2

We are implementing CI/CD setup. The components involved are - GitLab - Jenkins - SFDX CLI

we are already few releases deployed in Prod and want to streamline package development model using SFDX CLI/Jenkins CI/CD setup.

The pipleline for pushing builds has been created on Jenkins and works well. Developers are also well connected with GitLab.

As GIT and Jenkins administrator, the challenge I am facing is for below questions

I give you a scenario.

Lets say we are already on Release 1.0 on Prod. And we we are preparing for Release 2.0.

  1. What should be the starting point for developers (Around 20)? The reason for asking this question is the master or main Branch does not contain currently all the custom metadata delivered in prod. After release 1.0 there were some hotfix changes so the master branch contains metadata concerning the hotfix.

  2. What is the common practice followed for release management? for example after Release 1.0 my assumption is master branch should have all the code/custom metadata present as per prod. And when developers start working on any feature what they first should do is GIT Clone to pull all the custom metadata (R 1.0 specific) on their local and then start on R 2.0 by creating a feature branch followed by test on scratch orgs and then merging on Dev branch.

  3. What will the content of Master branch when we are ready for R2.0? Would it be all the custom metadata for R1.0 and R2.0 together or it would only be incremental R2.0 specific metadata?

I tried to search google and various flow diagrams etc but these basic questions still bothering me. Any suggestions?

Thanks and Regards Abhishek Verma

3

In my opinion:

  • master represents the state of development towards the next release (some folks would, instead, have release branches that are merged to master at the time of the next release).
  • you only deploy to your package "release org" from master.
  • when releasing a version you tag the latest commit on master with the release identity.
  • if you need to provide "hot fixes" these are done on branches created from the appropriate tagged point in the git log and are used to create patch releases on "patch orgs". This has some limitations - no new components, for an example, and no changes in the number of global classes/methods/attributes/properties in your Apex for another.
  • git is the source of truth; it should contain the full state of the package at all times. Changes to the package should be disallowed except via git (or at least git must be updated at the time the change is created).
  • every piece of work requires a separate issue branch (usually named after your issue in your issue tracking system), and this applies for bug fixes as well as new feature work.
  • such issue branches get merged to master (and possibly cherry picked back to earlier version branches for patching purposes) only once they have been fully reviewed (perhaps via pull requests) and only when all tests pass (could be enforced by your CI mechanism). Even better, only allowing the merge as long as the over-all coverage of testing meets or exceeds Salesforce requirements.

To your specific questions, based on the above:

  1. Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
  2. IMHO it is prod that FOLLOWS git, not the other way round. Nothing should go into prod without first being developed and tested in git.
  3. master will contain all existing code plus reviewed and approved feature and bug fix development. Since the release is created from the content of master, you need to time the creation of the release appropriately (i.e. if there is a mandatory feature or bug fix not yet approved and merged to master you need to get that done and merged first). Importantly, you don't just remove material from git because it has already been deployed. That would be nonsensical - how could you apply bug fixes to Apex code if it isn't still in git?!?

NB: This is described from the ISV development perspective where more than one version of the package needs to be supported. If you don't need to support multiple versions, forget about patch releases. Hot fixes can still be catered for via a branch off master into which only hot fixes go, but this would be used as the source of truth for creation of whole new versions (not patch versions) to avoid bringing in material not yet ready for formal release.

  • Thank You Phil. For Q.3 on my post what I understand Master Branch will contain R1.0 + R2.0 and build will run on master branch to push the code on targeted ORG. Wouldnt this approach will make master branch very heavy after multiple releases and deployment time would start increasing since build is done on full set of metadata for all previous releases. Another approach where you move the content of master to another Branch after R1.0 and tag it as R1.0 for any future reference. Add the content of R2.0 on master branch to keep it light weight and then do the build. – Abhishek Verma May 9 at 9:01
  • Yes, indeed. Git should contain everything that makes up your package. (There are some org configuration items that cannot be captured as meta data, so you may have to include a number of post-installation manual steps too on occasion. But that's org-level stuff, not package stuff.) – Phil W May 9 at 9:01
  • My recommendation: only create branches when you need them. Use tags instead when marking the state of the repository used to generate a release. – Phil W May 9 at 9:03
  • 2
    Clearly you can do whatever you like, but the approach you suggest is going to completely screw you over at some point. Follow best practice; have the whole package in git. Deploy everything from git. Don't allow direct updates in prod or at the very least immediately pull those down into git. Your suggested approach is just wrong (IMHO). – Phil W May 9 at 10:38
  • 1
    @PhilW Only posting this because it might benefit others - I use bluecanvas.io for one of my clients just to keep track of who is making changes in production and am able to do git compares between my source of truth master and what's actually really in production. A great tool for orgs that has the unfortunate reality of many people/teams making adjustments and changes in Production – Brian Miller May 9 at 12:55
3

My opinion (on the simplest approach):

  1. Get all the metadata into Git.
  2. Create a branch for R 1.0 in case any patches are needed (that will also need a patch org for people creating managed packages) and work on master towards R 2.0. Merge any patch fixes made for R 1.0 into master.
  3. The master branch will contain all components and everything from R 1.0 not the differences.

FYI on Jenkins pipelines, we have created https://claimvantage.github.io/sfdx-jenkins-shared-library/

  • Thank You Keith. For Q.3 on my post what I understand Master Branch will contain R1.0 + R2.0 and build will run on master branch to push the code on targeted ORG. Wouldnt this approach will make master branch very heavy after multiple releases and deployment time would start increasing since build is done on full set of metadata for all previous releases. Another approach where you move the content of master to another Branch after R1.0 and tag it as R1.0 for any future reference. Add the content of R2.0 on master branch to keep it light weight and then do the build. – Abhishek Verma May 9 at 9:01
  • @AbhishekVerma Dependencies come into play. Usually, a v2 of something requires changes to the v1 components hence accumulating the whole component set. But if you can avoid those dependencies (hard to do) you could layer v2 on top of an unchanged v1. We have code bases with thousands of classes and multiple thousands of unit tests. Yes they take 10 mins to deploy and the tests take over an hour (would take 10 mins but parallel testing breaks in scratch orgs) but that is just something you learn to live with on this rather slow platform. – Keith C May 9 at 9:08
  • I work for an ISV. We have around 5000 components that we regularly work on using SFDX and scratch orgs. It takes about 8 minutes to deploy everything (i.e. when first creating a scratch org). Thereafter it is incremental (takes less than a minute). We run all tests in parallel on our scratch orgs without issue. This takes about 2 elapsed minutes, and about 13 minutes when run in sequence. – Phil W May 9 at 9:26
  • Thank Keith and Phil, As you can anticipate our salesforce practice is not too old, hence I had these doubts on build deployments. It is however clear now that build/deploy time is not too much of a concern. @Phil you mentioned it takes 8 minutes to deploy everything. Thereafter it is incremental (takes less than a minutes). Can you explain this line "Thereafter it is incremental (takes less than a minutes)". Once everything deployed why incremental? – Abhishek Verma May 9 at 9:51
  • The sfdx CLI is what we use for deployment ("push"). With what Salesforce calls "tracking orgs" (scratch orgs are an example of this), the CLI spends the first 12 or so seconds working out what has changed between your local file system full of meta data files and your target org. It then sends just the changed files. (The amount of time varies based on size of your project; as I mentioned, we have around 5000 components [i.e. files] and it takes 12 seconds to process these for incremental deployment with the sfdx CLI. Extra time is then spent pushing the changed files.) – Phil W May 9 at 11:10

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.