Data migration
June 14, 2024
How to build a best-in-class release management strategy
The three essential phases to keep in mind
.jpeg){kind=avatar}
It’s critical for Salesforce teams to have a best-in-class release management strategy to ensure they can deploy changes to production accurately, effectively, and without any bugs. In this blog, we discuss how to build a best-in-class release management strategy in three phases. You’ll advance from a basic strategy with manual deployments to an intermediate one with CI/CD and ultimately to an expert level with automation.
A basic release management strategy defines when and where changes are promoted from one Salesforce org to another. Release management is the practice of packaging tested and approved changes and then deploying them to production.
The principles of a basic release management strategy are:
Because this phase is foundational to building a best-in-class release management strategy, we’ll take a closer look at the components you need for it.
A release consists of verified changes made by Salesforce admins, developers, or contractors. Business users request these changes by means of work items. When combined, the changes in a release deliver an enhancement, new feature, or bug fix.
The most fundamental principle of release management is that the changes must be verified. So this means you must have a full understanding of what has changed and why—and the certainty that the change works as desired.
To verify changes, you need to have:
Note that there’s a lot of emphasis on documentation. This rigor is standard in software development, but generally lacking in Salesforce practice.
To see differences between orgs, it can be helpful to use a tool like Prodly. With our compare orgs feature, you can see everything that’s different in the development environment compared to the destination environment and generate documentation accordingly. That way, pieces of the release won’t be missed. In addition, you can easily identify which changes work and which didn’t pass testing.
Next, when you have verified the changes, you can package them together for a release.
Before deploying any changes, you need to define your packaged release deployment flow. In other words, you must decide how to move the changes through the various stages of development to production.
Also, determine how you’ll sync new work back down to lower-level environments. This gives your developers and admins a clear understanding of the impact of their work based on the ever-evolving state of production. In addition, it helps prevent the, “This worked in my Dev org, but it doesn’t work in UAT” conversation.
Each stage of development should have its own dedicated environment. As a result, it’s best practice to use feature branch orgs, which means using one scratch org or Developer sandbox per feature you’re creating.
Here’s what a basic release pipeline should look like:
All new work should go through the defined release path. However, no process is perfect, and occasionally, a bug makes its way into production.
When that happens, you can save yourself a ton of headache by having a clearly defined hotfix strategy. It’s like insurance. You don’t want to realize you’re not covered after you’ve been in a collision.
Create a dedicated hotfix environment where you can isolate the bug, fix it, and then sync it to all the in-flight orgs in your release path. Otherwise, you risk re-introducing the bug in the next release.
Some Salesforce teams use a Full Copy sandbox as their hotfix environment. However, this isn’t necessary. In contrast, with a good seeding strategy, you can recreate the components that matter in a scratch or Dev org and develop a fix there.
Using this strategy, you can build hotfixes without interrupting the rest of your release management flow. You can debug and fix a production problem in a targeted environment and push the components to production in an isolated hotfix release. Then you can share the hotfix to lower environments to ensure you don’t introduce the same bug again.
After you’ve established all the fundamentals discussed in Phase I, it’s time to move to the intermediate level. The main principles of this phase include:
At the intermediate level, give every team member their own up-to-date development environments to do their work. This prevents them from overwriting each other’s work and stepping on each other’s toes.
It’s critical to keep the environments up to date with the solid packaged releases you learnt how to make in Phase I. By always providing your team with current development environments, you minimize the chances of errors and bugs.
You can now set your first steps on the path towards the continuous integration/continuous delivery (CI/CD) process. Along with setting up the necessary environments and keeping them up to date, you can also establish long-term and short-term development projects.
Because you’re no longer doing all the work in a Full Copy sandbox, you don’t have to wait for long project work to be completed to get smaller enhancements into production. Plus, you don’t have to worry about refreshing your—costly—Full Copies, because you’re performing the major units of work in isolated development environments.
At the intermediate level, it’s important to have a dedicated integration or merge environment where you pick up, test, and package the changes created in your development environments.
Now the full value of packaged releases becomes clear. Why? Because you can promote them forward to higher-level environments—UAT, staging—and ultimately, to production. On top of that, you can back feed them into development environments so everyone is up-to-date with the most recent build work.
At the expert level, you perform more frequent deployments that you manage more with automation and tools as opposed to manual drudge work.
The essential principles of the expert phase are:
Best-in-class organizations have some way to back up their deployment destinations. This allows them to quickly roll back changes if something unexpected happens. Usually, they leverage GitHub, Azure, or some other version control system to version and automatically deploy metadata and configuration data.
When you use a repository for version control, it’s easier to package changes there than in a Salesforce environment. The reason for this is that—assuming you’re using feature branches at this point—it’s easier to manage multiple inputs in a repository than in a Salesforce org.
Instead of performing all the deployments manually, best-in-class organizations automate them with a tool like Prodly DevOps.
Prodly DevOps allows you to automatically deploy all the changes required for a work item at once. That means both data and metadata! You can integrate to a version control system for source control and automatic versioning. Plus, it included prebuilt automations for major Salesforce Clouds that save you tons of time and work!
A best-in-class release management strategy involves CI/CD. Continuous integration sends verified packages into your long- and short-term production environments—and you can use automation for this.
Continuous delivery involves moving packages up the pipeline to your production environment. Using a staging environment, you can automatically deploy your packages as often as you like. By appropriately managing and testing the releases, you ensure that the work you push to production will have the desired functionality.
Best-in-class release management also calls for automated regression testing. Establish your testing plans and execute them automatically to avoid introducing bugs into production. The stronger your test plan is, the more you can rely on automated deployments.
If you adhere to the pointers in this blog, you’ll soon be able to progress from a basic release management strategy to an intermediate one—and eventually to the expert level.
At the expert level, it becomes incredibly important to have the right automation tools. We’ve already briefly discussed the capabilities of Prodly DevOps—but why not see them in action? Click here to schedule a demo!
It’s critical for Salesforce teams to have a best-in-class release management strategy to ensure they can deploy changes to production accurately, effectively, and without any bugs. In this blog, we discuss how to build a best-in-class release management strategy in three phases. You’ll advance from a basic strategy with manual deployments to an intermediate one with CI/CD and ultimately to an expert level with automation.
A basic release management strategy defines when and where changes are promoted from one Salesforce org to another. Release management is the practice of packaging tested and approved changes and then deploying them to production.
The principles of a basic release management strategy are:
Because this phase is foundational to building a best-in-class release management strategy, we’ll take a closer look at the components you need for it.
A release consists of verified changes made by Salesforce admins, developers, or contractors. Business users request these changes by means of work items. When combined, the changes in a release deliver an enhancement, new feature, or bug fix.
The most fundamental principle of release management is that the changes must be verified. So this means you must have a full understanding of what has changed and why—and the certainty that the change works as desired.
To verify changes, you need to have:
Note that there’s a lot of emphasis on documentation. This rigor is standard in software development, but generally lacking in Salesforce practice.
To see differences between orgs, it can be helpful to use a tool like Prodly. With our compare orgs feature, you can see everything that’s different in the development environment compared to the destination environment and generate documentation accordingly. That way, pieces of the release won’t be missed. In addition, you can easily identify which changes work and which didn’t pass testing.
Next, when you have verified the changes, you can package them together for a release.
Before deploying any changes, you need to define your packaged release deployment flow. In other words, you must decide how to move the changes through the various stages of development to production.
Also, determine how you’ll sync new work back down to lower-level environments. This gives your developers and admins a clear understanding of the impact of their work based on the ever-evolving state of production. In addition, it helps prevent the, “This worked in my Dev org, but it doesn’t work in UAT” conversation.
Each stage of development should have its own dedicated environment. As a result, it’s best practice to use feature branch orgs, which means using one scratch org or Developer sandbox per feature you’re creating.
Here’s what a basic release pipeline should look like:
All new work should go through the defined release path. However, no process is perfect, and occasionally, a bug makes its way into production.
When that happens, you can save yourself a ton of headache by having a clearly defined hotfix strategy. It’s like insurance. You don’t want to realize you’re not covered after you’ve been in a collision.
Create a dedicated hotfix environment where you can isolate the bug, fix it, and then sync it to all the in-flight orgs in your release path. Otherwise, you risk re-introducing the bug in the next release.
Some Salesforce teams use a Full Copy sandbox as their hotfix environment. However, this isn’t necessary. In contrast, with a good seeding strategy, you can recreate the components that matter in a scratch or Dev org and develop a fix there.
Using this strategy, you can build hotfixes without interrupting the rest of your release management flow. You can debug and fix a production problem in a targeted environment and push the components to production in an isolated hotfix release. Then you can share the hotfix to lower environments to ensure you don’t introduce the same bug again.
After you’ve established all the fundamentals discussed in Phase I, it’s time to move to the intermediate level. The main principles of this phase include:
At the intermediate level, give every team member their own up-to-date development environments to do their work. This prevents them from overwriting each other’s work and stepping on each other’s toes.
It’s critical to keep the environments up to date with the solid packaged releases you learnt how to make in Phase I. By always providing your team with current development environments, you minimize the chances of errors and bugs.
You can now set your first steps on the path towards the continuous integration/continuous delivery (CI/CD) process. Along with setting up the necessary environments and keeping them up to date, you can also establish long-term and short-term development projects.
Because you’re no longer doing all the work in a Full Copy sandbox, you don’t have to wait for long project work to be completed to get smaller enhancements into production. Plus, you don’t have to worry about refreshing your—costly—Full Copies, because you’re performing the major units of work in isolated development environments.
At the intermediate level, it’s important to have a dedicated integration or merge environment where you pick up, test, and package the changes created in your development environments.
Now the full value of packaged releases becomes clear. Why? Because you can promote them forward to higher-level environments—UAT, staging—and ultimately, to production. On top of that, you can back feed them into development environments so everyone is up-to-date with the most recent build work.
At the expert level, you perform more frequent deployments that you manage more with automation and tools as opposed to manual drudge work.
The essential principles of the expert phase are:
Best-in-class organizations have some way to back up their deployment destinations. This allows them to quickly roll back changes if something unexpected happens. Usually, they leverage GitHub, Azure, or some other version control system to version and automatically deploy metadata and configuration data.
When you use a repository for version control, it’s easier to package changes there than in a Salesforce environment. The reason for this is that—assuming you’re using feature branches at this point—it’s easier to manage multiple inputs in a repository than in a Salesforce org.
Instead of performing all the deployments manually, best-in-class organizations automate them with a tool like Prodly DevOps.
Prodly DevOps allows you to automatically deploy all the changes required for a work item at once. That means both data and metadata! You can integrate to a version control system for source control and automatic versioning. Plus, it included prebuilt automations for major Salesforce Clouds that save you tons of time and work!
A best-in-class release management strategy involves CI/CD. Continuous integration sends verified packages into your long- and short-term production environments—and you can use automation for this.
Continuous delivery involves moving packages up the pipeline to your production environment. Using a staging environment, you can automatically deploy your packages as often as you like. By appropriately managing and testing the releases, you ensure that the work you push to production will have the desired functionality.
Best-in-class release management also calls for automated regression testing. Establish your testing plans and execute them automatically to avoid introducing bugs into production. The stronger your test plan is, the more you can rely on automated deployments.
If you adhere to the pointers in this blog, you’ll soon be able to progress from a basic release management strategy to an intermediate one—and eventually to the expert level.
At the expert level, it becomes incredibly important to have the right automation tools. We’ve already briefly discussed the capabilities of Prodly DevOps—but why not see them in action? Click here to schedule a demo!
.png)