Salesforce DevOps: Learnings from 300+ Salesforce Deployments

DevOps is a set of practices that combine software development and IT operations, with the aim to create a collaborative approach between historically siloed teams. DevOps adopts many Agile principles, and enables teams to standardise, automate and ultimately deliver projects faster, at scale.

DevOps gives us the flexibility to make deployments from anywhere; Developers can even review and approve deployments using mobile devices. We can deliver a quality product by executing automation suites and ensure code quality is maintained by integrating with code analysis tools.

Salesforce is a cloud-based platform, meaning we can make changes directly in the production environment, however this is not recommended! To ensure success, Salesforce development must follow the basic development lifecycle of develop, test, and release.

In this blog, I will talk about my experience of using DevOps with Salesforce to deliver successful projects. We will cover typical implementation models, as well as how to choose the right deployment mechanisms and the importance of version control.

1. Salesforce Deployments are Time-consuming

During my 4 years of development on the Salesforce platform, working on 7 different projects and performing a minimum of 1 deployment per week using different tools and in multiple environments, it became evident that development doesn’t mean that we build something and the job is done!

Around 20% of my time as a developer has been spent on deployments (moving changes from development to production) which seems like an awful lot of time that could be better spent elsewhere.

2. Learning Deployment Models is Essential

Why does deployment take so much time? The answer lies within the lifecycle of project implementation. Typically we have at least 3 environments: Development, QA, and Production, however it’s not unusual to see far more complex deployment models with additional environments.

Let’s take a look at a few typical deployment models you can expect:

Preliminary Model

This model is used where there is little platform customization required and many of the customer requirements can be met using Salesforce “out of the box” features.

Entrenched Model

This model is widely used in Service industry projects where there are complex development needs.

Sophisticated Model

This model is used on complex implementations for large scale enterprises.

1. Generally, the standard operating procedure (SOP) is for a developer to build functionality in a developer org, then deploy to QA for testing.
2. After the QA signs off, the developer moves his changes to UAT for business users to test.
3. Once a business user signs off, it is then moved to Preprod. The Preprod environment is used to reproduce and fix critical bugs reported in production.
4. If no issues are found changes are deployed to Production. Business Verification Testing (BVT) is performed in production on an as needed basis.

In our final deployment model example, the developer deploys changes to 4 different environments. This can equate to as much as 20% of working time spent in deployments.

3. Choose a Salesforce Deployment Tool

Salesforce provides us with multiple ways to deploy changes including:

• Change Sets
• Force.com IDE (depreciated)
• ANT Migration Tool
• Salesforce Development Experience (SFDX)

Initially I used Change Sets, however, I found that they were time consuming and must be repeated for each deployment. If you forget to add a component to your Change Set, you must go through the process again, which can be very frustrating.

After researching the various options, I selected the ANT Migration Tool as my preferred method, which has many additional benefits as shown below.

4. Version Control Systems are Must-have Tools

In addition to choosing the best deployment tool, we should also consider Version Control. Version Control is keeping track of the changes made to the code; if there are any issues, version control helps us to compare the code base with the previous version, then locate and fix the issue.

The tools used to version control the code base are called Version Control Systems (VCS). There are many VCS tools available such as Git, Bitbucket, Gitlab, and Perforce.

Why is VCS a must have tool?

• If you are working in a team, then managing inevitable code conflicts is a headache. VCS gives you the ability to handle mergeconflicts with ease.VCS works as a backup. If certain components get deleted from our environment by accident, VCS can be used to recover them.
• Before VCS, versioning was done by taking a backup of the code base after every release and storing them as zip files. If there is a bug in a new release, comparing code base using zip files is not an easy thing to do. VCS makes it much simpler.
• VCS gives the ability to do peer reviews. Team members can easily review each other’s code and give feedback to improve code quality.
• VCS also has the ability to control who can make changes to the code base by granting / revoking permissions to users.

Summary

By choosing a suitable deployment tool and implementing version control, you can expect to see multiple benefits. Personally, after implementing these best practices, I experienced:

• Time spent doing deployments was reduced to less than 10%.
• It gave me flexibility to work on proof of concepts in my developer org and then migrate to a sandbox using ANT.
• Version Control Systems improved code quality by facilitating code review, controlling changes to the code base, and providing an easy way of comparing code bases.
• VCS is now the source of truth for my code base.

By using all these learnings, I was able to design an effective DevOps solution, making my deployments more robust.