Salesforce Release Management ®

Best Practices Guide Salesforce Release Automation

Release Management is the process of planning, scheduling and controlling

a software build through different stages and environments.

Challenges in Salesforce Release Management

Multiple Release Environments: The code will have to pass through multiple environments, viz., SIT,
UAT, Stage, etc., before it is finally deployed in Production. Maintenance of these environments is a
challenge, especially with many manual pre-migration and post-migration activities that are involved at
each sandbox level.

Multiple Parallel Releases: There can be minor releases (config changes), major releases
(typically released once every quarter) and hotfix releases (for any business-critical issues that happen
simultaneously). Ensuring that the development and release environments are in sync constantly
across these releases is a challenge.

Complex Salesforce Orgs and Heavy Deployments: Salesforce environments are large and complex with large custom objects, profiles and
permission sets, and typical deployments contain a few thousands of members.

Environments Out-of-Sync and Challenges with Refresh: Since changes happen directly on Salesforce environments during releases, and
some of the BRs may not go-live to production – being rejected in the UAT/Stage – it causes the developer sandboxes, release environments and
production orgs to go out-of-sync. Frequent refresh causes developers to lose their work-in-progress as well as induces a lot of manual steps for
development teams.

Lack of Version Control: Since multiple development tracks happen in parallel, changes happen to shared metadata members, such as Custom
Objects and Profiles, often resulting in overwriting of code. It is not possible to maintain versions of changes, track them, and roll them back in the
Salesforce environment.

Best Practices of Salesforce Release Management

Designing the Right Sandbox Combination for
Your Release

It is extremely important to have the right sandbox compo-

sition for your release that caters to various release
phases.

Salesforce provisions Developer, DeveloperPro, Partial

Copy and Full Copy Sandboxes designed for various needs
such as development, testing, training, etc.

Setting Up Continuous Integration for Automated Deployments

For large enterprise teams, it is important to have version control set up so that teams can effectively collaborate, perform change analysis, roll-back
and also maintain isolation of code across multiple releases using version control branches.

Setting up Continuous Integration ensures that developers integrate their code as often as possible, which serves as an “early warning” system in case
of integration issues, so that issues are addressed at the time of the development stages itself.
1
® www.autorabit.com | info@autorabit.com Copyright © 2016 AutoRABIT
Modelling the Deployments Across Your Release Environments
It is the key to strategizing your deployment/Code Migration Plan across various release environments. Drawing release automation blueprint on how the
code will flow from Development to Production, where and to what extent version control is involved and what steps are automation driven enables
streamlined Release Management.

A sample release automation model has been shared here.

Publish Release Calendar

Preparing release schedules and communicating the release calendar for each phase of the release ahead of time for multiple stakeholders ensures that
all participating teams have complete visibility on the timelines and expectations.
It is also important to consider the Salesforce release timelines and keep them aligned with the project releases for better manageability of releases.

Sign-Off Every Release Phase, Not Just Production

The sign-off criteria at each release phase, and not just for production, ensures that the entry and exit requirements are met at each release phase and
serve as quality benchmarks.

Sanity of Release Environments

It is extremely important not to have direct access to release environments for defect fixes. Development directly fixing QA/UAT issues on respective
environments will not be auditable and are most likely to miss out in production deployment.
There can be very few exceptions like a performance fix that requires huge data and can be only fixed/verified in Stage sandbox or an integration that
involves the UAT sandbox with entire integration set up – but again exceptions cannot derive practices.

Pre/Post Deploy Operations Checklist

There are certain tasks that need to be done manually on release environments, mostly owing to Metadata/Changeset constraints from Salesforce.
The manual tasks, especially pre/post-deployments as well as pre/post-Sandbox refresh. Hence, it is required to maintain a migration as well as a refresh
playbook, so that release teams are well notified of all steps involved in deployments.

Regression Test Automation

As the complexity of applications grow over a period of time, it is required to have regression test automation enabled for the applications, so that the
change management is predictable and has faster release velocity.

