Capturing all details I’ve managed to find about this exam. Helped me organise my thoughts but might help other as well.

About this Credential 

The Salesforce Certified Development Lifecycle and Deployment Designer credential is designed for professionals who have the requisite skills and experience in managing Lightning Platform development and deployment activities as well as effectively communicating technical solutions to business and technical stakeholders.

About the Exam 

• Content: 60 multiple-choice/multiple-select questions
• Time allotted to complete the exam: 105 minutes
• Passing score: 68%
• Exam Guide

Exam Outline

Category	Counts	Trailhead Links
Environments	15%	Org Development Model An Introduction to Environments
Application Lifecycle Management	17%	Application Lifecycle and Development Models
Testing	10%	Unit Testing on the Lightning Platform
Governance	17%	Governance Basics 9 Steps to Effective Change Management
Risk Identification and Mitigation	12%	Raise level of awareness on generally accepted practices, tooling and resources for applying some SDLC principles to Salesforce.
Change Sets	5%	Change Set Development Model
Metadata API	10%	Apex Metadata API
Continuous Integration Techniques	8%	Simplify Your Development Process with Continuous Integration
Methodology Tools	3%	Salesforce Agile Basics
Understanding Packages	3%	Build and Release Packages with Salesforce Developer Tools

Out of Scope

• Project Management generics
• Salesforce Editions and License types
• Salesforce DX/Heroku CI*

Application Lifecycle Management

Project Assignments, test plans, decisions, and milestones are easier to think about in concrete terms than in the abstract : Backlog => Development Process => Release.

The Typical Development Process Lifecycle:

• Step 1: Plan Release – Plan functional requirements.
  • Schedule your concurrent development projects.
  • Establish a process for changes to the production organization.
  • Track changes in all environments.
• Step 2: Develop – Develop using Salesforce Web tools, using profiles to hide your changes until they’re ready to deploy. Each team member has their own Developer sandbox to create their assigned customization. Developer sandboxes contain no production data.
• Step 3: Test – Update profiles to reveal your changes to the appropriate users.
• Step 4: Build Release – Each team member migrates their customizations from their respective Developer sandboxes to a shared Developer Pro sandbox for integration. Developer Pro sandboxes don’t contain production data, but you can seed them with testing data.
• Step 5: Test Release – For user-acceptance testing, the team uses a Full sandbox to create a complete replica of production. A Full sandbox includes production data.
• Step 6: Release – Notify end users of changes. After the release is in production, the team can use the Full sandbox created in the last step to train users without exposing production data.
  • Releases typically fall into one of three categories:
    • Patch
    • Minor
    • Major

Environments

Given a customer landscape and their requirements, evaluate business, technical, and architectural considerations while defining an appropriate org strategy.

What are the uses for a Sandbox environment?

Use sandboxes for development, testing, training, or other purposes without compromising the data and applications in your Salesforce production org.

All Sandboxes are generated from a production org and has the same number of Licenses as Production.

• Generate new Sandbox from any type or clone an existing Sandbox:
  • New Sandbox: Salesforce copies the metadata from your production org to a sandbox org.
  • Clone Sandbox: A cloned sandbox uses the same license type as its source org.

There are 4 Sandbox Types:

• Developer – Developer sandboxes copy customization (metadata), but don’t copy production data, into a separate environment for coding and testing.
• Developer Pro – Developer Pro sandboxes copy customization (metadata), but don’t copy production data, into a separate environment for coding and testing. Developer Pro has more storage than a Developer sandbox. It includes a number of Developer sandboxes, depending on the edition of your production organization.
• Partial Copy – A Partial Copy sandbox is a Developer sandbox plus the data that you define in a sandbox template.
• Full – Full sandboxes copy your entire production organization and all its data, including standard and custom object records, documents, and attachments. Use the sandbox to code and test changes, and to train your team about the changes. You can refresh a Full sandbox every 29 days.

