The Development Lifecycle and Deployment Architect Certification is tailored for individuals possessing the necessary expertise in implementing DevOps, Application Lifecycle Management, and governance principles in the Salesforce context.

This includes supporting client requirements and effectively communicating proposed solutions

and design trade-offs to both business and IT stakeholders.

There are 8 areas of knowledge that are covered by the Salesforce Development Lifecycle and Deployment Architect certification.

Development Lifecycle and Deployment Architect Topic Weighting Chart

The following are the core topic areas of the  Development Lifecycle and Deployment Architect certification and what you’re expected to know:

This topic includes the following objectives:

         Application Lifecycle Management (ALM) is the process of managing the life of an application. It manages an application’s development, from design to final release. It establishes a framework for fixing bugs and delivering feature enhancements over time. It consists of these phases: Plan Release, Develop, Test, Build Release, Test Release, and Release.

       Various development methodologies are available to manage the development of a Salesforce application. These include waterfall, agile, and hybrid. Furthermore, the principles of frameworks such as Scrum, Lean, or Kanban can also be applied to a Salesforce development project. It is also important to consider the establishment of governance strategies for a development methodology to e to manage and track changes effectively.

This topic includes the following objectives:

           Application Lifecycle Management (ALM) typically involves a specific process utilized for developing Salesforce applications. There are three development models available to implement an ALM process: the Change Set Development Model, the Org Development Model, and the Package Development Model. Each model necessitates the use of certain features or tools. For instance, the Org Development Model is source-driven and employs a source control system for tracking changes, while the Package Development Model utilizes unlocked packages and scratch orgs. Various key roles are integral to the ALM process, including architects, developers, QA testers, project managers, release managers, and business analysts, among others. These roles play crucial functions in ensuring the success and efficiency of the application development lifecycle.

       In Salesforce environments, addressing risks in customization, data security, governance, project management, development, and testing is crucial. Mitigation strategies involve user-centered design and governance frameworks for customization, stringent authentication, and encryption for data security. Documentation standards and rigorous testing address governance issues. Detailed planning and stakeholder engagement help manage project risks. Refactoring code and prioritizing tasks mitigate development challenges. Finally, comprehensive testing strategies and using separate environments address testing risks.

     A robust governance framework in Salesforce is crucial for aligning projects with business objectives and ensuring effective management. This framework should involve clear rules, processes, and responsibilities, guided by a Center of Excellence (CoE). The CoE coordinates strategic planning and project execution, ensuring adherence to standards. It harmonizes efforts across various teams, ensuring everyone works towards a common goal and adheres to the established standards. Additionally, effective change management is an integral part of a governance framework since it facilitates smooth transitions and adoption of new processes and technologies. 

This topic includes the following objectives:

          In Salesforce development, leveraging agile tools like Salesforce DX and agile project management tools significantly enhances team productivity and project management. Salesforce DX streamlines the development lifecycle with features like Salesforce CLI, scratch orgs, and Dev Hub, supporting rapid iteration and quality assurance. Agile project management tools, such as Agile Accelerator, facilitate task management, sprint planning, and real-time collaboration, allowing teams to adapt quickly and efficiently to changes. These tools are foundational in applying agile methodologies, ensuring teams can deliver superior Salesforce solutions swiftly and effectively. 

         In today's rapidly evolving business landscape, organizations leveraging Salesforce face critical decisions regarding their org strategy, primarily whether to opt for a single-org or a multi-org strategy. This decision significantly impacts an organization's ability to innovate, collaborate, and grow. Choosing an appropriate org strategy requires a comprehensive understanding of various factors, including business objectives, technical requirements, and architectural considerations. For instance, the enterprise architecture operating model is important to consider for an org strategy. By carefully assessing these aspects, organizations can tailor their Salesforce environment strategy to their unique needs. 

       A Salesforce sandbox is a separate, isolated environment that contains some or all of the data and metadata from production. Sandboxes can be used for development, testing, staging, and training. There are four types of sandboxes, namely: Developer, Developer Pro, Partial Copy, and Full. Each type of sandbox is used for specific use cases. A new sandbox is created with the metadata and data (depending on the sandbox type) from the production org. Refreshing a sandbox updates its metadata from the resource org. If the sandbox is a clone or uses a sandbox template, the process updates the org’s data and its metadata. Sandboxes have different refresh intervals and storage limits.

        For a successful deployment strategy, it is important to consider various components and tools. Deployment components include metadata components, data components, governance, change management, test plans and scripts, and rollback strategy.
