A Complete Guide to Salesforce DevOps Automation With GitHub Actions

The days when backing up your org metadata at a particular point in time using change sets or unmanaged packages in Salesforce have gone. The days when data losses occurred because of human errors, disasters, or an inadvertent refresh of a sandbox also have gone. The times have changed.

Whether you are a Salesforce Administrator or a DevOps engineer, keeping your data secure, intact, and available with a reliable and easy-to-maintain solution should remain your primary objective.

This article outlines a maintenance plan for your Salesforce organization to be implemented as part of your overall data management and security model. It offers a way to combine multiple maintenance tasks into a single package that can be executed manually or on an automated schedule.

The presented solution will ensure the following:

• Hassle-free backups to safeguard your Salesforce data and metadata.
• Secure and automated daily backup jobs or instant backup on request.
• Detailed analysis of your code and visualization of anomalies.

The Recipe Ingredients

Let’s begin by describing the main components of our solution.

GitHub

A proprietary platform for developers to create, store, manage, and share their code efficiently.

GitHub Actions

A CI/CD solution to automate DevOps operations and streamline the software development lifecycle. GitHub Actions is seamlessly blended with your GitHub code repository and allows developers to define reusable workflows in YAML files.

When triggered by specific events like push, pull, or schedule, these workflows execute a series of predefined jobs that may integrate disparate third-party software into your processes.

Salesforce CLI

A cornerstone, versatile command-line tool that simplifies working with Salesforce projects. It streamlines the creation, deployment, and management of Salesforce applications and offers a wide range of commands to boost your experience as a Salesforce DevOp, especially in environments where continuous integration and continuous deployment (CI/CD) practices are employed. 

In July 2023, Salesforce released an evolved version of the CLI (aka sf v2) while sunsetting the Salesforce Extension Pack SFDX commands.

Salesforce Data Move Utility (SFDMU)

A comprehensive and powerful data migration solution, approved by Salesforce and equipped with a lot of functionalities that facilitate data migration and synchronization processes between various Salesforce environments, including scratch, development, sandbox, and production orgs. 

Salesforce Code Analyzer

A solution designed to provide you with a high-level analysis of code health, reduce the overall cost of code review processes, and give you actionable insights about the compliance of your code with best practices. 

It leverages multiple code scanners that integrate effortlessly with your CI/CD pipelines.

The Recipe Prerequisites

As said, the secret behind the success of any project is La Mise en Place! To get started, let’s have all the ingredients and supplies prepared and well-organized.

1. Creating the GitHub Account

Create a new repository on GitHub to host your project-related data. Within this repository, create a “config” folder to include the basic configuration files of our solution listed below:

Package.xml

A manifest file used to selectively identify Salesforce Metadata components. This file is optional; if omitted, all your org Metadata components will be backed up. For the sake of simplification, I created this sample file to push/pull only the Apex classes defined in our Salesforce org.

Export.json

A simple-to-build configuration file is required by the SFDX Data Move Utility to manage various data operations like data migration and data export. To put it simply, I designed a JSON file to export selected fields out of the objects (“Account”, “Contact”, and “Opportunity”) from our org as shown below:

2. Collecting the Org Authentication URL

Having Salesforce CLI installed in your terminal, connect to your org and extract the authentication URL. 
The latter, typically used when building CI/CD pipelines, contains the information necessary to access an org on the user’s behalf and serves for authorizing an org without necessitating a JWT Token or using the browser for entering the required credentials.

The Authentication URL is formatted as follows: force://clientId:clientSecret:refreshToken@instanceUrl

To get the Authentication URL:

1. Execute this command on your terminal: 
   • $ sf org login web --alias  <OrgAlias> --instance-url <OrgURL> --set-default
2. A prompt to log in to the targeted org is then shown on a new browser tab. Enter your credentials. Once it’s successfully authorized, close the browser tab.
3. Next, run this command:
   • $ sf org display --u <OrgAlias> --verbose
4. Maintain a copy of the Authentication URL displayed immediately after: “Sfdx Auth Url”.
5. Store the generated Authentication URL in the GitHub repository. Then, on GitHub:
   • Navigate to the main page of the lately created repository. 
   • Go to Settings > Secrets and Variables> Actions.
   • Create a new repository secret named “ORG_SFDX_URL” and fill the “Secret” field with the Authentication URL previously collected.
6. Grant rights for actions and reusable workflows. Then, on GitHub: 
   • Navigate to the main page of the repository that has been created lately. 
   • Go to Settings >  Actions > General.
   • Enable the property “allow all actions and reusable workflows.”

The Cooking Journey

Everything is now in place, roll up your sleeves, and let’s get cooking!

Configuring the GitHub Action Workflow

First, let’s explore the building blocks of GitHub Actions.

A GitHub Actions workflow is a customizable automated process comprising a series of predefined jobs.
Workflows can be triggered on demand when a specific event occurs within the containing repository, or at a defined schedule.

Workflows are configured using YAML files and placed under the “./github/workflows” directory in the repository.

Workflows are composed of jobs having the following characteristics:

1. They consist of one or more steps that execute specific instructions. These steps may include actions provided by the GitHub community or third-party providers.
2. They run in parallel by default, but they can be configured to run sequentially in case interdependencies exist between them.
3. Each job may run in a separate virtual environment – for example, runner.
   

Putting this all together, let’s get into the nuts and bolts of our solution workflow.

Go to your repository root directory, create a workflow file called “backup_analyze_org.yml” and store it beneath the directory “.github/workflows”.

Copy the code snippet below into your workflow file and commit the changes as demonstrated in the following example: <Insert the contents of the attached file backup_analyze_org.yml here.>

This walkthrough will demonstrate our workflow.

1. We configured the triggering events of our workflow, which are:
   • Scheduled based on a cron trigger. 
   • Manually using a “workflow_dispatch” event adds a layer of flexibility to our solution.
2. We defined a single job called “backup_analyze_job” that makes use of the Ubuntu-latest runner.
3. Within the above job, we included a series of steps involving the following actions:
   • Checking out the code. 
   • Setting up Node.js.
   • Installing Salesforce Client.
   • Installing Salesforce Code Analyzer.
   • Installing Salesforce Move Data Utility.
   • Authorizing the Org.
   • Creating a Salesforce DX project and retrieving Metadata components based on the predefined manifest file.
   • Exporting the data of the specified org objects to CSV based on an “export.json” configuration file placed under the “config” folder.
   • Running the Salesforce Code Analyzer and storing the generated results, classified by severity.
   • Capture a snapshot of the staged changes and save them to the repository.

The Tasting Experience

Let’s manually start our workflow and visualize its output:

On GitHub, navigate to the Actions tab on your repository’s main page and run the workflow “Backup and Analyze Org” while selecting the “main” Branch:

The Execution Details

Following the workflow execution, you can check its output status and review the time spent and the running logs of each step at a granular level, as shown below:

The workflow job then displays the Salesforce Code Analyzer results:

Now, let’s look into the changes introduced to our main GitHub repository:

You will notice that three new folders were created:

1. backupData: containing the CSV extracts of the chosen objects.
2. backupMetadata: encompassing a backup of the selected metadata components.
3. scanResult: holding the salesforce code analyzer results and a change-log file.

Final Thoughts

The vast ecosystem of GitHub Actions makes it an ideal orchestration tool for building world-class pipelines, simplifying GitHub interactions, and automating software workflows.

Leveraging the capabilities of GitHub Actions and implementing the solution described in this article brings a host of benefits, like:

• Offloading the routine, repetitive, and most overlooked administrative tasks.
• Expanding data protection and improving tracking of changes.
• Bolstering the software testing and quality assurance of your Salesforce org source code.
  

Make sure to leave your thoughts in the comments below!