Use Case	Developer	Developer Pro	Partial Copy	Full
Build	●	●
QA	●	●	●
Integration Testing			●	●
Batch Data Testing			●	●
Training			●	●
User Acceptance Testing			●	●
Performance or Load Testing				●
Staging				●

Deployment between environments:

How can you ensure that changes can be successfully deployed without overwriting changes on the Production Organization?

Being able to track and replicate changes in all environments is the only way to ensure that functionality can be successfully deployed without overwriting changes on the production org. This may have to be done sometimes manually.

Testing

• Unit Test – Specify and test one point of the contract of single method of a class. This should have a very narrow and well defined scope.
• ​Integration Test – Test the correct inter-operation of multiple subsystems. There is whole spectrum there, from testing integration between two classes, to testing integration with the production environment and external systems. ​
• Regression Test – A test that was written when a bug was fixed. It ensures that this specific bug will not occur again. The full name is “non-regression test”. It can also be a test made prior to changing an application to make sure the application provides the same outcome. ​
• Acceptance Test – Test that a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case to provide rather than on the components involved.
• ​Stress Test – Used to gauge performance during abnormal or extreme conditions often caused by diminished resources or excessive requests
  • Goal is to find the boundaries of a system
• Load Test – This is considered as positive test as we monitor application performance with predefined load (concurrent operations).
• ​Performance Test – Used to gauge performance under expected conditions with varying loads (i.e., increasing numbers of users or transactions) and monitor response request time performed of concurrent transaction and configurations.
  • It Measures performance under a particular workload, and includes both stress testing and load testing.
  • Ensure custom application or business logic meets your desired response times
  • Determine whether your estimated transaction throughput of anticipated loads is accurate
  • This is also considered as positive test. 

Apex Hammer Test

Salesforce runs your org’s Apex tests in both the current and new release and compares the results to identify issues for you. The Hammer means taking every single Apex test that you or anyone else has created and running it twice.Salesforce uses these results to identify any issues to resolve before the release.Apex hammer test refer only those test classes which do not have access to org data.  The advantages of creating data silo tests are:

• Tests run more reliably because they aren’t dependent on data that can sometimes change.
• Failures from those tests are easier to diagnose.
• Finding bugs in the Hammer process is easier.
• Deploying from one org to another is more reliable.
  • credit to sfdcstuff.com

Governance

What is a Change Process?

A change process determines what kinds of modifications can take place on your production organization, when they can occur, and who is responsible for making the changes.

Best Practices for change process :

• Allow no changes in production (most strict)
• Modify only components in the Metadata API
• Allow only one administrator to make setup changes (workable if org is small enough for just one admin to handle)
• Schedule Production Changes

Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile vs Waterfall Methodology

• Use agile approach if requirements keeps on changing based on end user feedback. This is an iterative approach in which we deliver features one by one. In this approach we estimate project time line and budget and will not have strict deadlines as requirements may vary based on end user feedback.
• Use waterfall methodology if project has fixed scope, timeline and budget. Also if requirements are pre-defined and end users are looking for complete product at end of process.

Governance Roles and Responsibilities

Information Technology – administer and develop your Salesforce instances.

• Defining the release schedule
• System testing
• System support

Business Units – Own the project vision and strategy. A lean governance framework establishes a continuous partnership between technology teams and the people who run the rest of the business.

• Gathering end-user feedback
• Onboarding users
• Owning and managing the budget
• Designating a product owner

End Users – They hold the knowledge about the business process you’re trying to optimize in Salesforce.

 

CoE Roles

• Executive Sponsor – Helping overcome the biggest obstacles to success.
• Program Team – Manages the CoE’s daily activities
• Release (Project Management) – Create and own the overall project roadmap and release plan
• Business – Convert high-level goals and strategies into a business backlog (Agile) or prioritized list of goals (Waterfall)

Change sets

