Now that you’ve decided that you want to implement CI/CD for Salesforce, here are the fundamental building blocks that you will need to think about and implement:

Design your pipeline

Your pipeline will include a list of shared environments (the highest of which is your production environment). An example list of this type is: integration -> UAT -> Prod.

In some cases the process of introducing changes into the pipeline begins right in the lowest shared environment (integration in the example provided), where team members develop changes and then push them up the pipeline. In other cases changes are made in personal environments (dev sandboxes or scratch orgs) and then pushed into the first shared pipeline environment (see below).

The different ways to introduce changes into the first env in the pipeline will have different limitations and advantages, and might affect your change management processes.

The main challenge with introducing personal orgs is maintenance: keeping them up-to-date with all the changes made by the rest of the team, so that the individual contributor doesn’t end up working on a stale representation of production. In addition, working in an isolated environment might mean that you are completely unaware of changes being worked on in other personal sandboxes, that might collide with what you’re trying to accomplish. This isolation, however, does have some advantages: The main advantage of using personal orgs, is that each IC essentially avoids other teammates breaking things and dirtying up the shared environment with errors or incomplete work. This also means that the first shared environment itself will most likely be more stable and less messy, since changes that reach it would have already been tested in the personal sandboxes.

Plan your Git branching strategy

In the context of Salesforce CI/CD - your branching strategy will most likely be one branch per environment. Whether implemented on your own or through a Salesforce DevOps tool, it is likely that Git will be part of your CI/CD and versioning frameworks. 

The following criteria might play a role in your per-environment decision whether to maintain its configuration in a Git:

• Version history: If there’s a requirement to have version history of the environment (the need for a papertrail, or for ease of reverting changes and troubleshooting) - Git can help with versioning your environment changes. 
• Desired review and approval process for the org: If you plan to create processes for collaboration among team members in a structured reviewal and approval process for changes targeting an org - Git pull requests were designed exactly for that.
• Automating testing and deployments: CI servers work with Git and are designed to enable any automatic job triggered in reaction to Git events. This means that connecting the target org to Git will enable you to leverage them effectively. 
• Protecting the org: If you plan on protecting the org from unapproved changes or those that fail tests, and ensure they won’t make their way into the environment - maintaining the environment configuration in a Git branch enables you to utilize Git’s branch protection rules.

Choose the right tools 

Even though it is possible to build your CI/CD solely with SFDX CLI, VS code and Git, most Salesforce teams adopt a DevOps Salesforce tool (like Salto). 

Salesforce DevOps tools generally aim to serve two types of users - the developers working in an SFDX pipeline on the one hand, and also the less technical team members who usually make changes in UI and not code. These DevOps tools provide the latter with a much easier and intuitive interface that essentially wraps SFDX and Git commands (which hold the team’s branching strategy). This brings everyone on the team to the same high standard of DevOps processes and enables them to collaborate efficiently, without compromising on the ease of making changes for less technical users, nor on the ability to work with SFDX and VS code directly for the more technical team members. 

Additionally, some of these DevOps tools provide substantial flexibility to incorporate existing tools you may already use (like your CI server, Git providers, etc), as well as allow you to customize based on your needs by adding your own scripts into the process (send notifications, automatically integrate with ticketing systems or other internal systems, etc.)

Plan your automations (testing, validation, deployments, etc.)

Maintaining your orgs in Git opens the door for automations. These automations will be based on events in your Git repo that can trigger different subsequent actions. For example, you can leverage Git events to set up automatic Salesforce validations and tests for your deployments. This can also include branch-protection rules, restricting the deployment in case these tests fail. In addition, you will be able to automatically prepare promotions of deployed changes to higher envs in the pipeline.

If you’re ready to get started with designing and implementing your CI/CD pipeline, feel free to book a 1:1 session with our DevOps experts, or start on your own with Salto’s free trial.

‍