Salesforce deployment roadmap: from inception to implementation

Change sets serve as a user interface tool facilitating the deployment of customizations from one Salesforce environment to another. With change sets, you can select specific components, such as custom objects, workflows, and Apex classes, streamlining the deployment process. More on it later.

It is probably the most used deployment type in Salesforce sandboxes. Salesforce DX represents a paradigm shift in Developer tools, emphasizing source-driven development. The command line interface (CLI) enables Developers to perform various tasks, emphasizing version control and collaboration.

The Ant Migration Tool complements change sets and Salesforce DX by providing a programmatic metadata retrieval and deployment approach. You can use this command line utility that supports the scripting of complex tasks. It also offers features like batch processing for the structured deployment of numerous components.

👉 Author's note: Remember that the Ant Migration Tool has reached its end of life as of Winter '24.

There are many valuable external deployment solutions you can incorporate into your workflow. Many of them do, however, pose some challenges that are beneficial to keep in mind.

These solutions include:

• Salesforce native change sets: They are outdated, have a poor UX, and tend to be error-prone.
• Salesforce command line: It is excellent for deployments but is designed with experts in mind.
• Org to org deployments: Gearset and Salto are good tools to deploy from org to org. However, tools like these leave some problems unanswered, such as presenting a clear source of truth and giving an overview of what feature went to production.
• Salesforce DevOps Center: As it is still very immature, it can be slow-moving and lack support.
• Copado: It streamlines an enterprise's software lifecycle and automates deployment tasks to speed up the release process. The downside is that Copado can be costly, and deployments must be executed 'the Copado way.'

🔎 Author's note: I thus recommend to use a combination of a more lightweight, modern UX tool – like Hutte – and combine it with open-source, like you can find on Hutte Recipes, to make your deployments automated from your Git host.

CPQ deployments are a bit tricky because they involve special data relationships. Unlike metadata, each piece of data gets a unique CPQ ID, so you must carefully keep everything organized and avoid any mix-ups. With all the unique IDs and multiple data relationships, deploying changes between environments gets complex and error-prone.

Salesforce Industries (or Vlocity) adds a bit more complexity to changes. When making changes, remember that these changes might act a bit differently compared to other parts of Salesforce.

Testing things out in a safe space before deploying with Vlocity is crucial. If you're working with it, make sure to chat with professionals already working on such deployments.

Set up meetings with key stakeholders to clarify deployment objectives. Ensure that these align with the overall business goals.

Try to put stakeholders on the same page to mitigate potential misalignments and secure commitment to shared objectives.

Establish measurable key performance indicators (KPIs) to measure the impact of the deployment and gauge its success.

Conduct a thorough analysis of any possible dependencies between different components, identifying any interrelated functionalities or processes.

Allocate responsibilities among team members based on identified dependencies, optimizing resource utilization.

Develop a strategy to mitigate risks associated with dependencies, providing a contingency plan for potential bottlenecks. 

🧠 Author's note: Use your consultants!

Developing a realistic timeline is one of the essential prerequisites of the Salesforce development process. A strategically developed timeline helps in dealing with any foreseen or unforeseen challenges.

Consider adopting an iterative release approach, allowing incremental enhancements. Breakdown all the changes into smaller chunks and deploy them in iterations.

Communicate the release schedule transparently to all stakeholders and team members, ensuring everyone is on the same page regarding timelines and expectations.

Develop clear criteria for prioritizing features and changes, considering factors such as business impact, user needs, and strategic alignment.

Establish a habit of regularly reviewing and grooming your backlog, ensuring that priorities remain aligned with evolving business requirements. You don't want to miss an open bug or an underdeveloped feature while deploying.

Embrace agility in the planning process, allowing for priority adjustments based on real-time feedback and changing circumstances.

Systematically identify potential risks associated with the deployment, covering technical, operational, and organizational dimensions. However, you'll be halfway there after you oversee all the backlogs and dependencies.

This is an underrated trick, but you should actively seek stakeholder input to capture a broad perspective and insight into potential risks.

Maintain a comprehensive risk register, documenting identified risks, dependencies, and their potential impact on the deployment.

Once you have the list of all the potential risks, develop detailed plans to mitigate them, outlining specific actions, responsibilities, and timelines.

You should communicate the risk mitigation strategies to the relevant stakeholders, fostering transparency and collaboration.

It helps if you implement continuous monitoring mechanisms to reassess risks throughout the planning process, allowing for dynamic adjustments to mitigation strategies.

Before anything, take a backup of the Salesforce instance, including data, metadata, and configurations. You can utilize Salesforce's native backup tools or third-party solutions to ensure a complete snapshot.

Document a detailed snapshot of the current environment, capturing metadata configurations, workflow rules, and custom code. 

🗣️ Author's note: Don't forget to include information on profiles, permission sets, and sharing settings to recreate the environment accurately if needed.

Regularly simulate the restoration of backups in a sandbox environment to validate the completeness and accuracy of the backup process. Documenting and communicating the backup and recovery procedures to the deployment team is even better.

First things first, formulate a data migration strategy based on the volume and complexity of data, considering factors such as data relationships and dependencies. Prioritize data cleansing and transformation steps to ensure data quality during migration.

Clearly define how data will be mapped from source to target, addressing schema differences between environments. You can use Salesforce or external data mapping tools to streamline the mapping process. Document data mapping rules and share them with relevant team members involved in the deployment.

Implement validation checks post-migration to verify the accuracy and completeness of the migrated data. Match the source and target environments to address any discrepancies. Ensure stakeholders are involved in the validation process to ensure alignment with business expectations.

Change sets allow Developers to group a set of changes, including fields, workflows, and Apex classes, into a single package.

