ClickDeploy’s Deployment Options from Git

ClickDeploy allows for automated deployments within a CI Job. These automated deployments move metadata from git to the Target Salesforce Org. Within the CI Jobs record, we give users 4 options when choosing the ‘Git Source’ method for deploying metadata. Here are the 4 options that will fit any development branching strategy:

1. Incremental Build

The first option is to commit to the Salesforce org upon any commit or change to the base branch. This will account for all incremental deployments and is easily the most common. For users unsure of which option to pick — ClickDeploy recommends this one. Only user changes are deployed and it is the easiest option for rollbacks.

Pros:

• Adheres most to Salesforce best practices. Enforces the git branch as the source of truth without deploying the entire branch every time there is an incremental change committed.
• More reliable for rollbacks.
• Avoids messy branch strategies

Cons:

• May not fit with a team’s current development strategy.

2. Selected Components From base Branch

A ClickDeploy user will be able to create the CI Job and outline metadata that they wish to have deployed from that base branch. ClickDeploy recommends wildcards as they will find updated metadata that fits that Wildcard type. Each time the CI Job is triggered, it will automatically deploy the metadata fitting the criteria previously outlined.

Pros:

• Can restrict auto-deploy of certain metadata types and set the job to deploy only those you outline.
• Can be useful for ad-hoc deployments or hotfixes where only a few selected components need to be included in the deployments.

Cons:

• Does not enforce the entire git branch being the source of truth which could cause issues downstream.
• Can miss other types if not outlined in other CI Jobs or deployments.

3. Everything From base Branch

The second option, a ClickDeploy user can elect, is to deploy all metadata from the base branch. The Salesforce Org should then mirror the git branch it is being deployed from. This is for users that want git to always be their source of truth. Direct changes within the Salesforce Org will automatically be reverted. Deployments will truly have only one process.

Pros:

• Branch will reflect what is in Org.

Cons:

• Base branch must truly reflect what you desire to be deployed to the Target Org.
• Direct changes within the Salesforce Org will automatically be reverted

4. Differences Between base Branch & Another Branch

The third option is to deploy the difference between two branches. This option is going to be a better fit for teams currently working in sprints that utilize sprint branching. Sprint branching involves cloning a (sprint) branch from the desired target branch. All features and updates made to that sprint branch will eventually be merged into the base branch it was cloned from. This allows for longer development time away from the target branch.

Pros:

• Sprint branches can be used by teams currently following this structure in git.

Cons:

• This requires cloning the branch in the repository and cannot be done within ClickDeploy.

Try ClickDeploy

ClickDeploy provides enterprise-grade release management powered by the benefits of source control and continuous delivery. To explore how ClickDeploy can help simplify and streamline your Salesforce deployment checklist with integrated deployment tools in Salesforce, log in to start your free three-week trial.