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.
We are pleased to announce AutoRABIT 3.9 GA, the first GA release after Dreamforce’15, wrapping up most of the awesome feedback received during the event. Here is an update on the new features that will be made available for our customers over the weekend release scheduled for 17th Jan, 2016:
1. Salesforce Metadata Deployments:
a.Back-up and Rollback – You can now take a back-up of the destination metadata before deploying. The deployment can also be rolled-back in case of any functional issues.
b.Smart Profile Deployments – You can now deploy profiles with an option to Skip Visibility settings for the metadata members that are missing in the destination.
c.Metadata API Support for the Winter’16 release components .
2. Salesforce Data Migration Enhancements:
a.AutoRABIT Advanced Data Loader Pro has become more powerful with its comprehensive circular reference resolution algorithm. The Sandbox environment set up can be a breeze now with the records of an object along with the parent-child relationships transferred all at a time.
b.Filters on Record Types are provided to give more flexibility in restricting what records can be transferred to the destination.
c.Incremental Migration to ensure that you can synchronize your environments by migrating the delta of records on a schedule.
d.Chatter Data Migration support.
a.Thin Client for TFS – Salesforce Teams can now check-in to Team Foundation Server, Register Repositories , Create Branches in addition to deployments right from AutoRABIT .
b.Thin Client for Perforce – Salesforce Teams can now check-in to Perforce, Register Repositories , Create Branches in addition to deployments right from AutoRABIT .
4.ALM Integration – “ No Deployment” Theme supported for Jira
a.Automated deployments can now be scheduled into multiple environments based on the Jira User Story Status with AutoRABIT
b.Attach the metadata changes to Jira tickets for User Story-based deployments .
5.Test Automation Factory
a.Special Automation Templates to automate manual steps with Orchestra CMS deployments, Apptus and Skuid
a.Org Level ACL’s – Org Administrators can now set access control levels for various operations in AutoRABIT at the Salesforce Org level for team members .
b.User Profiles – Users logged into AutoRABIT can now map their Salesforce Org user and their SCM user details making it easier for Administrators in Salesforce Org Mapping step.
Please write to email@example.com for more information and detailed discussion on the Release features.
Yes. We are gearing up for a first major version change after the big AutoRABIT 2.0 launch 8 months ag0 with a superlative AutoRABIT 3.0 .
AutoRABIT 3.0 theme – ” One AutoRABIT for all the release management on Force.com “
” Forget about bits and pieces that you have been using now for various salesforce activities – one half-baked tool for deployments , one manual tool for data loader , Salesforce waiting periods for Sandbox refresh etc.,” – AutoRABIT does it all in most efficient way .
What does AutoRABIT 3.0 mean for Salesforce Community ?
1. Top-5 major requirements of Salesforce release management as heard in many dreamforce events , community blogs and our salesforce clientele viz., automated metadata deployments , Salesforce Data Loader , Sandbox back up- restore procedures , version control support , rapid test automation are all brought under one AutoRABIT umbrella making it super powerful and super useful for Salesforce developers and administrators as a one-stop solution for continuous delivery of Salesforce applications .
What more – You can now procure one month free-trial license for any or all of these components unlike a centralized trial license mechanism before .
2. Auto-Commit to Team Foundation Server – Along with Subversion and GIT , there is an integration built into TFS for either fetching the latest changes from TFS 2013 and deploy into destination Sandbox or directly deploy the metadata between various sandboxes and do an auto-commit to TFS .
This enables business users and developers to have version control being adopted in the organization while they can continue with their normal work till they are all upto speed in using version control as part of their development process.
3 . Test Case Generator – A new robust Test Case generator driven by our comprehensive object repository model for Salesforce ensures that business users can directly write test cases in excel format , logging into AutoRABIT and the automated test cases are generated on the fly.
4. Enterprise Installer [ AutoRABIT on-premise ] Support – After AutoRABIT 2.0 – it has all been PAAS driven – hosted model for Salesforce Applications and thus a great news for the customers who are after us for trial licenses for our enterprise on-premise installers of AutoRABIT . It is confirmed to all that the Beta version of “AutoRABIT -On Premise “ is getting ready for early-bird access in Dreamforce’ 14 .
5. More User-friendliness and flexibility in configuring Projects in AutoRABIT , as well as important fixes like Wild-card support in destructive changes , circular reference handlers in uninstallation and many more – in this superlative edition of AutoRABIT .
Request for a free 30-day trial at this link https://login.autorabit.com . No credit card required.