The process involves creating a change set in a source environment, adding components to it, and deploying it to a target environment.

Change sets closely align with declarative development by capturing configuration changes made through point-and-click tools in the Salesforce setup.

You need to carefully choose the components to include in the change set, such as custom objects, fields, workflows, and Apex classes.

Emphasize the importance of testing these changes thoroughly in sandbox environments before promoting them to production to catch potential issues early.

Implementing naming conventions and thorough documentation practices enhances change set manageability, making it easier to track changes and understand their purpose.

We've already talked about it a few times. You need to know how changes to one component may impact others, emphasizing the importance of deploying related components simultaneously.

Leveraging Salesforce tools like the dependency API helps identify and address dependencies before initiating deployment, reducing the risk of deployment errors.

Encourage collaboration among Developers and Testers to resolve dependency-related issues. Communication and collaboration are vital to ensuring a smooth deployment process.

Salesforce CLI enables the automation of deployment tasks, ranging from deploying metadata components to loading data and executing scripts.

CLI comes with some common commands used in deploying metadata changes, retrieving modifications from an org, and executing tests to ensure code integrity.

Salesforce CLI facilitates script execution, allowing Developers to create automation scripts that enhance deployment efficiency.

Developers can create reusable scripts for complex deployment scenarios, streamlining the execution of repetitive tasks.

You should use version-controlled scripts to ensure traceability and collaboration among team members. This practice enhances transparency and supports teamwork in the development process.

Documenting best practices for script development and maintenance ensures that Developers follow standardized procedures, reducing the risk of errors and promoting consistency.

The integration allows for a controlled deployment workflow, enabling Developers to manage changes, track versions, and collaborate seamlessly.

Get a clear understanding of branching and merging strategies within version control systems. This allows for parallel development efforts without compromising code integrity.

Implement continuous integration practices to automate the deployment pipeline using Salesforce CLI. This ensures that changes are validated automatically with each code change, minimizing manual intervention and reducing the risk of deployment errors.

Unit testing involves testing individual components, such as Apex classes, triggers, or methods, to validate their functionality in isolation. It ensures each individual component is working fine.

The importance of unit testing in the Salesforce deployment process is that it:

• Ensures each component functions as intended
• Identifies and rectifies errors early in the development cycle
• Facilitates the maintenance of code integrity and stability.

A step further from unit testing, integration testing verifies the seamless interaction between different components within the Salesforce ecosystem, ensuring they work cohesively.

The importance of integration testing in the Salesforce deployment process is that it:

• Validates the interoperability of integrated functionalities
• Detects issues arising from the collaboration of multiple components
• Assures the overall system functions harmoniously.

UAT involves end-users testing the system to validate that the deployed changes meet their expectations and align with business processes.

The importance of UAT in the Salesforce deployment process is that it:

• Gathers valuable feedback from end-users
• Confirms alignment with business requirements
• Ensures the system meets user expectations.

Automated testing involves using tools and scripts to execute test cases, enhancing the efficiency and accuracy of the testing process. It frees the testing team from various manual tasks and allows them to run tests 24/7.

The importance of automated testing in the Salesforce deployment process is that it:

• Reduces manual effort and human errors
• Facilitates continuous validation of changes in the development pipeline
• Improves consistency and repeatability of test scenarios.

Utilize Salesforce deployment monitoring tools to monitor deployment progress in real-time. Stakeholders can easily access dashboards or reports displaying deployment metrics and status updates.

Establish straightforward communication channels to update stakeholders on the deployment status. Designate a central point for inquiries and regularly share updates through email, chat, or collaboration platforms.

Schedule periodic check-ins with key stakeholders to address concerns and provide clarification. These check-ins foster collaboration, allowing stakeholders to provide feedback and seek clarifications during the deployment process.

Develop a comprehensive rollback plan that outlines the steps to revert changes in case of unexpected issues. Identify specific triggers that would necessitate a rollback, such as critical errors, data corruption, or performance degradation.

• Regularly test the rollback procedures in a sandbox environment to ensure their effectiveness.
• Document the rollback testing process, including success criteria and steps for each scenario.
• Iteratively refine the rollback plan based on testing outcomes.

Deploy changes in small, incremental releases rather than large batches. This reduces the risk of errors and makes troubleshooting more manageable.

Implement continuous integration practices to merge code changes, ensuring consistent integration and automatic testing.

Develop a rollback plan detailing steps to revert changes if needed. Perform validation tests post-deployment to confirm success.

Sustain collaboration between development, testing, and operations teams. Encourage open communication channels for swift issue resolution.

Pre-populate sandboxes with realistic data to mimic the production environment, aiding accurate testing and reducing the likelihood of data-related issues.

Establish governance policies to ensure adherence to best practices. Ensure compliance with industry regulations and internal standards.

Regularly backup configurations and data before deployments. Establish a reliable restore strategy for quick recovery in case of issues.

In case you're using change sets, prioritize their validation in a sandbox environment before production. Identify and resolve issues early in the deployment lifecycle.

Implement monitoring tools to track deployment progress and system health. Set up alerts for any anomalies or unexpected behaviors during deployments.

Involve end-users in UAT to validate changes from their perspective. Address user feedback before moving changes to the production environment.

Document not only code changes but also configuration modifications. Include details about dependencies, integrations, and any manual steps.

Communicate the completion of deployments to all stakeholders. Provide a support channel for users to report issues post-deployment.

Train Salesforce Administrators on new features and changes. Ensure they are equipped to handle potential user inquiries.

Conduct performance testing, especially for large-scale changes. Identify and address any performance bottlenecks before deployment.

Maintain detailed deployment plans and document post-deployment changes for future reference.