Continuous Integration Using

As mentioned in my previous post, Team Development on, Continuous Integration is a key part of getting your team to working efficiently. I recently found to be really easy to get setup. They provide a trial with 50 free builds. After that, the cheapest option is $25/month for unlimited builds. I was using it in a matter of minutes after signing up for an account. In this post, I’ll describe how to setup to build your Git branch into a target org.

First we need a repository in Git. works really well with both Github and Bitbucket. I’ve set up a  demo repo on Bitbucket that you can fork and use to try it out. (This repo will deploy a custom object called Test1__c to your target org.) First, let’s look at the things that aren’t usually in Salesforce metadata. At the root directory, you’ll see three new items:

  • lib folder that contains the ant-salesforce.jar – this provides the Ant files needed to deploy to Salesforce.
  • – this provides some settings for the deploy
  • build.xml – this provides the deploy actions we can use to deploy to the target org.

Let’s look a little deeper at the two build files.


This file sets up the deploy targets. Provided are two targets, one runs all tests and the other runs none. You’ll notice there are several variables in use in the file including sf.username. This allows us to avoid hardcoding values and also prevents them from being visible in source control.  We’ll use these later in our setup.

<project name="ci-demo" default="test" basedir="." xmlns:sf="antlib:com.salesforce">

    <property file=""/>
    <property environment="env"/>

    <target name="deployRunAllTests">
      <sf:deploy username="${sf.username}" 
        maxPoll="${sf.maxPoll}" />

    <target name="deployRunNoTests">
      <sf:deploy username="${sf.username}" 
        maxPoll="${sf.maxPoll}" />


This file provides some of the default values for the build. In this case, the default server url is so I can deploy to a developer org. Change this  to to deploy to a sandbox org. The other variable I tend to tweak is the maxPoll. The default is 20 and I find for large deploys this isn’t near enough time to let the deploy finish.

sf.serverurl =
sf.maxPoll = 100

With our repo all set up and pushed to Bitbucket, we are ready to set up the build job. First create an account at You can use your Bitbucket credentials, which makes things pretty convenient later on. After you have your account created, click on “New Project” at the top of the page, select Bitbucket, then pick your repo. You’ll then be prompted to select a language. I just went with Java as that has all the components we need. In the script window, enter the following command:

ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunNoTests

This invokes Ant and tells it to include the ant-salesforce.jar. It then sets the username and password using an environment variable (I’ll cover that in a minute) and finally tells Ant to use the deployRunNoTests target in the build.xml file.

After saving the script, let’s add the username and password environment variables. I use variables here so the password is not transmitted in clear text when success and failure emails are sent.

[email protected]

With everything entered, click Save at the bottom of the page and then click Build Now at the top of the page. You’ll see a bunch of messages display and hopefully something like this:
deploy log


You now have a project setup! It will automatically build every time you commit to Bitbucket. If you use branches, you should go to the project settings and enter in only the branches you want to trigger builds. You can even get fancy and have the build do different things depending on the branch being committed. Here’s an example where we have two different branches. When the branch called develop is committed, we don’t run all tests. When master is committed, we run all tests. You could also have develop build to one org and master to another by changing the username and passwords being used.

[ $DRONE_BRANCH == “develop” ] && ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunNoTests
[ $DRONE_BRANCH == “master” ] && ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunAllTests

Poke around at the other settings. If you find other tricks, let me know what you like to do. Happy developing!

2 thoughts on “Continuous Integration Using”

Leave a Reply