WEBINAR : 3 Phases of Salesforce DevOps: Join us on 8/23 @ 10:00 a.m CT.  Register now

+1 925 500 1004

Blog Circle icon

Validation of the Delta Before Merge


Merge plays an important role in the devops life cycle as the version control is the “source of truth”. Merging source code from one branch to another branch is simple, but we may face problems while deploying. This is due to missing dependencies in the source code. This is critical when it comes to deploying packages in Salesforce instances.

Validation of the Delta Before Merge

Solving for the Delta
What’s the Delta? Simply put, it is the changes or differences between the Dev branch and the Integration branch identified as a result of the merge process.
If not all the proper dependencies are identified and validated first, the deployment does not fail.
Once you have identified the delta and validated the changes and dependencies against the salesforce instance, you can then prepare the package and send it to the receiving instance for deployment.
Sounds confusing and potentially disastrous as it is highly prone to human error, yet there is a better way.

The AutoRABIT Way
This diagram explains the step by step process that AutoRABIT customer use to solve that very problem.

Validation of the Delta Before Merge

Once the user initiates the merge from the Dev branch to the Integration branch a label will be created in AutoRABIT and the following process ensues:

  1. Changes are merged from the Dev branch to the Integration branch without committing to the remote repository.
  2. A separate (checkout) copy Integration branch is created and maintained in a remote repository source in a completely separate location.
  3. Next, the deltas are processed on both locations.
  4. The package is prepared for deployment and the deployment request sent to the Salesforce instance for validation.
  5. A Difference Report is provided to the users to show the delta.
  6. Static Code Analysis Report is published based on the delta.
  7. Next, the Admin can approve or reject the changes.
  8. Then, if approved, the user can merge the actual changes to the remote repository.

After the successful merge, we can deploy the Integration branch changes to the Salesforce instance and rectify any deployment failures.