Certification

Salesforce Certification Guide: Development Lifecycle & Deployment Designer

Standard

If you have ever attempted to get a Salesforce certification, you may find it stressful knowing how to best prepare for such a task. I attended Salesforce University 2017 and managed to get 2 certification within my 3 attempts. As a historically horrible test take this was a proud accomplishment for myself. As a self-taught developer, currently positioned as a Technical Architect, with ambitions to obtain the highly coveted Salesforce CTA title, I will never forgot the many people who gave back to the community to help me grow in this field.

With that said, I thought in a small way I could give back to anyone else with similar ambitions looking to prepare for the Salesforce Development Lifecycle & Deployment Designer Certification. After failing the test on my first attempt I felt mislead, I understood the concepts of everything the exam guide outlined, I can confidently say that I even feel comfortable teaching a class on it. So how could I have failed? Well for one the details on the test are not just conceptual understandings but specific terms and use cases that can’t necessarily be found by scouring Salesforce’s documentation even if you know what you’re looking for (which again the guide will not help you with).

Retrospective Guide

After absorbing my failure, I wrote down everything that I would need to get a more comprehensive understanding about so that I could debunk every tricky question I would encounter during my retake the following morning. This “retrospective guide” that I comprised that night helped my to pass the certification and I’m posting it in in case it can help you as well. This should not be your only source of study but I would definitely consider it your cliffnotes to make sure you know what to study so that you can be prepared. Good Luck!

Development Lifecycle & Deployment Design Guide:

I will put the important terms in headers with a description of what you need to know about it and any related bullet points I came across along the way.

Governance

Governance improves agility by ensuring all members of your team are working together to achieve. Three elements of a responsive, adaptable framework for governance are:

1. Circle of Excellence

A center of excellence (CoE) is a group of people who promote collaboration and best practices to ensure great business results. Need to understand the responsibility of this group and what decisions they are responsible for within the organization and throughout a given project

2. Release Management

Learn, educate, plan, communicate, test, go live, iterate. Understand the cycle of a release what challenges may arise. Keep in mind the Change Control Boards role within a release. Understand available tools like change sets and a sandbox to manage changes, and when it is appropriate to use them. Many question around scenarios that you must advise as a Technical Architect what is the best tool or solution to provide to ensure a release is deployed smoothly and on time.

3. Design Standards

When design or architectural questions arise you need to understand how the standards will dictate the direction going forward. Who governs and enforces these standards?

  • Standard naming conventions
  • Consistently using the Description field
  • Bulkified code
  • Standard methods for deprecating classes and fields
  • Consistent data architecture across all projects

The architect or architecture team in your center of excellence defines your company’s design standards

Roles

Program Sponsor

Need to know what their role is and what governance they have, meaning what decisions and/or will fall under their jurisdiction.

  • Executive responsibility for success of the project
  • Execution
  • Drives success

Steering Committee

Who makes up this committee? What is their responsibility within an organization and within a given project?

  • “Team of Champions”
  • Related to “Circle of Success”
  • Prioritize request
  • Review feedback
  • Cross-functional
  • Share decision-making: set and monitor the direction in alignment to the objectives
  • Info Resource – requirements gathering
  • Standardized Data – scale beyond 1 department

Change Control Board (CCB)

Who makes up this board? What responsibility do they have within an organization or a given project?

  • Decide whether the project/scope changes are implemented
  • When there is a diversion from the baseline requirements
  • Made up of stakeholders or their representatives
  • Ensure acceptance of project by client
  • Related to “Release Management”

Environments

Need to have a strong understanding of the different editions and their expected and appropriate use cases. Be aware of limitations when developing in a given edition with certain requirements or development team size. Also be able to advise a deployment plan against certain requirements including around Salesforce’s release schedule.

  • What edition org should be used for different types of testing?
  • When is the appropriate time to refresh a sandbox within a dev cycle?
  • How should you resolve a regression expected from upcoming Salesforce release?
  • What are the challenges of a large development team? Deployment, sandbox structure, etc.

Aloha Apps

There was one question where this appeared and it was the correct response to the scenario presented, in which the production org is approaching limits but still needs a new feature. Aloha Apps don’t count against your system limits for apps, tabs, and objects—no matter which salesforce.com edition you’re using

Change Sets