On the other hand, there are various native and third-party deployment tools. They include Salesforce DX, Salesforce CLI, Metadata API, Ant Migration Tool, Change Sets, packages, automated testing tools, and CI/CD tools. 

This topic includes the following objectives:

     Using a source control system like Git for Salesforce development allows tracking and managing changes to code and configuration over time. It allows developers to revert to previous versions, compare changes, and merge updates from multiple sources.
Git keeps track of changes in a project over time while GitHub is a collaboration platform that hosts Git repositories. There are various branching strategies available for Git workflows, including Centralized Workflow, GitHub Flow, Gitflow Workflow, Forking Workflow, and Trunk-Based Development. A commit represents a snapshot of a project at a specific point in time. A merge conflict should be resolved to merge two branches successfully. It occurs when two developers have changed the same lines in a file or if a developer deleted a file while another developer was modifying it.

           In Salesforce, creating test data for Apex tests is necessary to ensure that tests do not depend on production data and are repeatable. Test data can be created using brute force, a test setup method, a test data factory, or a CSV data file uploaded as a static resource.
Various unit testing strategies are available for Apex unit tests. Positive tests are used to return expected results when a valid input is provided. Negative tests are used to ensure that code handles invalid data and unexpected user input correctly. Permission-based tests ensure that code behaves as expected when it is run as a user with or without specific permissions. Mocks and stubs facilitate unit testing by simulating real objects and methods, allowing developers to test code in isolation from external dependencies.

            The org development model and package development model are two models that are often used for Salesforce development. The org development model leverages sandboxes and a source control system for development. On the other hand, in the package development model, metadata and code for applications and customizations are organized into manageable packages. Scratch orgs are temporary orgs that can be spun up quickly for development. Sandboxes are copies of the production environment that are used for development, testing, and training. Individual development orgs and partner development orgs are also available for application development. Partner development orgs offer higher API and storage limits and more licenses.

         There are various methods that can be utilized to ensure the delivery of quality code in Salesforce. These include the creation of coding conventions and standards, the integral process of pull requests in Git-based workflows, the practice of code review for quality assurance, and the technique of static code analysis for the examination of code. These methods can be used to improve code consistency, enhance code security, catch bugs, and significantly improve the overall integrity of the codebase. 

This topic includes the following objectives:

         Salesforce allows the use of Metadata and Tooling APIs to perform operations that involve metadata. Metadata API can be used to move metadata between orgs during the development process. It supports operations such as retrieving, deploying, exporting, and deleting metadata. Up to 10,000 files can be retrieved or deployed using Metadata API. Moreover, the maximum file size of a deployed .zip file is 39 MB.Tooling API can be used when fine-grained access to an org’s metadata is required. It supports the use of SOQL queries to retrieve smaller pieces of metadata. REST resources and SOAP calls can be used to access Tooling API functionality. Certain SOQL and SOSL operations are not supported for the EntityDefinition and FieldDefinition objects.

      Salesforce deployments often require pre and post-deployment steps. Pre-deployment steps include important activities such as planning, sandbox testing, documentation of manual steps, freezing users, etc. It is necessary to perform these steps to ensure that no issues arise during or after the deployment. Deployment activities include choosing a suitable tool, performing deployment validation,  identifying the correct order of dependencies, and performing the deployment. Post-deployment steps are necessary to make sure that the deployed components work as expected. Some important steps include reactivating deactivated features, such as validation rules and email deliverability, performing data migration in the correct order, monitoring the deployed features, etc.

       In Salesforce, technical reference data is used to categorize other data, standardize terminology, and ensure consistency across systems. It serves as a reference within applications, such as picklist values, configuration settings, or other standardized data sets.
Custom Metadata Types are typically used to store and manage technical reference data that can be deployed across Salesforce environments. Various considerations are applicable to the management and deployment of technical reference data. For example, when using Salesforce objects to store the data and use it in Apex, object relationships and governor limits should be considered.

