Gated Merges – A Criteria-Based Approval Process for Pull Requests
A Gated Merge is a criteria-based approval process for pull requests that provide an early-warning system for Salesforce merges. Using this, merging is as easy as writing a “Hello World” script. This article will help you get the most of out of this feature, which is only available in AutoRABIT.
How Do Gated Merges Work?
What are Pull Requests? – Developers initialize a pull request to propose and collaborate on changes that need to be integrated into a forward branch.
Gated Merges are used to enforce conditions on the pull requests based on a set criteria for individual branches or branch patterns.
The enforced conditions include:
- Deployment Validation – Performs a mock deployment on your QA, Integration, UAT or Production orgs to determine if the merge will break during deployment
- Code Review –
- Apex Class/ Trigger Monitoring – Preempts your Apex Test Class failures and code coverage results before merging your code
- PMD – Finds common programming flaws such as unnecessary object creation, empty catch blocks, unused variables, etc.
- Diff Report – Generates a line-by-line Diff Report of “as if” and “to be” changes.
The Flowchart below depicts the process flow of Gated Merges
After meeting the pre-set parameters, the approver/reviewer can choose to accept or reject the pull request.
Consider this example, which will probably sound familiar to you:
You’re a Salesforce Administrator or a Release Manager overseeing a mid-size development team building an Expense Management application for your business. The team uses two source code streams: Integration and Release. Without Gated Merge, each time a developer merges a change into the Integration or Release branch, you won’t know whether the code worked or failed until the day of your Production deployment. A failed deployment at this stage is likely to put your business commitments in jeopardy, not to mention subject you to a whole lot of frustration.
With Gated Merge, a Salesforce-specific review process is initiated whenever a developer raises a Pull request. The review process does a mock deployment on your Integration Salesforce org, confirming the change to be a “Good” or “Bad” change. Apart from the mock deployment, you also get to see a PMD report and a line-level Diff report on the changed Apex Trigger. This guarantees a quick, fun-filled Production deployment.
Why are Gated Merges Important for Your Salesforce Development?
Version Control Systems such as GIT and SVN are used to manage and version files (obviously). For Salesforce, which uses XML file structures storing configuration and meta information, the smallest unit is an element which typically spans multiple lines. The version control systems do not have Salesforce source code that comprehend such XML files and this results in XML file corruption (malformed XML). This shortcoming can lead to invalid XML files or missing nodes causing Salesforce specific code errors.
The image below shows the XML file of a Profile
Gated Merges provide a mechanism to preempt XML file corruption, code mis-match, deployment failures in Pull requests. Enforcing conditions to validate merges reduces the risk and cost involved in deployments by allowing you to spot and fix defects earlier in the process.
Ready to try Gated Merges? Click here to get started.
Catch up on the previous post on another cool new feature of AutoRABIT, “Delta Deployments powered by a lean-packaging model”