Commit-by-commit deployment
As you are giving an option to trigger the CI job based on repository commit, it would make more sense to only compare the source and target based on the commit items and consider the commit changes for deployment based on your selection of either new, modified or deleted and the comparison filter(which can be optional in this case).
This will help in reducing the chances of overriding the changes of other teams working in a shared environment or an environment not in sync with the branch.
There can be other scenarios where we maintain managed package items in the repository and do not want it to be deployed and exclude it in the comparison metadata filter. But for now, Gearset is also unable to identify managed package items in Git repository and that would cause unnecessary items to be either added or deleted from the target.
ALOK BHAKAT
shared this idea
This was released on the 23/03/2021. Documentation is on https://docs.gearset.com/en/articles/5069914-delta-ci
-
Alexis Rafesthain commented
Ability to only deploy the difference between the last 2 commits (incremental build) will dramatically reduce the time to run a CI job
-
Vivin Mathew
commented
Yes commit by commit is a very much needed feature.
-
Ramesh Ale
commented
This is a major limitation of Gearset CI functionality. Because of this, I am about to setup CI outside Gearset, Because it always does the comparison between repository and Org and deploys all differences, instead it should only deploy what is changed in the current commit. But this should be an option. Some companies want that and some don't.
Also surprised that this didn't get any attention from Gearset in last 10 months. Please let us know what details you need from us to deliver this feature. Thanks!
-
Mike Havrilla
commented
We would like ability for CI jobs to only look at changes made in a commit.
Sometimes things like page layout changes, field level security, permission set assignments, profile changes happen in higher orgs on the fly without making it down to lower orgs right away or until the next refresh. We don't want a CI job to overwrite those changes *unless* one of those items, like a page layout, is specifically included in the commit.
-
Hi Alok,
Thanks for the suggestion, can you give a little more detail why you want to see this?
Are your orgs and your repository currently in drastically different states?
Are there a certain set of things you want to exclude from every CI deployment? Does this change from deployment to deployment?You mentioned about overwriting changes, could you give us a bit more information on your current development process and how the risk of overwriting changes comes about?
-
Mike Havrilla
commented
This would be very beneficial!
-
Anonymous
commented
Yeah, make perfect sense and a much-needed one. Big thumbs up