Documentation available. When you want to send customizations from your current org to another org, create an outbound change set. Once you send the change set, the receiving org sees it as an inbound change set.

In Order to allow deployments you will need to establish a connection manualy from the UI. Modify the source org to allow an outbound connection to the target org and inside your target org make sure to allow inbound connection from the source.

Deployment is a one-way transaction – A change set is deployed in a single transaction. If the deployment is unable to complete for any reason, the entire transaction is rolled back. After a deployment completes successfully, all changes are committed to your org and the deployment can’t be rolled back.

Change sets can easily show related dependencies. The delay when creating a new changeset is because Salesforce checks component dependencies before displaying the change set page.

Action overrides in change sets – you cannot change names, you may only change field type using change sets.

Consider possible delays in deployment time when a change set includes field type changes

Quick Deploy

• Quick deploy option is available for only production environment.
• Quick deploy option is applicable for non production organisations.
• Quick deploy is available for change sets and meta data API-based deployments.

To perform quick deployment:

• First run a validation-only deployment with test execution.
• Quick deploy option is enables or appears for only qualified success validation.

Metadata API

Force.com Migration Tool (ANT)

The Force.com Migration Tool is a Java/Ant-based command-line utility for moving metadata between a local directory and a Salesforce organization.

Gives you complete control over the retrieve() and deploy() asynchronous methods and various commands; editing and saving a file on your local file system does not change the metadata in any organization until you choose to deploy it.

How does the Metadata API work?

Metadata API provides two parts that work in conjunction: a rich and powerful metadata model and an application programming interface (API).

Limitation of Metadata API:

You can deploy or retrieve up to 10,000 files at once and the maximum size of the deployed or retrieved .zip file is 39 MB. If you need to retrieve or deploy more than either of these limits, you must do so in batches.

Force.com IDE Allows you the following benefits:

• Work with setup configuration as metadata files.
  • Deploy or retrieve components using a package.xml file
  • Delete components using destructiveChanges.xml file
• Copy, paste, merge, and manipulate metadata files using familiar tools, such as text editors, IDEs, batch scripts, and source control systems.
• Migrate configuration changes between organizations, either between two development environments or from development to production.
• Create your own tools for managing deployment.

What are some factors with Deployment Time?

• Number and size of files—The more you deploy, the longer deployment takes. However, network payloads are rarely larger than 10 MB, so raw file size usually does not play a significant role.
• Type of components—Some components take longer to process than others. For example, custom fields, custom junction objects, and profiles take longer to deploy than other components.
• Processing time—Making a change that requires recalculating data takes an amount of time proportional to the amount of data that has to be modified. For example,changing a field type could require modifying all records that use that field.
• Test execution—When deploying to a production organization, the number and complexity of Apex tests have a large impact on the deployment time.
• Network and server availability—These are of minimal concern compared to other factors. However, consider scheduling long-duration deployments during off-peak hours so that you are not waiting on deployments during working hours or locking components from use.
• Locking—If users are working in the org during deployment, locking can affect users and the deployment.

What is a deployment validation?

A deployment validation is a deployment that is used only to check the results of deploying components and is rolled back. A validation doesn’t save any deployed components or change the Salesforce org in any way. You can determine whether a deployment is a validation only (Validate) or an actual deployment (Deploy) by inspecting the information for pending deployments or the Status column of deployments in the Failed and Succeeded sections.

If a validation completed successfully in the last 10 days, and all tests passed with sufficient code coverage, you can perform a quick deployment by deploying this validation to production without running tests.

What are the different Deployment Dependencies?

• Parent-child—Metadata components may depend on other components.
• Referenced file—Every file that is referenced by another file must either be included in the deployment plan, or already in the destination organization.
• Ordering—Dependencies require that components are deployed in a specific order, and within a single deploy operation, this order is handled automatically by the Metadata API. However, if you deploy a subset of components, or split your deployment into multiple batches, you must take into account the ordering dependencies yourself.
• Mandatory fields—When you create an object using the Force.com IDE or the Salesforce user interface, the tool enforces the creation of mandatory fields.

