One unique thing about Salesforce development is that there is no local environment, unlike other software development. You cannot make the changes in your code and see them right there on your machine; the code must be deployed to at least one org whether it’s a sandbox or a dev org.
The problem arises when a small team is working on the same org, and managing every bit of code starts to become a challenge. Here you are left with a few choices, most of which include buying an expensive CI/CD solution. This post will focus on a solution for the aforementioned problem, which can be implemented quickly and won’t cost you any money.
1. A Brief Intro to Version Control Systems
A Version Control System is a software that helps with tracking changes in code. GitHub is the most prominent example of a Version Control/Source Control system. It helps with keeping track of all the changes that were ever made to the code so that information loss is eliminated.
2. What Is Bitbucket?
The first step involves using the Version Control System. Bitbucket (just like GitHub) is a code repository hosting service from Atlassian, and we can create as many private repositories as we want with a free account.
Sure, we can push the code directly from the Code Editor to the target org. However, having the code and its multiple versions in Bitbucket (or Git) is many times safer, is a standard practice, and will also act as the base of our DevOps process.
Now, we can go ahead and use the pipeline feature from Bitbucket. One repository can have one pipeline configured using a yml file; a yml file is where we let the pipeline know what to do when there are changes in a particular branch of a repository.
3. Bitbucket Uses Docker Inherently
Pipelines in Bitbucket are used when we want to perform an action on code change in the repository. They are highly configurable as we can specify different routines to be executed on changes to each branch of a repository. To execute the steps that we describe in our yml configuration file, Bitbucket uses Docker. Docker is a service which delivers software packages as a container. These containers are the entities whose compute power is used by Bitbucket pipelines to execute the commands written in the yml file.
Each pipeline’s yml file has a standard docker image attached with it, whose instance is created as a container on Bitbucket’s infrastructure (Bitbucket’s cloud servers) to perform the actions mentioned. We can leverage this to our advantage as, if we specify an image with SFDX CLI installed, we can use that container to move our code from Bitbucket to the target org.
4. Use Docker Image to Deploy From Source Control to Org
Salesforce provides their standard image on Docker Hub with SFDX CLI installed. We can use this image as our base image in the yml file for our pipeline to deploy changes to the target org. All we need to do is set up the authorization to deploy the code — for that we will need to set up a connected app and use the “sfdx force:auth:jwt:grant” command’s authorization flow.
Getting to this point means that we just need to add deployment commands in the yml file — then this whole flow will start working and moving the changes from the repository to the target Salesforce org. The pipeline works at this point, but there is one crucial optimization that needs to be added to make this solution efficient and dependable.
5. Use the Sfdx-git-delta Package From Npm to Push the Changes
If we deploy manually using SFDX commands, we have an option to select which components to deploy. But automated systems cannot do that, hence we need this package to be integrated with our pipeline flow — this is the final piece of the puzzle.
The standard SFDX CLI installed Docker image that Salesforce provides can be extended to build things on top of that (the same for all images available on Docker). The extension required for this pipeline to work is the “sfdx-git-delta” npm package.
Now armed with the power of this new image, we can deploy the “delta” from the last push — in simple words only the components changed, as compared to the last push to Bitbucket repository, will be deployed to the target org.
Summary
This process is an excellent option for a Salesforce DevOps pipeline for two reasons. First, and most importantly, it is free and not every team/project can afford enterprise solutions. Secondly, it is highly configurable (whether we ever use it or not), and there is always an option to alter the minute details of the pipeline flow.