Salesforce is not just any typical application from an architectural perspective. With Salesforce, the majority of the program logic is stored in XML files unlike J2EE or .NET applications. These XML files are then used with the Salesforce Metadata API to deploy program code into an instance of Salesforce, often referred to as an "Org."
The problem with many source control systems is that they aren't the best at figuring out how to merge differences with XML files, especially when the sequence of the information within the files differs between Source Orgs and Destination Orgs. Salesforce provides two options - Change Sets and the Force Migration Tool - to deploy updates from one Salesforce Org to another.
Change Sets are a UI-driven deployment function that works well in Salesforce, but demands manual efforts. To create a Change Set, the developer has to simply select any number of the changes, package them into a Change Set and determine the target Salesforce Org(s). Change Sets are probably the most-used process to deploy Salesforce updates, however, pose the following challenges:
- The changes must exist in the Salesforce Org where the Change Set is being created.
- Once the Change Set is created and deployed, it cannot be updated.
- The Change Set developer must know every item that is changed when building the Change Set.
- A Change Set is limited in size and cannot include each and every design element in most of the Salesforce implementations.
- When a Salesforce implementation contains several design elements and updates, the process to continue to use the pagination system with an option to select more can become quite tedious.
- There is no source control/change history aspect to this delivery method.
Force Migration Tool
The Force Migration Tool follows an Ant-based mechanism to deploy changes based upon a set of source files. This approach uses Apache Ant and a custom Salesforce connector to talk to the Metadata API directly. As a result, the Force Migration Tool yields the following benefits:
- Change sets do not need to exist in a given Salesforce Org and are sourced from an external repository.
- Using source control, changes can be made to the source files as if they are used in a Java or .NET application.
- There is no need to know each and every change since the source control system is able to identify these updates.
- An entire Salesforce implementation can be pushed to another Org using the Force Migration Tool.
- Using the Force Migration Tool, changes can be removed using an un-deploy, destructive change process.
Nevertheless, the Force Migration Tool is also not 100% challenge-free due to the following issues:
- Usage of regular expressions within the build.xml is required to remove elements at run-time which exist in Salesforce but do not seem to migrate from one Org to the other.
- Usage of Ant-based commands (like delete) is often required to remove files that cannot be migrated.
- The process requires continuous attention, especially during Salesforce core releases, to address new challenges. New elements are often added or old items are removed, both of which can cause errors with the Force Migration Tool deployments.
How does AutoRABIT help?
Considering the above challenges encountered by Salesforce developer community, AutoRABIT came up with a complete suite of tools for Salesforce Continuous Integration and Continuous Delivery. AutoRABIT’s CI Jobs feature enables the following:
- Deployments from one Salesforce Org to another Salesforce Org
- 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
An overview of how developers can run CI jobs using AutoRABIT:
- Developers use a Salesforce Org to make changes and commit to any popular SCM repo.
- The QA Team tests the changes in the same Salesforce Org with TAF, Provar, etc.
- Upon approval, the developer can create a new branch in GIT and then use Eclipse with the Force IDE to pull the changes from their Salesforce Org into their branch. Once the code is checked-in, the developer can schedule the build.
- Developers can deploy parent-child metadata components, which are only “modified” in the release and not in the entire Object Definitions.
- Once the tests are successful, the developer creates a Pull Request in SCM, which is reviewed by the other team members with Gated check-in control as and when required.
- Once the Pull Request is approved and merged, the Salesforce Org that is used for integration can also be used to perform a test deploy with the approved code, and then the tests are commenced in that Org.
With AutoRABIT’s CI job feature, it is easy to onboard the CI journey. It minimizes the deployment footprint significantly and makes the deployments lean. For further information, contact us at email@example.com