`

Deployments and continuous integration with Autorabit

There are a lot of ways of managing developer's code on the Sandboxes and Salesforce orgs. One of the convenient ways is storing the code on the Version Control (like SVN, GIT, TFS and many others). It is often organized so that different branches store the code of different developers teams, but some of the branches should be periodically merged with other ones. In this case we need to organize some metadata management process which would have some rules of code commits from the Sandbox to the version control with an opportunity to perform periodical merges with different branches.

For example, the version control has the following structure:

There are 3 developers teams which use sandboxes Dev_T1, Dev_T2, Dev_T3. Their code should be stored on the branches V1_T1, V1_T2, V1_T3 appropriately in order to have an opportunity to merge the code and to integrate it to a single environment, in our case we need to have the branch dev_V1 where the merged metadata will be stored. For that we will need to make merges V1_T1 to dev_V1, V1_T2 to dev_V1 and V1_T3 to dev_V1. Of course, during the merges a lot of conflicts appear and have to be solved with the participation of developers.

An issue appears when we need to upgrade the developer's sandboxes periodically from the integrated branch – before the deployment to the dev_T1, dev_T2, dev_T3 there is some data which is being developed at that moment. It has to be retrieved and put on the appropriate team's branch. But it is reasonable to retrieve and deploy all the data except the code (classes, triggers, components, pages, aura components) as they are usually continuously developed and supplemented. Such metadata is committed to the branches by the developers.

To resolve this issue, we have developed a tool which checks which metadata is missing on the branch and sends the remind email to developers to copy their metadata they are currently working on. After that, it retrieves the metadata from the developers sandboxes (except the reminded metadata types which are committed manually) and commits it to the appropriate branches.

After all the metadata is saved on the branches and locally the deployment from the merged branch can be deployed to the developers sandboxes in order to keep the teams updated with all the changes from different teams.

So with organizing the development process, as in the given example, we have an opportunity to have separate developer's sandboxes, branches and a merged branch which can be deployed to the staging sandbox, where all the united changes from all the teams can be tested.

Sometimes during a deployment process the following issue can appear: the unnecessary metadata is left on the sandboxes after continuous deployments from the branch, where the same metadata does not exist (during every deployment only the new components are added and in order to remove the components destructive packages should be deployed). So we end up facing a situation where lots of unnecessary metadata (which should be tracked) is present on the sandbox. To avoid a big amount of post deployment tasks which remain to remove some metadata, the best solution is to run a destructive package. In order to automate this process there was created a tool which compares the metadata retrieved from the sandbox and from the version control and generates a destructive package.

For the Salesforce release management the valuable feature in an opportunity to manage deployments with an option of tracking the metadata. This feature simplifies the deployment process and saves a lot of time.

A good solution for managing deployments is the Autorabit tool. When developers use an ALM such as SVN, GIT or TFS, Autorabit allows you to perform a lot of the actions for deployments automation which are necessary, while deploying metadata from multiple branches to multiple Salesforce orgs.

To organize the deployment environment in Autorabit at first you need to register a version control repository, and branches, and create a Salesforce mapping. Then you can create a project or a single deployment where you can choose a branch and an org to deploy in.

During the project creation there are few additional options such as test running, scheduling (both deployment or just a build creation) – with the help of that feature you can create builds automatically within some time intervals.

So, with this tool you don't need to create any tasks manually, to retrieve the metadata from the TFS and the main point – Autorabit saves the history of deployments for every project automatically, it shortens the deployments time, as with every build of the comparison with the previous build is being performed, what can be seen for every build. Also build and deployments logs are stored as well.

Deployments through the Autorabit allow to deploy any package to Salesforce org you need (both from version control and Salesforce org), with excluding metadata option – it saves time which could be spend on editing a package.xml file.

This is the first post from our upcoming series of deployment and continuous integration best practises.


md.png

Maria - Junior Salesforce Developer, release manager. Outside of work I love photography and to sculpture.

Comment