º£½ÇÌìÑÄÉçÇø

Modern SFDX workflows often rely heavily on the use of scratch orgs, which are a great tool for testing changes in a safe environment. º£½ÇÌìÑÄÉçÇø supports both manual creation of scratch orgs, as well as during continuous integration (CI) jobs, which is what we’ll focus on in this post.

What are scratch orgs good for?

Scratch orgs are temporary environments that you can spin up to do development work in isolation, build and test deployment packages ahead of time, or just ‘fiddle around with stuff’ without the worry of maintaining the environment. For example, you might create a scratch org based on the metadata in your version control system (VCS), then get on with development work without worrying about stepping on your team members’ toes.

Typically, scratch orgs are created using the SFDX command line interface (CLI). This is where things can quickly get complicated, as there are lots of tricky commands and options to remember. Switching between different Dev Hubs can also be a hassle sometimes, especially if you forget which Dev Hub username has been set as default, as this can lead to someone accidentally making changes to the wrong Dev Hub. We decided to make things a bit easier for º£½ÇÌìÑÄÉçÇø users.

Get your CI job in º£½ÇÌìÑÄÉçÇø to create a scratch org

Continuous integration jobs that allow for automatic validation or deployment of metadata are one of º£½ÇÌìÑÄÉçÇø’s core features. Wherever possible, we encourage the use of CI to enhance development workflows, as we think it’s one of the best ways we can help people on their DevOps journey.

Whether you’re using CI to automatically validate a package built from a Git source, or using it to regularly deploy between two Salesforce environments, CI can really accelerate your development process. We already know that utilizing CI in your process can have a dramatic measurable impact - we found that teams using CI deploy 17 times more frequently than teams that don’t, and have a success rate of more than 90% when deploying to production.

One of º£½ÇÌìÑÄÉçÇø’s more advanced features lets you in a Dev Hub of your choice from your CI job, and use it as the target of your deployment or validation. When your CI deployment source is a Git repo in SFDX source format, and your target is a new scratch org, your CI job will automatically create a scratch org based on the scratch-def.json configuration, using the namespace found in the sfdx-project.json file. It will also install the package dependencies listed in sfdx-project.json.

Sample sfdx-project.json file:

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "MyUnlockedPackage",
      "versionName": "ver 2.3",
      "versionNumber": "2.3.7.NEXT",
      "dependencies": [
        {
           "package": "ManagedPackage@4.0.0-1"
        },
        {
           "package": "AnotherUnlockedPackage@2.2.0-1"
        }
      ]
    }
  ],
  "namespace": "NSNS",
  "sourceApiVersion": "45.0",
  "packageAliases": {
    "ManagedPackage@4.0.0-1": "04t3u000013X3cuAAC",
    "AnotherUnlockedPackage@2.2.0-1": "04t4d070013X4cuAAC",
    "MyUnlockedPackage": "0Ho4J000000XZnkSAG",
    "MyUnlockedPackage@2.3.7-1": "04t4J0000035bZ4QAI"
  }
}

Sample scratch-def.json file:

{
  "orgName": "TestScratchOrgForCI",
  "country": "GB",
  "adminEmail": "jonathan@gearset.com",
  "edition": "Developer",
  "description": "This is a scratch org to test CI deployments",
  "hasSampleData": false,
  "features": [
    "API",
    "EventLogFile"
  ]
}

Here you can see how easy it is to :

Example use case

The following is an example of using CI to streamline your development process and build better confidence in the resulting managed package.

Suppose I’m developing a managed package, for which I’m using Git to source control my metadata and Apex code, with feature branches that I merge into master via pull requests (PRs).

My development process looks something like this:

1. Use º£½ÇÌìÑÄÉçÇø to deploy from my Git repo (master branch) to a scratch org created from the º£½ÇÌìÑÄÉçÇø deployment UI.
2. Do my development work in the safe environment of my new scratch org.
3. Use º£½ÇÌìÑÄÉçÇø to manually deploy from my scratch org containing my work into a feature branch.
4. Use º£½ÇÌìÑÄÉçÇø to create a PR between my feature branch and master, then review and merge from the GitHub UI (or from the equivalent UI of the Git hosting provider you’re using).

Once I’ve run through these steps, I need to validate that the package I have in Git is working, and safe to deploy back into my development or QA org, before releasing a version of my package to production. This might just be to make sure I have a valid source of truth in Git for my package, or it might be because, when I deployed from my scratch org to Git, I was selective with what metadata I deployed. Or, maybe, I just wanted to take advantage of º£½ÇÌìÑÄÉçÇø’s problem analyzers to check the package can be deployed, or make use of º£½ÇÌìÑÄÉçÇø’s repo cleaner to clean up any obsolete metadata in my repo. As long as I’ve created a CI job that targets a scratch org, with a Git repo source where I’ve configured an incoming webhook for merged PRs, this is where º£½ÇÌìÑÄÉçÇø takes over:

5. An incoming webhook triggers a CI job in º£½ÇÌìÑÄÉçÇø when a PR is merged.
6. The CI job automatically creates a new scratch org based on the scratch-def.json configuration, and the package dependencies and namespace found in the sfdx-project.json file.
7. The CI job then takes the metadata in my repo, and validates/deploys it to the newly created scratch org

Now, I’ve validated that my package in source control is safe to use and passes all my Apex tests, etc. Automated success!

Ready to upgrade your CI/CD workflow?

Just starting out your automation journey? To learn more about how you can automate your releases and achieve continuous delivery, check out our free ebook CI/CD for Salesforce.

If you’re looking to go above and beyond the use of scratch orgs to supercharge your CI/CD workflow, Pipelines, º£½ÇÌìÑÄÉçÇø’s Salesforce CI/CD solution may be the next step! With advanced branch management, improved visibility, and seamless automation, Pipelines can support your team in reaching for more mature DevOps workflows. Try it for yourself with a today.