AutoRABIT for Powerful Salesforce Continuous Integration
Continuous Integration and Continuous Delivery of applications are essential for higher release velocity and faster go-to-market. With development teams working on multiple parallel releases and multiple Salesforce environments, Version Control is essential for the development teams to maintain isolation, parallelism and change analysis in their development and release process.
AutoRABIT has some very powerful capabilities that can help Salesforce development teams get onboard and streamline their development process with Version Control System. It also has some unique CI capabilities that can keep your deployment footprints lean and also have automated test execution, code coverage, static code analysis enabled as part of CI deployments.
This article talks about the Salesforce Development Environment challenges and why AutoRABIT is the best with its powerful framework for achieving Salesforce Continuous Integration.
Salesforce Development Environment
Salesforce developers can work on individual development sandboxes or share a common development sandbox based on the Salesforce licenses purchased by their enterprise. Developers make configuration and code changes to the key standard objects such as Account, Opportunity, as well as to custom objects as part of their development effort in multiple sandboxes. The security settings on various application components are maintained through a set of profiles in Salesforce.
The release process constitutes migration of changes across multiple release environments, viz., QA/SIT, UAT, Pre-Production and Production. There are some steps to be performed before and after migration of metadata in Salesforce.
After every production release, it is a practice by Salesforce teams to refresh their Sandbox environments to keep their developer and release environments in sync with production.
Challenges in Development
- Multiple Development Tracks: There are several project teams, viz., Sales, Service, Marketing, etc., working with deliverables for minor and major releases. Consolidating all these changes from multiple development teams without stepping on each other’s shoes is a challenge, as metadata, such as profiles and permission sets, are shared for various development tracks.
- Multiple Releases: There are minor releases (config only), major releases (quarterly once) and hotfix releases for any business critical issues that happen simultaneously. Ensuring the development and release environments are in sync constantly across these releases is a challenge.
- Multiple Environments: There are quite a few environments such as SIT, UAT, Performance, Training, Innovation, etc. Maintenance of these environments is a challenge, especially with many pre-refresh and post-refresh activities that need to be done manually after every production release.
- Complex Salesforce Orgs and Heavy Deployments: Salesforce environments are large and complex with large custom objects, profiles and permission sets, and typical deployments contain few thousands of members.
- Governance and Audit for Deployments: Several types of releases happen in parallel and changes are directly made in release environments such as SIT, UAT, which make it difficult to track the changes from a governance and audit perspective.
- Environments Out-of-Sync and Challenges with Refresh: Since changes happen directly on Salesforce environments during releases and some of the BRs may not go-live to production, being rejected in the UAT phase, the developer sandboxes, release environments and production orgs are out-of-sync. Frequent refresh causes developers to lose their work-in-progress as well as induces a lot of manual steps for the development teams.
- Lack of Version Control: Since multiple development tracks happen in parallel, changes to shared metadata members such as Custom Objects and Profiles happen, resulting in overwriting of code. It is not possible to maintain versions of changes, track them and roll them back in the Salesforce environment.
- Manual Steps in Migration: There are many pre-migration and post-migration steps involved in deployments in addition to large deployment footprint.
- Exclusion Lists in Deployment: Security guidelines and architecture recommendations can require certain metadata to be excluded in packaging and deployments. Examples include login IP ranges, SSO configurations, etc. There is no way to skip parts of metadata in current deployment process without heavy manual intervention.
The Benefits of Version Control System (VCS)
- Team Collaboration: Developers can check-in their changes to Version Control System and can share it with other members of the team so that they can constantly keep their environments in sync and also be able to perform code-review process on the changes with mechanism such as “Pull Requests”.
- Change Analysis: Version Control System gives the ability to track various versions of the changes made to a file. It ensures the team is always able to look at application as a series of changes and in case of any bad fix, they can track, isolate and revert the changes done to the metadata.
- Streamlined Release Management: With multiple releases happening in parallel, the application needs multiple levels of isolation to support development phase, release activities and maintenance mode in case of any hot fixes to be delivered. With efficient branching and merging techniques available with Version Control, it would be seamless to maintain multiple versions of the software efficiently and support parallel development.
Salesforce Metadata Structure
Salesforce metadata can be retrieved from Salesforce into local filesystem as well as deployed into Salesforce with its Metadata API. The metadata of the Standard as well as a custom objects are in XML file format.
Typical Salesforce Object Metadata Structure is given below:
Note: As you can see a Custom Object Metadata definition, along with all the child metadata, such as Custom Fields, Validation Rules, Sharing Model, is all stored in the same flat XML file in Salesforce.
Salesforce Metadata Constraints Force.com IDE for Version Control
Traditionally, even though developer works on his sub-metadata type like a custom field, when they request Salesforce from any tool, such as Eclipse, the entire Custom Object will be retrieved from Salesforce. Hence, when the developer pushes the changes to Version Control, the entire Custom Object is available for the check-in. This Custom Object can contain the changes done by other developers on this object metadata, which may or may not be eligible for check-in to Version Control System such as SVN/GIT.
It will put additional challenge on the developer to review all the metadata XML files for changes and edit them from his workspace, before he can send the changes to Version Control System.
Here are the metadata components whose children are also metadata, but are embedded in the same XML file as the parent metadata.
|Parent Metadata||Child Metadata|
Benefits of AutoRABIT EZ-Check-ins
- Check-in Only My Changes: With AutoRABIT EZ-check-ins, developer can retrieve the changes up to the last child metadata type (such as changes to custom fields, validation rules, etc.) that he/she has worked on and submit the changes to VCS instead of pushing the entire object.
- Append Vs Overwrite: AutoRABIT will logically append the modified metadata based on the change done to the file system in VCS, ahead of traditional overwriting of the entire XML file from Salesforce sandbox.
This can ensure metadata components, such as Login IP Ranges, etc., from developer sandbox will not overwrite what is in VCS.
- Dependencies: AutoRABIT EZ-check-ins shows cases of all the dependencies to be checked-in for a particular change.
For e.g., creating a new custom field will have impact on Profiles, Layouts, etc., and AutoRABIT will list all these members to be checked-in, along with their timestamps.
- No Additional Tools/Training: With AutoRABIT EZ-check-ins, there is no need for training on Version Control Systems, no need for additional tools such as GIT/SV/TFS clients and understanding of complex CLI of these tools to perform the check-ins to VCS, as check-ins can be done from right inside AutoRABIT in your browser. Hence, it is easy to on-board Version Control and CI journey easily with AutoRABIT.
- Tag the Changes to User Story/BR: With EZ-check-ins feature, developer can associate his metadata changes to the BR or user story in his ALM.
Challenges with Traditional CI for Salesforce
- Maintenance of the Build Scripts
- The packaging and deployment scripts are to be written using ANT Migration Tool and it needs to be maintained for each new Salesforce release to update/remove the metadata types added/changed in the Salesforce release.
- The scripts are also not robust and flexible, where we cannot retrieve changes based on a “modified date” or by a particular developer.
- If the changes are to be retrieved from VCS such as GIT/SVN, it would mean that additional knowledge of the CLIs of version control tools are required to maintain the scripts maintained.
- Using the scripts, we can deploy the entire changes of a GIT/SVN/TFS/Perforce branch into Salesforce but cannot deploy “Cherry Picked Commits” or changes from a particular baseline revision instead of the entire branch.
- Maintenance of Destructive Changes and Wild Cards in scripts are additional overheads.
- Large Metadata Deployments: The file size of Metadata components such as Custom Objects, Profiles can be really large.
For instance, even though only one Custom Field is modified in a particular release and is checked-in into VCS such as GIT, the check-in will be made into the Custom Object file. Hence, as part of the deployment, the CI job will deploy the entire Custom Object file.
This can cause large metadata deployment footprint when deploying from version control system with CI Jobs.
For most enterprises, the count of Salesforce metadata will be more than 10,000 members and it can always end up in governor limit issues at the time of deployments.
- Maintenance of Package XML: Preparing Package XML file dynamically to list only the members of particular release in the branch is cumbersome.
- Maintenance of the Build Scripts
Benefits of AutoRABIT Salesforce Continuous Integration
- Delta-Based Continuous Integration: AutoRABIT can deploy child metadata components, which are only “modified” in the release and not in the entire Object Definitions.
This can minimize the deployment footprint significantly and make the deployments lean.
- Flexible CI Job Configuration: With AutoRABIT, you can have CI Jobs that can perform the following:
- Deployments Salesforce Org–to–Org from a start date
- Deployments from VCS (GIT or SVN or TFS or Perforce) to Salesforce sandbox
- Deploy the entire branch into Salesforce sandbox
- Deploy from a particular revision from VCS into sandbox
- Deploy a particular revision into sandbox
- Deploy a particular BR/user story directly from Version Control System
- Deployment support for Unmanaged, Managed and Unpackaged Mode in Salesforce.
AutoRABIT Unique CI Capabilities for Salesforce
- Validate Only: Development team can constantly validate deployment of their changes against their release environments so that any possible dependency issues in migration are detected early, reducing the time taken for deployments in SIT/UAT/Pre-Production environments due to dependency issues.
- Automated Apex Test Execution and Code Coverage Reports
- Smart Test Execution: AutoRABIT has the capability to retrieve tests that are committed to VCS in a particular release, run the test classes and give code coverage for the release, providing early warning of lesser code coverage.
- Integrated Data Loading Step: With the integrated Data Loader in AutoRABIT, you can set up Data Loader jobs and add them to your CI Job, so that the entire environment with metadata and data can be set up in one attempt.
- Static Code Analysis: AutoRABIT has static code analysis component integrated into it that can review the Apex Code against the best practices and provide violation reports, along with priorities.