Streamline Your Deployments

We had a release to production last night, and I marveled at how smoothly things went compared to the first release we did as a team. In this post, I’ll outline the critical components of building a successful release package.

1. Documentation

Before you even start work on features or bug fixes, have a system in place to document what is being asked for and how it will be used. We have a custom built set of objects in Salesforce to track this. Each feature or bug fix is assigned to a release and sprint and status is tracked as it moves through the process. We also add metadata as a related list to the features so we know what was changed. I’ve written some code that builds a package.xml based on all the items in the release. We use this package.xml file during our deployments.

2. Development Environment

Each person making changes that will go into the release should do their work in their own sandbox. By staying in your own sandbox, you have  no danger of overwriting someone else’s changes.

3. Version Control

Using version control ensures you can easily track changes back to a person and a feature request. We use a repository on Github that contains a complete snapshot of metadata. Each feature request goes in a branch that will get merged.

4. Continuous Integration

Before a feature gets merged into the release branch in Git, we test each one with CI. We use Snap-ci to do our CI. When a pull request is created, Snap does a validation build and runs all unit tests to make sure nothing is broken. If the change breaks the build, we know about it early and can fix it before it gets merged and sent on to users for testing.

5. Deployment Tool

All deployments are performed using the Ant Migration Tool. This allows for creation of a release package will all the metadata in it that we can deploy again and again to different sandboxes. We test the deploy at least three times before releasing to production.

6. Sandboxes

We use a lot of sandboxes when preparing for a release. Below are a few of the main sandboxes we use.

Staging – this is a config only sandbox used as the target of our CI process.  This sandbox is also used for user demos and basic testing by the development team.

UAT – this is a full sandbox that we use for user acceptance testing. We deploy from Staging to UAT about 2 weeks prior to the release to give users enough time to test and sign off on the changes. Important: if a user group doesn’t sign off on a change, we will pull their feature from the release.

Backup – this config only sandbox is created a day before the release and serves as a complete backup of the org’s metadata. It is easier to create a sandbox than doing a backup using Eclipse, Ant, or MavensMate. This sandbox is used in case we need to review how something worked prior to the release (aka, did that break with this release?). We can also restore quickly using change sets from that org if things go horribly wrong.

7. Quick Deploy

A recent feature Salesforce added is Quick Deploy. This allows you to do a validation deploy to production during which all tests are run. If it validates, you can click on the Quick Deploy to deploy the changes to production without having to run the tests again. The day of the release, we validate the package against prod and then wait for the designated release time to click the Quick Deploy button. This saves us so much time.


6 thoughts on “Streamline Your Deployments”

  1. Thanks for providing this write up. I’m curious how you are handling flows and processes in your code repository. Each edit of one of these creates a new version with a new metadata file name and each sandbox has it’s own independent version numbering. Are you doing something to strip off the version number before committing a change?

    1. Flows and processes have been a thorn in my side. I don’t include them in my repo, mostly because the CI build process fails if the flow is active in the target org.

Leave a Reply