4

I tried to understand the benefits of using Scratch org for CI/CD, but still not quite get it.

According to the Salesforce document:

The scratch org is a source-driven and disposable deployment of Salesforce code and metadata, 
made for developers and automation (CI/CD). 

But in next paragraph, it also says:

Projects and scratch orgs are meant to be used by one developer.
Therefore, we don’t anticipate file conflicts or the need to merge.
[Reference](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_push_md_to_scratch_org.htm)

Based on my current understanding, please correct me If i am wrong. I suppose Scratch org mainly allows one Developer to do some pre-validation to avoid some obvious errors (field missing...etc) or conflicts against new released features before the actual deployment.

Use Scratch org as a 'release branch' is not recommended, that is asking 20 developers to push all their touched metadata for next major release into one Scratch org is not best practice and we should avoid. Hence we should stick to the old way, leverage CI/CD tools (Gitlab, Jenkins,Salesforce CLI for example) to automate the deployment against sandbox orgs, rather than scratch org,

Feel free to contribute if I am wrong.

Update on Nov 1st. Thanks @Philw and @ zaitsman's answer. Each of you provide clear explanation based on your experience. After reading through several times, I am more believed that Scratch org can provide some benefits for CI/CD, but not big enough to convince all business to choose that approach.

2 Answers 2

5

@zaitsman's answer - when you ignore a bit of the slightly sarcastic tone ;) - covers one of the core points of scratch orgs: cleanliness.

By using a scratch org and always populating it initially from your version control system, such as git, via a command like sfdx force:source:push, you:

  1. Ensure that everything you need is really in version control, not accidentally just on some random org.
  2. You give the developer a baseline from which to continue development, making the delta for their work easier to manage and bring back into version control via a command like sfdx force:source:pull.
  3. For 2GP managed package development, this (is supposed to) allows Salesforce to verify that the delta doesn't contravene package versioning rules such as deleting global components etc.

Where it comes to your CI/CD pipeline, which is intended to verify that you have all the required metadata in version control and that the code being committed passes tests with appropriate coverage, it has an additional massive benefit:

  • Each commit and/or merge you wish to run the pipeline against (in whatever way you have set up your pipeline triggers) can be run in parallel - as much as your branching and merge strategy against your version control system permits - without risking conflicting use of a shared org.

This means your CI/CD process can be simpler (you don't need to have a bunch of orgs you round-robin against) and can respond more quickly while you can be confident that each execution is independent and fully self-contained. You won't get pipeline false negative or false positive execution of your pipeline. And you'll know that all the metadata you need has been correctly added to version control.

By the way, your CI/CD process should always start with ensuring that the target branch (which may be your "master"/"main" or some feature or epic branch) is at least temporarily merged into the branch being processed before the scratch org gets created and populated. This ensures that any merge conflicts must be resolved before you waste time with Salesforce and ensures that after the pipeline has finished you can be more confident a following merge would not result in any broken tests due to parallel changes.

4

So their idea is very much for developers who are only developing features that are deployed and accessed form within SF UI/Rest API. Under this paradigm and in a traditional agile dev house, a developer is usually working on a small and isolated change (e.g. a button, a flow, a screen, a layout etc.).

Those changes typically do not require a lot of data and once implemented and test covered are good to survive forever.

So some genius in Salesforce came up with a concept of 'Scratch orgs' being 'throwaway orgs' where if you made other changes unrelated to your work nothing will be accidentally affected.

So the use case for developer is:

  1. Create a scratch org from a definition file or org shape
  2. Code
  3. Commit
  4. Create a PR

The CI then

  1. Creates a scratch org from a definition
  2. Pulls devs branch in
  3. Runs all unit tests
  4. Reports the PR as good to guy

Once PR is merged, the CD then

  1. Pulls changes into the developer org
  2. Runs all unit tests

Or so it seems to me.

I work for an ISV so for our use case 2GP and Scratch orgs simply don't work, to develop a simplest feature in our app requires tens of different records across custom objects and they are consumed by external mobile apps. Because of this we use 1GP, each developer gets his own long-living dev org, and it's for developer to pull in the changes to source control; the ci/cd deployment just happens to a consolidated dev org and then a human does the same to Gold Master.

5
  • 1
    I also work for an ISV, developing both 1GP and 2GP with scratch orgs. We are able to successfully do this because our packages do not depend on bespoke external systems (only a few globally accessible ones like Google Maps and Google Calendar) and all our tests generate the data they require. Even our UTAM automation tests do this. Our core 1GP has some 140+ custom objects and this works fine on scratch orgs for development and CI/CD. We abandoned long lived, per developer dev orgs about 3 years ago and haven't looked back since.
    – Phil W
    Oct 28, 2022 at 6:08
  • @PhilW I bet your core offering is actually web interface within Salesforce. Ours isn’t. In fact majority of our objects are disabled for creation from UI. SF for us is for backend reporting and admin, it's not what we sell primarily. And all of our customers have old data within their orgs so if we don’t have the same it makes it difficult because things will be missed. To each their own, of course
    – zaitsman
    Oct 29, 2022 at 20:10
  • I wasn't saying your perspective is invalid (indeed I upvoted your answer), though I would hope you can still make appropriate use of scratch orgs if you structure your code for testability and write unit tests appropriately. I am puzzled by your reference to "old data", though if you are alluding to old CreatedDate values this is mockable in tests using Test.setCreatedDate.
    – Phil W
    Oct 29, 2022 at 20:28
  • @PhilW Old data means data created by older versions of our client app. Like from 3 years ago. My LEX js code needs to know how to render it. Tbh for us the code in Salesforce itself including all customisations is maybe 8-10% of the entire code base. Everything else lives outside and this is where devs spend the majority of the time.
    – zaitsman
    Oct 30, 2022 at 1:28
  • Not wanting to waste your time since this is only a small part of your dev work, though I wonder why your unit and UI (Jest?) tests cannot include simulation of old style data. You need not answer, unless you want to. In the meantime, I do believe you should be able to make use of scratch orgs. I feel this would increase your robustness of process - if you restructure your code for testability (e.g. non-static code so you can mock it using StubProvider and some simple dependency injection mechanism) and write appropriate unit tests. I would encourage you to re-examine this option.
    – Phil W
    Oct 30, 2022 at 7:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .