The riskiest point of any development project is when your work is ready to be deployed. Naturally, things don’t always go to plan. But teams can seek solace in the fact that, while failed deployments are nerve-racking, they’re typically caused by the same issues that crop up time and time again. In this post, we look at several best practices that teams can follow to reduce the risk of hitting any unexpected issues when deploying — and make them easier to resolve if they do.
Prepare well for any deployment
It goes without saying that preparation is one of the most important factors for a successful deployment. Many teams consider it a best practice to keep a deployment checklist of changes made and how they’ll need to be deployed. Keeping this checklist updated throughout the development life cycle encourages developers to be thinking about how the deployment will happen, as well as any checks they need to be making before releasing to the production environment.
Agreeing an achievable goal and creating a timeline for releases will make sure everyone is involved at each stage and the team shares a sense of ownership for deployments. This will also help with collaboration and encourage input from the whole team from the beginning.
It’s also essential to manage your environments by refreshing sandboxes or syncing with production — this helps to smooth any bumps when you come to project releases.
Practice deploying to sandbox orgs
A sandbox or separate playground is a great place to practice deployments with the reassurance that you’re nowhere near production. While it’s easy to refresh a broken sandbox from production, recovering from a similar situation with a live environment is likely to be much more work. Use sandboxes to learn how to recover from failures and to work out how to improve things.
If you’re using Gearset, then validating deployments and initiating problem analyzers will also give an added layer of protection by knowing what will (and won’t!) work in the production environment ahead of time.
Avoid developing directly in production
Another best practice for pain-free deployments is to use a multi-org approach for Salesforce development and steer clear of developing straight into production. Using a mixture of sandboxes, development and testing orgs will allow you to spot issues before they cause problems in your live environments.
Sandbox environments are copies of your Salesforce org that can be used for testing or training. Having a completely separate test environment can be great for seeing how your changes or customizations will work when they reach your production environment.
Once you have your preferred set-up in place, make sure your Salesforce environments are always synced to your production org and adopt some basic sandbox management practices. Running regular sandbox refreshes and back-promoting from production (or your VCS) will keep everything as closely synced to production as possible — meaning you’re better able to test how your changes will land once you’ve released, which should mean you’re less likely to run into errors or cause a regression.
Get full visibility of the deployment process
A lack of visibility is one of the real challenges of deploying on Salesforce using native tooling like change sets. It’s hard to keep track of what changes you’ve made — and which dependencies will need to be deployed with them. And while you’re bundling up a change set there’s zero insight into how this will impact the target org. Gearset’s compare and deploy workflow is a gamechanger for Salesforce teams, as it shows exactly how the metadata differs between environments, and what the deployment will do to the target org.
Visibility into the deployment helps you include all the right dependencies, avoid forgetting changes, and have confidence in the process. Gearset’s metadata comparison is also what makes it possible to do full and partial rollbacks, and to get recommended fixes from its problem analyzers.
Test your deployment packages
Testing is critical in any release process and there are many kinds of testing that can be carried out before releasing to your production environment. Of course, Salesforce requires you to have at least 75% of your Apex code covered by unit tests before you can deploy your code to production environments. But only measuring code coverage is a poor indication of how effective a particular test suite is, and scrambling to reach a particular level can result in poorly-designed tests written to meet the coverage requirement rather than because of their value as tests. So it’s important to write tests that genuinely confirm whether classes execute as intended.
Alongside unit testing, it’s important not to skip over other types of testing. Quality assurance (QA) relies on testers finding defects that aren’t easily uncovered by other tests, such as a button that can’t be clicked or a broken link. QA testing acts as a safety net against the release of unfinished or ineffective updates and changes.
User acceptance testing (UAT) is generally the last test carried out before your changes are released to your production org. The goal is to find out whether end users feel the changes are meeting their needs and match their feature requests. This type of testing is usually performed in a sandbox or UAT environment by the end users and is tricky to automate because it relies on human interaction and emotion.
Watch our webinar to discover how testing can play a part in speeding up your Salesforce deployments.
Track and monitor your orgs
Even with a comprehensive audit trail of the changes you deploy to production, you won’t necessarily catch rogue changes made directly in production. How long would it take your team to notice if a hotfix had broken a field or a checkbox had been deleted?
As mentioned, it’s best practice to avoid making changes directly in your production environment unless absolutely necessary. But, sometimes a teammate will skip the proper development and release process, either because they think the change isn’t that risky or because they’re making a hotfix. In either case, you really want to know when that has happened as soon as possible so that if things do go wrong, you can fix them quickly.
Deployment reporting is a good way to track what’s been deployed, by who and when. With Gearset’s change monitoring, you can set up deployment notifications to alert you when a deployment has been successful and jump into the app to see all the granular details on the org monitoring dashboard.
Use a version control system
Teams who are reaching deployment stability and thinking about the next steps of DevOps adoption will probably be considering using a version control system (VCS). Adopting a VCS is considered best practice for keeping track of changes and establishing a single source of truth. There are a few things that might sway your decision on which one you choose, such as security considerations or whether you choose to adopt CI/CD.
There are many types of version control out there, but Git is the de facto standard for Salesforce. Git provides teams with the ability to separate out multiple streams of development and avoid stepping on each other’s toes by making changes in isolated branches, instead of in shared sandboxes. Teams looking to continue their DevOps journey by adopting CI/CD can’t do so without first implementing a version control system.
Implement an automated CI/CD pipeline
Once you’re running reliable and repeatable deployments and happily using version control as your source of truth, best practice would be to start automating your deployments using CI/CD. Introducing a Salesforce CI/CD solution into your workflow might sound like a daunting mountain to climb but it doesn’t have to be. And, once successfully implemented, teams reap incredible benefits including: fewer bugs, reliable releases, faster delivery to end users, and agile working.
Releasing continuously in smaller chunks will lower the risk for each of your deployments — breaking something small is much easier to unpick and fix than something that has been months in the making. To be successful, CI/CD needs the whole buy-in from the team, which can be the trickiest step of adoption.
Understand the limitations of Salesforce’s Metadata API
Teams can run into issues when deploying to Salesforce because of the limitations of Salesforce’s Metadata API (MDAPI). While most of the changes teams want to migrate can be deploying using the MDAPI, not all metadata types and configuration options are supported.
The MDAPI also has a few usage limits, but these typically affect only the largest deployments since it’s possible to retrieve or deploy up to 10,000 files at once.
Introduce deployment process governance
Having a strict governance process in place, especially in a large enterprise, gives teams the confidence that they’re protected with guardrails while they’re deploying.
To make sure your Salesforce governance framework is being followed, a dedicated tool like Gearset provides traceability and visibility to promote a consistent and compliant process. It’s especially helpful when you need to download things like auditing reports quickly. Having these practices in place gives teams control and accountability while also allowing the ability to delve into insights like the biggest risks and priorities.
Implement a quick restore procedure
Salesforce orgs need backup. There are a number of reasons for Salesforce data and metadata loss — Salesforce outages, human error or even malicious deletions from a disgruntled employee. But deployments can also cause problems that lead to data loss.
If you lose Salesforce data or metadata and need to restore your orgs, the likelihood is that you’ll be acting under pressure and not making your best decisions. Implementing a robust recovery plan now means that you’re ready for when the worst happens. It’s worth remembering that the backups are only as good as your ability to restore from them.
Encourage the team to use the same tools
Many teams hit bumps in their deployment process because of a clash over the team’s preference of tool. It’s common for teams to use a mix of the tools offered by Salesforce — Ant migration tool, Salesforce CLI (DX) or change sets — as their personal preference of deployment tool, but using a combination of different methods can be confusing and difficult to track when lots of admins and developers are working together.
It’s best to get the whole team aligned by introducing a solution that works for everyone. Gearset is designed to delight both developers and admins, which means that the entire team can collaborate easily on building deployment packages, tracking changes, managing automation jobs and monitoring for issues — all in the same UI. This reduces manual errors, saves time, and promotes consistent and reliable deployments across the whole team.
Take the pain out of Salesforce deployments
Whether you’re just starting to deploy reliably or you’re already on your way to building an automated deployment pipeline, following these best practices will make releasing to Salesforce as painless as possible.
Many Salesforce teams struggle with deployments that fail half the time. But Gearset’s users have a deployment success rate of 97%, as the platform is specifically designed to help you solve Salesforce deployments. And it doesn’t just help you achieve repeatable and reliable deployments every time. As a full-featured DevOps platform, Gearset will help you add version control, CI/CD and backup seamlessly into your workflow. To see how you can achieve seamless and pain-free releases, start a free trial of Gearset today. You can also download our whitepaper on simplifying release management for Salesforce:
