While small and incremental deployments of features to a Salesforce production org are best practice, there are times when multiple, or large areas of functionality must be released simultaneously. Accordingly, a large-scale Salesforce deployment can invoke a high degree of ambivalence among the team involved in its preparation. On one hand, there should be a great degree of excitement. Chances are the functionality you are preparing to implement will alleviate pain points in your existing org, or perhaps greatly simplify existing workflows. On the contrary, it’s also quite normal to feel a degree of anxiety. Large-scale Salesforce deployments merit significant planning and attention in order to ensure a successful rollout. In those situations, proper steps should be taken to minimize disruption of the production environment and operation. With these practices in place, you can help to ensure that any deployment is truly successful.
Large-scale Salesforce deployments merit significant planning and attention in order to ensure a successful rollout.
Thorough end-to-end testing
Often times, end-to-end testing may be neglected in favor of unit tests, to focus on specific details. Ensuring that proper end-to-tend testing of the features entailed in your deployment has been conducted should make you feel much more comfortable about user experience post-deployment. For added benefit and confidence, this testing should be completed by the impacted user groups.
Testing corner and edge cases
Salesforce deployments require that code being deployed to production have tests that provide 75% code coverage. While this is often covered by granular, code-based unit tests, applications that are business-oriented should also be subjected to efficient, yet thorough end-to-end testing. This is to ensure that the integrity of complex business processes is maintained. These tests are typically conducted by users, rather than code, which allows for the detection of potential user-experience issues. Accordingly, upon ensuring that proper end-to-end testing is conducted, you should feel much more comfortable about user experience post-deployment.
Testing in a full sandbox
The Salesforce platform’s multi-tenant architecture means that there are significant limits that must be accounted for when developing custom applications. Some of these limits can only be tested with large amounts of data. As such, it is invaluable to ensure that your user acceptance testing is conducted in a full sandbox environment. This is particularly important, as it is the only environment which supports performance and load testing. Moreover, it allows your testing environment to be a complete replica of your production org – encompassing all data (including metadata), object records and apps. While the cost of a full sandbox may make your team hesitant, it is entirely justified with the invaluable test coverage provided. This in turn greatly lowers the risk of post-deployment issues, and accordingly results in saving the time and costs associated with encountering such issues.
Making a copy of the existing production environment, if applicable
Version control tools, such as Git and Subversion, are an excellent way of capturing the state of an org’s codebase through each release. If you do not have a version control system in place, having a backup copy of the existing production environment, through a sandbox refresh prior to deployment, allows for the capability of swiftly rolling back to the previous system in the event of a critical deployment issue. Additionally, you should be sure to schedule weekly Organization Data Exports to ensure that all of your Org data is backed up on a consistent basis.
Ensure resources are on standby for resolving issues that arise
While you certainly want to feel confident that your deployment will go off without a hitch, it’s invaluable to have resources readily available to handle any issues that are reported. To take things a step further, it is even more beneficial to proactively discuss a triaging plan with your team – such that you know precisely who would handle different types of issues.
Establishing formal go/no go plan prior to the release, and setting a firm timeframe for making that decision
When initially completing a deployment plan, one of the most crucial dates to set is when to make a formal “go/no go” decision with the team. This should be assessed in a meeting that includes all parties involved in the deployment. Prior to this meeting, it’s imperative to outline all facets that should be taken into consideration, separating the truly critical components from areas that can be refined beyond the designated “go/no go” date, or potentially after deployment.
There are also a few additional steps that are important to consider. You’ll want to develop some comprehensive communication to be distributed to the user base, detailing the new functionality. It’s also greatly beneficial to offer any training that may be necessary. Finally, you’ll of course want both your development team and business stakeholders to verify the changes in production upon deployment.
It is inevitable to feel some of the inherent anxiety that comes along with a large-scale deployment. However, upon following the practices outlined above, your team should feel truly confident that you have comprehensively covered all areas and are headed towards another successful release.