Packages

Given a scenario, analyze and explain the use cases and considerations when using managed vs. unmanaged packages

Sample Questions

1. Universal Containers is having problems with their development team. The developers are overwriting code, and blaming each other for bugs and unit test failures. Due to security implications, UC has decided to begin auditing changes for compliance. What should an architect recommend to address these issues?
   • A. Implement a requirements traceability matrix.
   • B. Schedule regular exports of Salesforce system audit logs to an offsite database.
   • C. Implement a source control system and require developers to commit changes.
   • D. Require developers to work in different sandboxes and periodically merge code into a staging sandbox.
2. Universal Containers is going to create a new Customer Community. The requirements for the community are not defined yet. The company is planning on an agile methodology, and has committed to delivery in three months. What two items would an architect identify as potential risks to this approach? Choose 2 answers.
   • A. Agile is not an appropriate methodology for Customer Community implementations
   • B. The functionality that can be delivered in 3 months is unknown, and may not meet business requirements.
   • C. Agile does not allow for changes in requirements, so customers may not like the end result.
   • D. Given the lack of requirements and 3 month time commitment, the project may not be feasible.
3. Universal​ ​Containers​ maintains 18 different orgs across multiple regions. One of these regions has created a new custom object to track delivery vehicles. The CIO has requested that this tool be used in all UC Salesforce instances. Each org is managed locally, so modifications may be necessary to the object. Which deployment tools would support this request?​ Choose​ ​2​ ​answers.
   • A. Change Sets
   • B. Force.com Migration Tool
   • C. Force.com IDE
   • D. Tooling API
   • E. Managed Package
4. Universal Containers (UC) has purchased a new application from a partner to enable advanced quoting. UC just hired a developer to help modify the application to meet their needs. Which two package types should the Architect recommend?
   • A. Unmanaged package developed in a Partner Developer Edition org.
   • B. Managed package developed in a Partner Developer Edition org.
   • C. Unmanaged package developed in a Developer Edition org.
   • D. Managed package developed in a Developer Edition org.
5. What consideration should an Architect take into account when asked for a recommendation of Agile vs. Waterfall?
   • A. Rapidly changing business requirements.
   • B. Project budget and timeframe.
   • C. Number of stakeholders involved.
   • D. Technical complexity of the project.
6. Universal Containers (UC) has a highly customized org. A Salesforce release is coming up soon, and UC has sandboxes that have already been upgraded to the next release. What two actions should UC take to ensure that their customizations are not affected by the new release?
   • A. Execute all unit tests in the upgraded Sandbox to validate that code has not been affected.
   • B. Review code in the upgraded Sandbox to ensure that no automatic updates were applied to the code.
   • C. Testing is not necessary because Salesforce tests all code and configuration before each upgrade.
   • D. Review the updated features of the release, and perform functional testing to understand the impacts of updated features
7. A Salesforce release is coming up soon, and Universal Containers (UC) has sandboxes that have already been upgraded to the next release. UC has been developing code in an upgraded Sandbox, and needs to deploy code to Production which is still on the previous release. What is required to deploy these changes to Production?
   • A. No adjustments are necessary because all metadata types will deploy normally to Production.
   • B. It is not possible to deploy from an upgraded Sandbox to an older Production version.
   • C. Versioned metadata needs to be downgraded to a previous API version before deployment.
   • D. No adjustments are necessary as long as the deployment is from a Full Sandbox.

Answers

1. C
2. B, D
3. B, C
4. A, C
5. A
6. A, D
7. C

Resources :

• Official Salesforce study guide
• Development Lifecycle and Deployment Designer Study Guide – by Chris Gardner
• Random images were taken from Salesforce Slides for certification please visit salesforce.com