In this post we conclude the setting up of CircleCI for Salesforce. After a quick recap of how we got started in Part 1, we look at the technical components required to enable a simple conitnuious deployment process.

Overview

The diagram below highlights how the different components are connected to enable the workflow described in Using CircleCI for Salesforce – Part 1.
CI_Overview.png

Force.com Migration Tool

The force.com migration tool is a Ant based utility that essentially allows us to automate the process of fetching components from one org and deploy to a target org. For more details check out the official documentation.

Package.xml

Defines which components to retrieve from a particular org or deploy to a particular org. For more information check out the official documentation.

Circle.yml

Since our app is not a standard web app, we need to tell CircleCI how to build our app i.e. how to run the migration tool so that the build process is kicked off. That is the purpose of this yml file. Below is an example

test:
 override:
 - ant -f build/build.xml -lib build/lib/ test:
 timeout: 600

Environment Variables

Since we are deploying to a another org, we need a mechanism for storing the login credentials for the target org. You can reference environment variables in the build.xml using the syntax below.

Below is a screenshot of the corresponding environment variables in CircleCI.

Screen Shot 2017-04-16 at 13.04.04.png

5 comments

  1. It would be nice to have more details on how to setup CI for Salesforce with CircleCI. Currently, I have no idea from where to start and where to get or put all those files you mentioned.

  2. Your post is so confusing. You basically showed a diagram then described some files. You didn’t explain how changes are made, pushed to github/bitbucket and how deployment is done. How is admin changes (e.g. UI changes) done.? Does an admin need to update the package.xml file? But an admin usually doesn’t have that skill…can the package.xml be autogenerated? What is the flow for changes from Prod down to dev and vice versa?

    1. Hi Dianna – thank you for your feedback, the target audeince for this post is salesforce developers who are familiar with the workflow. This could have probably been called out more clearly. With respect to your questions;
      1. UI Changes need to be pulled down (i.e. pull the metadata down from your org and ensure the package.xml is updated along with the corresponding xml files for the changes in question)
      2. I wouldn’t expect admins to update the xml whoever if they are comfortable then why not
      3. There is nothing in the force.com migration toolkit to autogenarate the package.xml – the expectation is that the package xml is manually created or at least maintained by a person. However, this is clearly not ideal and I have in the past used a node app (https://github.com/dlively1/sf-packager) to auto generate the package.xml. This can be used in conjuction with Ant build script to further automate the workflow.

      With the recent annoucement of the open beta of Salesforce DX, I would strongly recommend you look into using Salesforce DX to implement your CI/CD.

Leave a Reply