This topic includes the following objectives:

        In the Salesforce landscape, a comprehensive testing approach is vital for ensuring applications meet both performance and business criteria. This approach includes unit testing to check individual components, integration testing for verifying component interactions, and system testing to assess the application as a whole. User Acceptance Testing (UAT) confirms the solution aligns with user expectations and business needs. Regression testing ensures new updates do not disrupt existing functionalities. On the performance front, performance testing, load testing, and stress testing evaluate how the application behaves under various loads and conditions. Collectively, these methodologies guarantee that Salesforce applications are robust, reliable, and ready for deployment.

         In Salesforce, a test execution methodology is essential for a structured approach to executing tests, ensuring comprehensive coverage and alignment with best practices. Various tools are available for the execution of Apex unit tests, including Apex Classes page, Developer Console, and VS Code. When using Metadata API for a deployment, a subset of tests can be run using the RunSpecifiedTests test level. Using a mock object is necessary to test Apex code that performs HTTP callouts. The startTest() and stopTest() methods can be used to reset governor limits in Apex unit tests. For testing Lightning components, the Jest framework can be utilized. Aura component accessibility tests can be run in two environments: JavaScript and WebDriver

          A unified test data strategy is necessary to ensure the usage of consistent, reliable, and secure test data that is representative across all stages of the Salesforce development lifecycle. For reliable test data generation, data factory methods and scripts can be used. Tools such as Data Loader can be used for bulk data operations in non-production environments. Salesforce Data Mask can be used to automatically mask sensitive production data in sandbox environments. Mock data that mimics production data shape and volume can be generated. Batch Apex can be used to delete test data on a regular basis. Automated test data loading can be used for reliable results and when no human oversight is required. Multiple related records can be inserted in a single call or transaction using REST API composite requests or sObject tree requests.

This topic includes the following objectives:

      In the Salesforce ecosystem, the deployment and distribution of custom applications and functionalities can be effectively managed through different types of packages: managed, unmanaged, and unlocked packages. Each package type serves distinct use cases, from distributing applications on the AppExchange, sharing open-source projects, to deploying modular customizations within an organization. Managed packages are ideal for ISVs to distribute and sell applications with upgrade paths and license management. Unmanaged packages are suitable for one-time distributions where the recipient may need to modify the source code. Unlocked packages provide more flexibility for iterative development and release management within Salesforce DX, offering a balance between controlled deployment and customization capability. Understanding when and how to use each package type is crucial for Salesforce developers and architects to ensure efficient, secure, and scalable application lifecycle management.

       In today's dynamic Salesforce development environment, aligning a sandbox strategy with a comprehensive release plan is essential for project success. This involves meticulous planning across multiple project streams, each with its distinct development and deployment timelines. A well-thought-out sandbox strategy ensures that various teams can work in parallel without interference, while also accommodating training needs for end-users on new features or updates. Additionally, having a dedicated environment for staging allows for thorough validation of features and updates before production deployment, ensuring that each release enhances the system's functionality and stability. Moreover, the strategy must include provisions for urgent hotfixes to address any unforeseen issues promptly. 

      Developing a robust release management strategy tailored to specific customer scenarios is crucial for the integrity and efficiency of Salesforce projects. This approach involves analyzing the customer's operational requirements, development processes, and business goals to devise a strategic plan that ensures smooth, consistent, and successful deployment of Salesforce updates. By incorporating different types of releases (immediate, minor, major, and hotfix) in their release management strategy, organizations can significantly enhance the delivery of new functionality on their Salesforce platform. An effective release management strategy aligns releases with business objectives, facilitating seamless integration of new features and improvements.

This topic includes the following objectives:

      Organizations leveraging Salesforce must navigate the delicate balance of implementing urgent updates in their production environment against the backdrop of ensuring operational stability and security compliance. It is important to understand the critical considerations and implications of directly incorporating requests in a production environment.
Appropriate strategies must be adopted for addressing immediate issues in Salesforce-driven operations. Salesforce architects need to make informed decisions about making changes directly in production. Urgent fixes should enhance system functionality without compromising data integrity or user experience. Furthermore, best practices should be considered for managing direct changes in production, emphasizing the importance of thorough testing, stakeholder communication, and compliance with industry standards.

         Integrating changes directly into a production environment in Salesforce presents unique challenges and considerations. It is important to manage these changes within the broader context of Application Lifecycle Management (ALM). Such changes have implications on the development lifecycle, from potential disruptions to workflow, system integrity, and compliance issue, making it necessary to utilize strategies for effectively incorporating them into the ALM process. The risks associated with direct production changes need to be mitigated, ensuring seamless integration, and maintaining the balance between rapid deployment needs and the necessity for rigorous testing and validation processes. Architects should be able to make informed decisions with the aim of upholding system stability and user experience while accommodating urgent business requirements.

         In today’s complex Salesforce environments, architects often face the challenge of managing common release artifacts across multiple Salesforce orgs. In a multi-org architecture, various approaches can be utilized for managing these shared components, which include custom fields, Apex classes, Lightning components, etc. Salesforce architects should have the knowledge and tools to efficiently synchronize updates, maintain consistency, and ensure the seamless operation of business processes across different Salesforce orgs. Strategies for managing common release artifacts include source-driven development, Metadata API-based deployments, package-based deployments, and the use of change sets.