Don’t be fooled by the exam guide, this feature appears in more than 5% of the exam. The right answer may only be connected to 5%, but the feature itself appears several times throughout the exam.

You must understand the steps necessary to setup a change set, as well the limitations when attempting to use them

  • Cannot be used with developer orgs or orgs not related to your companies production or sandbox orgs.
  • The target site metadata will be locked during deployment.
  • Users can still read/write records (I found one question VERY confusing/tricky on this topic).

Methodologies

Depending on your experience or bias you may misunderstand some of the questions revolving around methodologies concerning a dev cycle. Keep in mind that both Agile and Waterfall have pros and cons and both can be used a wrong way and a right way. There is one question specifically that attempts to lead you towards agile alone given the time and budget constraints but Salesforce is using that to promote that waterfall too can adhere to those constraints if you use it correctly.

You don’t necessarily need to understand everything about the two approaches other than their main differences

Waterfall

Known for its structure, the ability to take on very large projects with massive requirements and provide documentation and actionable task towards a complete and through release. Praised for its completeness and adherence to governance but criticized for its clunkiness and heavy maintenance.

Agile

Known for its speed and efficiency, no project to big or small but thrives in small achievable deliverables. Criticized for its reckless nature of diving into the task without complete documentation of the requirements. It has the potential of providing immediate results with rapid deployment as its focus, but if not done properly it can miss the mark on the expected result for the end user.

Tools/Matrices

RTM (Requirements Traceability Matrix)

Used for tracking project requirements, great for outlining functional test that need to be accounted for during planning and project management. When refactoring code this can be helpful for creating regression test. Be aware of which scenarios this should be used

R.A.C.I. (Responsible, Accountable, Consulted, Informed)

Used to define each team member’s role and assists with reducing confusion on expectations, in turn, increasing project efficiency.

  • Responsible – Who is completing the task.
  • Accountable – Who is making decisions and taking actions on the task(s).
  • Consulted – Who will be communicated with regarding decisions and tasks.
  • Informed – Who will be updated on decisions and actions during the project.

Testing

Stress Testing

Gauge performance during abnormal/extreme conditions. Understand that stress testing is not necessary on the Force.com platform because Salesforce has already stress tested the platform so it is not necessary for you to

Load Testing

Gauge performance under expected conditions with varying loads. There are times where this is necessary but if so keep the following in mind:

  • Load testing on a sandbox will not provide the same benchmarks as a production environment. Variables include load patterns, database caching queue for @futures
  • In order to load test you must create a “test plan” that you submit to Salesforce for approval
  • TPS = Transactions Per Second. Used as metric for load testing.

Performance Testing

Gauge performance under particular workloads. This includes both stress and load testing collectively. You can test in sandbox to uncover conflicts between request (locking issues) or to test performance of external web services.

Apex Hammer

Mentioned at least a couple times during the test, but never appropriately from what I remember. At least understand that the Apex Hammer is a real thing (made that mistake my first attempt). Salesforce sometimes refers to this as “Hammer time”, and they do this during every release as a means of regression management.

In short, they use your unit test (even without asserts), to test against potential issues from their upcoming release. First they run all your test on its current version, then they run them again using the new version, its not important that the test pass or fail, but that the do not change results from the first or second attempt. If there is a difference in results then you will receive an email notification to update your Apex.

Tip: Even if the multiple choice suggest it, no you can not make arrangements with Salesforce to move the release date back, you will need to prioritize a fix by leveraging a sandbox that has the update.

Continuous Integration (CI) Considerations

You don’t need to use CI, but you need to understand its purpose and some considerations when advising its implementation as a technical architect

  • Uses Force.com migration tool
  • For small dev teams the only benefit is automated testing
  • For large dev teams you will benefit from commercial CI and custom builds.
  • Proper CI creates a new environment per a build cycle, this is not possible in Salesforce until the official release of Salesforce DX
  • This is a source control driven flow development workflow

Conclusion

I hope that helps someone out there cramming for their exam; if it does please comment below with any feedback. Also I don’t have everything listed (had over 20-30 tabs opened that night), but below are some of the references I used along the way as well as my original scratch notes. Also, remember to not limit yourself to Salesforce resources alone, some of the depth of the details you may need may be found elsewhere. Good luck!

Original notes

References