Got ever ready Code-Base? Achieving Frictionless Continuous Integration on Salesforce
So you had a successful Salesforce implementation, the users are loving the Cloud, demand for new features and improvements are pouring in. Your engineering team is growing, managing a development cycle and moving features using Change Sets has become an ordeal. Soon the release nights turn into a nightmare. How many organizations can relate to this?
I was facing a similar situation at a client where releases happened the day after Sprint end, usually ending every other Wednesday, the task of creating a changeset was getting hectic. Developers scrambling to get components bundled for a deployment, release days were the worst days but now we drink champagne every other Thursday.
How did releases become so comfortable for us?
Thanks to Continuous Integration (C.I.) and Continuous Delivery (C.D.). In software engineering Continuous Integration/C.I. refers to the practice of merging the working copies of all the developers’ changes into a shared copy of code-base using a Version Control System (V.C.S.).
This shared working code-base is often compartmentalized to represent different stages of the development life-cycle, for example; a “Dev” branch may contain any in-flight changes that are yet to be tested. “Feature” branch could represent a certain release or feature which is ready for testing while the main “Master” branch can represent the actual code-base in production. The branch names can be anything, given checks and balances are in place to ensure all the changes to the code-base are building at all times which is done through a combination of Pull Request (PR) and CI as shown below.
The same shared copy of code can be used to deploy to production or testing environments in an automated fashion, this is called Continuous Delivery/C.D.
At a high-level, there are 2 major steps towards setting up a Continuous Integration process.
1. Setup a source code repository.
The Version Control System (V.C.S.) recommended here is Git which will serve as the source code repository storing your Salesforce Org’s source code in the SFDX project format. This code repository should be the single source of truth for all working customization in the Production Org.
Even determining the changes going in the release can be gathered from the log entries of changes made to the code repository since its last release, called the commit logs.
It is important to note that instead of the traditional Org based development model, where development is done in sandbox/developer orgs then source code is pulled from such orgs to be stored in the metadata API format, a package based development model is recommended using the SFDX project template and scratch orgs. That being said, moving away from the org-based development model doesn’t mean that you don’t still need proper environment management, its just the developers’ org are replaced with scratch orgs while the validation, testing, and UAT continue to happen in their dedicated sandboxes.
Why Salesforce DX project?
SFDX project provides a module-based development on Salesforce facilitating the separation of concerns by reducing the number of shared files that are touched between features.
For example, a metadata API source format project requires a package.xml file containing all components to be deployed, also called the package manifest. Moreover the “.Object” files in metadata API format code stores all the custom fields of an object in a single file. Consequently, whenever a new field or component is added, such shared files are modified by every new change. By avoiding common files in a project we avoid source code merge conflicts between 2 developers.
By using the SFDX project, not only we reduce potential conflicts during development, but also every developer contributing to an SFDX project uses a Scratch Org, separating the development environments of every feature built and preventing any overwrite due to development done in a shared environment following a traditional Org based development model.
SFDX makes uses of the Salesforce CLI for updating development environments while Org based model requires a C.I. with ant based migration tool or changesets for updating other developers Org with the latest changes.
Contrary to a popular belief that SFDX projects can only be used for deploying to scratch-orgs and is geared towards package based development, an entire Production Org’s source code can be maintained in a single SFDX project which can be used to deploy to any Non-Scratch org by converting the SFDX format code into a metadata API format during the deployment process.
Whether you are starting an SFDX project from scratch or already have a source code setup using a metadata API, Salesforce has excellent documentation on how to create or convert a code repository.
2. Setup a C.I. tool to manage the code merge process/Pull Request.
Once you have the code repository set up, the next step is to create a process to allow developers to contribute to the code-base which does not introduce any breaking changes. This can be insured by a combination of test case runs and automated deployment validation called the “build”, before and after the developers merge their code-base to the project.
A peer code review before the code is merged is also essential to prevent any regressions along the way.
At the very least, any changes that are not passing a deployment validation and test case runs should not be allowed to merge to the project.
Proper test case run and deployment validation is the most important step in the C.I. for maintaining the health of the code-base, which needs to be followed with discipline by all the stakeholders of the code-base. Making exceptions to this process just for quick wins will cause error exceptions in build down the line, something to keep in mind.
C.I. tool such a Jenkins, Bitbucket pipelines/Bamboo, CircleCI, etc, can be used to facilitate all the above to make sure only a working copy of code changes is merged to the production branch. Once again Salesforce documentation has step by step guide on how to set up a C.I. infrastructure of your choice.
Conclusion
“When your code base is ever-ready to be deployed then you have more time to focus on change management, logistics, announcement of the release.”
A growing CRM team can re-gain productivity by reducing friction between the development life-cycle and avoid last-minute chaos on release days, by maintaining a single source using of truth of all its Salesforce customization and having any new changes validated before ready for testing, demo or release purposes through automation using C.I. Here I discussed the design patterns to be used in a Salesforce C.I. system which separates the concern between each development cycle and the developers while making sure the code-base is ready to be released at any given time. When your code-base is ever-ready to be deployed then you have more time to focus on change management, logistics, the announcement of the release.
