+ Start a Discussion
Abhishek VERMA 149Abhishek VERMA 149 

Release management

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

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 regarding GITFlow.

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
Selvin Samuel 1Selvin Samuel 1
Hi Abhishek,

Even I am having the exact same questions. All SF resources mentions to do modular development but then how do you manage dependency, a single source of master branch and merging? I got very very confused. As far as on my google searches i dont see any out of the box option provided for incremental releases. The tracking only works for scratch orgs.

Did you find an answer for your question? Appreciate if you could share some light.

Abhishek VERMA 149Abhishek VERMA 149
Hi Selvin,

I had posted the same question on stack exchange. And had a discussion thread. You can check below


We started Salesforce not very long, hence my doubts are more specifc to Deployment Jobs through Jenkins. I was confused whether Master Branch should contain the full metadata of All previous Sprints or only the incremental metadata specific to new sprint.

This doubt is clear now, master brnach should always have all the metadata of all the sprints including the current one which you intend to deploy.

Considering Modular or Packaged Development, I believe you are mixing 2 things here.

Note that as I said, Master Branch being "Source of truth" should always have all the metadata. 

Now as far as deployment through Jenkins is concerned using SFDX there are 2 methods

1. Through mdapi
2. Through UnLocked Packages (As described in - https://trailhead.salesforce.com/en/content/learn/modules/unlocked-packages-for-customers/build-your-first-unlocked-package)

The first method builds and deploys all custom metadata present on master each time you run a build.

The 2nd method, I belive only picks those metadata component which are part of package and deploys. (I have yet to validate this. Its been many days when I last worked on unLocked Paackages)

The master branch is both the cases should be up to date with full set of metadata for all previous and current sprints.

Selvin Samuel 1Selvin Samuel 1
Thanks Abhishek! That clears me on the master branch confusion. For the deployment option 2, are you meaning it can do incremental (delta) deployment from the master branch so, only the new changes gets deployed?

Abhishek VERMA 149Abhishek VERMA 149
For the deployment option 2, are you meaning it can do incremental (delta) deployment from the master branch so, only the new changes gets deployed?

Yes, I believe so. But has not tested in recent times to effectively validate so.