2

I am very confused on a concept with SFDX, i have been seeing many SFDC videos and presentations like this SFDX Presentation where salesforce has been telling the best practise for CI/CD is to create and delete scratch orgs.

I followed this practise and setup a CI/CD like this, the challenge was that because we created and deleted scratch orgs on every merge it was counted against the organisation limit for number of scratch orgs created per day. Because we use Enterprise edition we were limited with 80 scratch orgs per day, keep in mind although we delete the scratch orgs after creation the limitation still counts since its "how many scratch orgs you create" and doesn't matter how many are active.

Due to this we couldnt make more than 80 code merges in a day with this CI/CD approach. I am confused with this approach since salesforce is proposing this idea and we are hitting a limitation when we follow it due to limits. Is creating and deleting scratch orgs the right thing to do on code merge? and if so how do you handle the limitation of doing more code merges and not have limitation of 80.

Current limits of Scratch Org creation Salesforce Documentation enter image description here

  • 1
    Are you really merging to master eighty times a day? Or are you running CI on every commit on every branch? – David Reed Jul 23 at 23:05
  • 1
    yes david, thats what i am not sure whats the correct approach, whether to do a CI check on every commit or only on merges to some specific branches. Since all the demos had CI running i had thought its better to run CI checks on every commit, but looks like thats not correct? – Anil Shivaraj Jul 24 at 1:25
1

You can break this only if you have a huge team and if frequent merges are happening (Team of 20 devs with 4 Pull Requests each per day or 10 devs with 8 Pull requests, yes likely you run into this limit). I am hoping you are not deleting and creating scratch orgs on every commit .

Here are some mitigation strategies

1.A scratch org can exist for 30 days you don't necessarily dispose them off until your sprint ends.Reuse them as much as you can.You can definitely deploy to it just like sandboxes by storing the credential as environment variable.

2.Leverage non scratch orgs like sandboxes to validate merges instead of scratch orgs. SFDX supports non scratch orgs as well .

3.I would reach out to salesforce AE to see if they can increase this for you(Do not quote me on this but i have managed to get this limit bumped up .You will need proper explanation and justifications before salesforce will believe you).

  • good that you put the points mohit, i will keep this in mind but the way salesforce has presented in all the videos they keep creating and deleting scratch ors in every commits so i had assumed thats the right way. The way i thought is to keep a branch for every developer - 8 devs i.e 8 branches . Everyone works on a feature branch and merges to their final branch which has CI checks like lint & PMD. – Anil Shivaraj Jul 24 at 1:29
  • once it has passed in individual developers branch then they promote to a non scratch org through a merge where a CI check runs again but this time no scratch org is created but just deploy to a sandbox. Do you feel its a over kill to do a CI check for each developer branch - i have 3 things in CI check - PMD, eslint and sandbox deploy. Thanks mohit – Anil Shivaraj Jul 24 at 1:31
  • On every commit scratch org create is definitely overkill. while all checks you have is great , I would just validate against a dev sandbox for each branch. – Mohith Shrivastava Jul 24 at 1:43
  • Also Salesforce evangelist who put those videos build proof of concept apps .They rarely have an idea what an Enterprise org in Salesforce looks like and our challenges . – Mohith Shrivastava Jul 24 at 1:46
  • On top of this they never work as a team with 10 devs on a project and in that most of them are junior and crazy about commits 😂 – Mohith Shrivastava Jul 24 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.