DEV Community

poponuts
poponuts

Posted on

Running Salesforce CLI (sfdx) on Buildkite pipeline

#salesforce #buildkite #automation #cicd

Unlike typical web apps, Salesforce usually has its own ecosystem in terms of packaging and deploying its products via its Salesforce CLI (sdfx) package.

In my humble opinion, they are still in the infancy stage of the DevOps movement since there are still steps that require manual intervention. However, I think it's getting there in terms of trying to make everything smooth with one to two-click automation 🤖.

Here's a guide on how we did it with our current pipelines using Buildkite, which is flexible enough to allow prompts or as they call it blocks 🧱 in between steps. It required heaps of experimentation and iteration before we got to a stage where every developer is comfortable using it.

We initially used its docker image as most references on the web with SF CI/CD use this but we decided to use the npm package as its closer to how we do CI/CD for our other web apps.

Please refer to this boilerplate github repo as a guide. Ensure that the CI variables are defined in your Build Steps:
Buildkite env variables

For our Continuous integration (CI):
Every change (update or create) to any git branch (master or feature) would trigger running the Buildkite pipeline for Salesforce.
The pipeline would run the following steps in sequence:

  1. Download the @salesforce/cli npm package

  2. Create a scratch org (temporary org necessary to run unit tests)

  3. Run unit tests (BONUS: security tests using snyk and code coverage using Codecov)

  4. (if master) Deploy source package to scratch org

  5. Delete scratch org

Makefile:

test: .env
    @echo "Running sfdx test"
    openssl enc -nosalt -aes-256-cbc -d -in assets/server.key.enc -out assets/server.key -base64 -K $(DECRYPTION_KEY) -iv $(DECRYPTION_IV)
    docker-compose -f $(PATH_DEPLOY)/docker-compose.yml run --rm build "npm run test"
    @echo "Running snyk test"
    docker-compose -f $(PATH_DEPLOY)/docker-compose.yml run --rm snyk "snyk auth $(SNYK_TOKEN) && npm run snyk"
    @echo "Running codecov"
    docker-compose -f .buildkite/docker-compose.yml run --rm snyk "curl -Os https://uploader.codecov.io/latest/linux/codecov && chmod +x codecov && ./codecov -t $(CODECOV_TOKEN) --flag Apex"
.PHONY: test
Enter fullscreen mode Exit fullscreen mode

For our Continuous deployment (CD):
The aim is to automate the current manual process of creating and installing packages in testing environments.
Package release workflow

Every feature merge to master (a commit without tag) would trigger the following steps on the pipeline:

  1. Prompt to select which component/s to create a package for along with the corresponding package version numbers and dependency configuration for omni-channel and/or test drive. Beta package version
  • Package version numbers should follow the format MAJOR.MINOR.PATCH
  • When creating omni-channel and/or test drive package, by default package dependencies are not updated. To update package dependency, select the component to update and specify the core package version ID (if core package has already been created previously) or, leave the field blank to set dependency on the new core package when creating a new core package along with omni-channel and/or test drive package.
  • When creating core package only, selecting component/s to update package dependency and/or setting a core package dependency version ID will NOT update omni-channel and/or test drive dependency in sfdx-project.json.

  1. Depending on the selection, update version number (and package dependency) in sfdx-project.json and create beta package.

  2. Create scratch org

  3. Install beta package(s)

  4. Delete scratch org

  5. Upload the updated sfdx-project.json as a build artifact on Buildkite. Devs have the option to download the updated sfdx-project.json from Buildkite in case errors arise in succeeding build steps.
    Artifact

  6. Push the updated sfdx-project.json to a release branch

  7. Open a Pull Request to master from the release branch
    Bitbucket Pull request

Following the above, Devs must assign a reviewer, review and merge the Pull Request. In addition, Devs must create a tag for the commit to trigger the following build steps on the pipeline:

  1. Prompt to select which package(s) to promote to release version and install in testing environments.
    Promote install package

  2. Promote package(s) to release version

  3. Install package(s) to automation org

  4. Run e2e smoke tests

  5. Have the option to install package(s) to UAT org

As you can see above, it's not very straightforward (more like a partial DevOps) 🤯. Hopefully, Salesforce is working towards improving this process and making lives easier for the developers.

Top comments (0)