®

Salesforce Release Automation

Salesforce Release ManagementBest Practices Guide

Release Management is the process of planning, scheduling and controlling a software build through different stages and environments.

Challenges in Salesforce Release Management

Best Practices of 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.

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 DeploymentsFor 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.

info@autorabit.comwww.autorabit.com | Copyright © 2016 AutoRABIT®

1

Modelling the Deployments Across Your Release EnvironmentsIt 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 CalendarPreparing 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 ProductionThe 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 EnvironmentsIt 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 AutomationAs 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.

info@autorabit.comwww.autorabit.com | Copyright © 2016 AutoRABIT®

2

Best Practices for Version Control

Best Practices for Continuous Integration

Best Practices for Salesforce Deployments

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.

info@autorabit.comwww.autorabit.com | Copyright © 2016 AutoRABIT®

3

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.

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.

Best Practices for Production Deployment

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.

info@autorabit.comwww.autorabit.com | Copyright © 2016 AutoRABIT®

4

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.

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