Setting up a better Salesforce release management process takes time. A phased approach includes basic source control, continuous integration, testing, and Salesforce DX.
With this article, learn about the phased approach to Salesforce release management, starting with basic source control and moving towards continuous integration, testing, and eventually Salesforce DX. I also learned about the challenges of implementing DevOps in Salesforce and how tools like Blue Canvas can simplify the process.
Here are our 5 Key Takeaways:
1. Basic source control is essential for any Salesforce development team to prevent major catastrophes.
2. Continuous integration and sandbox management can improve deployment safety and dependency management.
3. Automated testing is a worthwhile investment for any team that has successfully implemented Phase 2.
4. Salesforce DX is a key part of Salesforce's future plans, but implementing it requires a solid foundation in CI and source control.
5. Tools like Blue Canvas can simplify the DevOps process for Salesforce development teams.
FREE TOOL
Profiles & Permissions Deployer
Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.
Get Started
Made with love by the Blue Canvas team ❤️
We talk to Salesforce development teams at every end of the spectrum. Some are super lean ISVs who have migrated their process over to Salesforce DX. Others are just getting started with Ant scripts and source control. Others still have never heard of source control and are just looking for a simple way to improve their release management process. Across all teams there seems to be a universal rule: setting up a better Salesforce release management process takes time.
Software development teams everywhere struggle with DevOps. It’s why there are countless white papers and dozens of CI companies trying to supplant Jenkins. Even the most elite teams like those at Google invested vast amounts of time, energy and resources into setting up a software development life cycle that works.
Unfortunately, Salesforce doesn’t do any favors for making this process easier. Setting up CI and source control for Salesforce poses unique challenges. This is largely because of Salesforce’s strengths: it’s declarative interface and friendliness to a wide variety of developer and admin profiles.
Moving to CI/CD is also hard because it’s not just a simple solution. It requires training and the formation of new habits. It’s a process. And implementing new processes does not happen overnight.
Since, many of our customers are turning to us looking for Salesforce best practices , we thought it might be useful to talk about the phased approach that our most successful customers have adopted.
Phase 1: Basic Source Control Many teams have no metadata backup or source control in place. This is a big deal and should be treated as an emergency. If you don’t have any kind of metadata backup in place, what will you do if a developer overwrites another’s code? What will you do if you release a bug and need to rollback to production. Getting a basic metadata backup solution in place is phase 1 for any Salesforce development team. With metadata backup you can rest assured and know that your team is safe from major catastrophe. It will let you sleep better at night.
It’s also a good starting point because it’s relatively easy to setup. With tools like Blue Canvas, you can actually have your metadata backed-up in minutes. It’s a four click process . There is no training required. There are no process changes you need. So you can get the benefits of backup and safety without having to ask your team to learn a whole new flow. Ideally this backup would be real time as it will allow you to revert to previous states.
Phase 2: Continuous Integration Once you have your metadata continuously backed up in Git, you can address a more complex part of your development workflow: sandbox management and continuous integration. This step requires a bit more training and so will take a few months to perfect.
The goal in this phase is to end code clobbering and use a source control tool for development. No longer should developers blindly push code from one environment to another. They should be able to confirm that changes are safe before pushing. And all changes should be fully part of a logged system that you can use for debugging and rollback.
In this phase, it makes sense to think more about how you want to set up sandboxes for your team. Our most successful customers end up with a model where each developer has their own dev sandbox . They then continuously push small changes to a staging sandbox called UAT. They are also frequently pulling down changes that others are making on UAT into their development sandboxes. Ideally they are pushing and pulling multiple times a day. This kind of small, granular change pattern makes deployment much safer and dependency management much easier.
This requires active work on the part of your team - migrating away from Ant scripts and change sets and towards a Git-based, pull request model. Though not conceptually all that different, it will take some time to learn the flow and train people to be disciplined about using the process and not deviating to do ad-hoc changes. (Fortunately, Blue Canvas automatically pulls any ad-hoc changes into Git so you never deviate too far from your flow).
Blue Canvas can simplify this Git based release flow so that you don’t have to do too much training.
Phase 3: Testing Automated testing is a key component of any CI flow. Many times, developers come to us and want to implement testing right away. But there are some pitfalls. First of all, it takes time write good tests. And there is still low hanging fruit - using source control for metadata backups and pull requests for deployments - that can be had before that takes place.
Second, testing can be quite slow. Unit tests can take hours. You want to make sure that all of your tests are written in a way that are fast to complete and likely to pass so that you don’t slow down your deployments.
However, once you have a good CI flow working as discussed in Phase 2, it makes sense to invest in developing automated tests and bringing them into your deployment process.
This might look like a mix of automated unit tests that run each time you push to your integration environment. Or it might be supplementing your unit tests with Selenium tests like our friends at Provar Testing do.
Automated testing improves the quality of code while allowing you to move faster and it is a worthwhile investment for any team that has successfully implemented Phase 2.
Phase 4: Salesforce DX Salesforce DX is a key part of Salesforce’s future plans. Bringing your team in line with that is certainly a priority. However, DX is still new and has a ways to go before it’s fully complete. Furthermore, DX is not a product but rather a development paradigm. Adopting that paradigm will take some time. If you have a legacy app, it will be difficult to get DX to work because there are different packaging and directory structures.
However, once you do implement CI and automated testing with your source control, you are now in a position to look at what DX has to offer. The newly released concept of scratch orgs makes feature branching a possibility in Salesforce for the first time. This is a big win and will make your team more productive as they can multitask and address different features and bugs in parallel.
Working with Salesforce DX and scratch orgs is a great way to finalize your Salesforce development process and ensure that you are aligned with the stated direction of Salesforce as it heads into the future.
Conclusion Salesforce development best practices take time to implement. However there is low hanging fruit to be had. We recommend starting with that low hanging fruit and then pushing forward with other changes from there.