2
® www.autorabit.com | info@autorabit.com Copyright © 2016 AutoRABIT
Best Practices for Version Control
There should be a single repository for applications with individual branches for
various Project/Developer Orgs and Release Sandboxes.

Need to have separate developer branches for minor and major releases.

Restricted access to Release Sandboxes, with all changes getting deployed from
Version Control for better governance and auditability.

No multiple entry points to Production Org (like deployments from master, as well
direct hotfix changes happening in Production). It can cause over-writing of
changes and hamper the efforts of the governance team.

Merge small, merge often. It is better to have one directional merge to reduce
frequency conflicts. Always merge instead of re-base.

Develop a maturity model that can drive towards Continuous Delivery of application
with Version Control, Deployment Automation, Data Migration Automation and Test
Automation to be able to spin up high quality environments at a button-click.

Best Practices for Continuous Integration

Maintain a Version Control repository.

Commit frequently as a developer. Developers should commit frequently – at least

once per day – several times a day. By doing so, developers will know the real-time
state and health of the software.

Integrate frequently; build the mainline on the Integration Sandbox.

Developers should integrate code changes frequently, so that integration doesn’t
become such a hard process. Once teams begin doing this, they should have the
Continuous Integration server building that main line.

Use a Central Binary Repository.

Automate deployment.

Regression Test should be done on a replica of production.

Best Practices for Salesforce Deployments

Run local tests in a deployment to a development environment, such as sandbox, by setting the RunLocalTests test level in the deployment options.
Running tests in a development environment gives you the opportunity to catch and fix any failures early and ensures a better deployment
experience to production.

Validate your components before deploying them by performing a deployment validation. A deployment validation is a deployment that is used only
to check the results of deploying components and is rolled back. A validation doesn't save any deployed components or change the organization in
any way.

Use recent validations that were successful in the past four days to perform quick deployments. Quick deployments are deployment of validations
that don’t run tests and help shorten deployment time to production.

Specify the tests to run by using the RunSpecifiedTests test level. This option enables you to run a subset of tests instead of running all tests in the
Org, cutting down on total test execution time.

3
® www.autorabit.com | info@autorabit.com Copyright © 2016 AutoRABIT
Best Practices for Production Deployment
Announce a maintenance window.

Stop all setup changes on production.

Back up the metadata that are expected to be deployed.

Have the roll-back strategy (fallback plan), just in case.

Considerations for Production Deployment

Ensure that planned Salesforce releases don’t impact your release. Schedule your release around Salesforce upgrades.

Ensure that tests run as part of a release.

Plan for the Salesforce Sandbox Preview. One month before every major release, Salesforce upgrades a set of its sandbox instances. All the
sandbox organizations that reside on these instances will have access to the upcoming Salesforce release. Use these sandboxes for regression
testing or trying out new functionality.

During Deployment Window

During a deployment window, you can use profiles to limit end-user access to the production organization.

Alert all active users about the maintenance window using email wizard. From setup, enter ‘Mass Email Users’ in the Quick Find box, then select
‘Mass Email Users’.

Create a profile to lock users out during the maintenance window by editing the login hours. Be sure that system administrators or integration
users have access, if they need it.

Roll out objects, tabs, and apps to different user profiles, if you want to allow some users’ access for acceptance testing.

References:
1. Release Management from Salesforce Community :
https://developer.salesforce.com/docs/atlas.en-us.200.0.dev_lifecycle.meta/dev_lifecycle/lifecycle.htm

2. Salesforce Limits :
https://developer.salesforce.com/docs/atlas.en-
us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm

3. AutoRABIT CI :
http://www.autorabit.com/powerful-salesforce-continuous-integration-with-autorabit/

4. AutoRABIT DataSheet :
http://www.autorabit.com/wp-content/uploads/2016/05/Datasheet-2.pdf

4
® www.autorabit.com | info@autorabit.com Copyright © 2016 AutoRABIT