I suggest you ...

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.

17 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

ALOK BHAKAT shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Mike Havrilla commented  ·   ·  Flag as inappropriate

    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.

  • AdminGearset Team (Admin, Gearset) commented  ·   ·  Flag as inappropriate

    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?

Feedback and Knowledge Base