Release Management in SalesforceSalesForce release management - standard mechanism?Deploying for a salesforce dx project [non ISV]How to use Salesforce DX with an existing sandboxesSFDX pull sample data from dev orgHow stable is SalesforceDX specs ? How does weekly CLI release maintain backward compatibilitySalesforce DX Use CaseGit unable to update URL baseHas anyone used the Salesforce DX CLI “shape” command?Jenkins, Docker and SFDX: Share SFDX “cache” between docker containersEfficiently merge handle parallel feature branches in SFDX
Why do testers need root cause analysis?
Ribbon Cable Cross Talk - Is there a fix after the fact?
Is "vegetable base" a common term in English?
Quantum corrections to geometry
Was this scene in S8E06 added because of fan reactions to S8E04?
How would a developer who mostly fixed bugs for years at a company call out their contributions in their CV?
Papers on ArXiv as main references
Why does the painters tape have to be blue?
Why did OJ Simpson's trial take 9 months?
What is the use case for non-breathable waterproof pants?
Can a multiclassed Kensei monk/Swashbuckler rogue use an offhand finesse weapon to trigger Sneak Attack, without using a bonus action?
Are there any German nonsense poems (Jabberwocky)?
Team has team lunch everyday, am I forced to go?
Writing "hahaha" versus describing the laugh
Why was this character made Grand Maester?
Complications of displaced core material?
Are PMR446 walkie-talkies legal in Switzerland?
How can I minimize the damage of an unstable nuclear reactor to the surrounding area?
To exponential digit growth and beyond!
Why is unzipped directory exactly 4.0K (much smaller than zipped file)?
Why'd a rational buyer offer to buy with no conditions precedent?
Unary Enumeration
Why does the hash of infinity have the digits of π?
How does the Earth's center produce heat?
Release Management in Salesforce
SalesForce release management - standard mechanism?Deploying for a salesforce dx project [non ISV]How to use Salesforce DX with an existing sandboxesSFDX pull sample data from dev orgHow stable is SalesforceDX specs ? How does weekly CLI release maintain backward compatibilitySalesforce DX Use CaseGit unable to update URL baseHas anyone used the Salesforce DX CLI “shape” command?Jenkins, Docker and SFDX: Share SFDX “cache” between docker containersEfficiently merge handle parallel feature branches in SFDX
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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.
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.
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.
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
salesforcedx release
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
add a comment |
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.
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.
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.
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
salesforcedx release
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
2
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27
add a comment |
2
2
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.
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.
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.
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
salesforcedx release
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
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.
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.
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.
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
salesforcedx release
salesforcedx release
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
asked May 9 at 5:52
Abhishek VermaAbhishek Verma
132
132
2
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27
add a comment |
2
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27
2
2
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27
add a comment |
2 Answers
2
active
oldest
votes
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:
- Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
- 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.
- 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.
answered May 9 at 7:07
Phil WPhil W
1,427311
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
|
show 5 more comments
3
My opinion (on the simplest approach):
- Get all the metadata into Git.
- 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.
- 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/
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
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
|
show 6 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f261740%2frelease-management-in-salesforce%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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:
- Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
- 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.
- 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.
answered May 9 at 7:07
Phil WPhil W
1,427311
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
|
show 5 more comments
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:
- Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
- 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.
- 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.
answered May 9 at 7:07
Phil WPhil W
1,427311
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
|
show 5 more comments
3
3
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:
- Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
- 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.
- 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.
answered May 9 at 7:07
Phil WPhil W
1,427311
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:
- Developers will always create issue branches directly from an up-to-date master branch, to be merged to master after review and approval.
- 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.
- 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.
answered May 9 at 7:07
Phil WPhil W
1,427311
edited May 9 at 7:53
answered May 9 at 7:07
Phil WPhil W
1,427311
answered May 9 at 7:07
Phil WPhil W
1,427311
answered May 9 at 7:07
Phil WPhil W
1,427311
1,427311
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
|
show 5 more comments
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
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
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
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
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
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
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
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
@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
|
show 5 more comments
3
My opinion (on the simplest approach):
- Get all the metadata into Git.
- 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.
- 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/
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
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
|
show 6 more comments
3
My opinion (on the simplest approach):
- Get all the metadata into Git.
- 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.
- 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/
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
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
|
show 6 more comments
3
3
3
My opinion (on the simplest approach):
- Get all the metadata into Git.
- 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.
- 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/
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
My opinion (on the simplest approach):
- Get all the metadata into Git.
- 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.
- 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/
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
edited May 9 at 9:04
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
answered May 9 at 7:10
Keith CKeith C
98.5k1198228
98.5k1198228
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
|
show 6 more comments
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
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
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
@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
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
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
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
|
show 6 more comments
draft saved
draft discarded
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f261740%2frelease-management-in-salesforce%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Hi. To be honest, I feel this is more of an opinion question than one with a direct technical solution. I would, therefore, suggest you consider asking the question on the Salesforce discussion forums.
– Phil W
May 9 at 6:35
I asked on salesforce discussions forum yesterday..did not get any feedback - developer.salesforce.com/forums/…
– Abhishek Verma
May 9 at 13:27