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.
Phase I: Basic Release Management Strategy
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:
- Set a release schedule and build packaged releases of verified changes.
- Establish roles and responsibilities for production releases.
- Establish testing and approval standards.
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.
Verified Changes
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:
- Well-defined and documented work items
- Test plans to ensure the changes accomplish their intended purpose
- Regression test plans to ensure the changes don’t break existing functionality
- Fully-documented configuration changes
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 DevOps. 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.
The Packaged Release Deployment Flow
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.
Here’s what a basic release pipeline should look like:
Create a Dedicated Hotfix Environment
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.
Phase II: Intermediate Release Management Strategy
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:
- Align with the “environment per feature” strategy as part of release management.
- Establish release paths for long-term and short-term development work.
- Start using an integration testing or merge org to package releases.
A Current, Dedicated Environment Per Team Member
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.
CI/CD Process
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.
Integration or Merge Environment
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.
Phase III: Expert Release Management Strategy
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:
- Integrate with source control for the ability to roll back changes to a previous state, as well as for an automatic audit trail.
- Package releases in your repository.
- Automate the deployments throughout the pipeline to production.
Version Control
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.
Package Releases in Your Repository
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.
Automate the Deployments
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!
Continuous Integration
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
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.
Regression Testing
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.
Conclusion
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!
