The Salesforce Tribe

I had the fantastic experience of being interviewed by Mike Gerholdt and Jared Miller for the ButtonClick Admin Podcast recently. We had a great time and I really appreciated how insightful both Mike and Jared were about my ramblings. I think the biggest theme we uncovered is that you should do what you love. I love working for a company that I believe in and that is making a difference in people’s lives.  I also love making the mundane parts of people’s jobs automated so they can focus on adding value and making a difference themselves. But, one of the things that makes me really enjoy what I do is the Salesforce community.

Over the last year or so, I kept running across the idea of a tribe. And I truly believe that’s what we, the Salesforce community, are.

A tribe is a group of people connected to one another, connected to a leader, and connected to an idea. For millions of years, human beings have been part of one tribe or another. A group needs only two things to be a tribe: a shared interest and a way to communicate. – Seth Godin, Tribes: We Need You to Lead Us

Our shared interest could be Salesforce, but I think that isn’t quite right. Our shared interest is in making it easier to work. Salesforce is just the tool we’ve all found that not only works well for our users, but also makes it easy for us to do our jobs. We have many communication channels that I outlined in my post Getting the Most from the Salesforce Community. We have leaders like Jared, Mike, and all the other Salesforce MVPs.

This American Life had an episode on tribes last year that resonated with me. One of my favorite quotes was in the prologue about how each tribe has ways of identifying true members.

If I come into a group and I say, I’m really a long-lost member of your group but I can’t speak your language and I haven’t tattooed myself. Then it’ll immediately be obvious that I’m not a member of your group. So all groups have what are called “expensive” ways of identifying themselves honestly so that you can’t just fake it. – Jared Diamond

So, become an authentic member of our tribe. Contribute to the community. You will be rewarded.

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!

Team Development on

One of the challenges of working with a team of developers is managing the changes everyone is making and not have one developer overwrite the changes another one makes. In this post, I’ll describe the setup I’ve found to work. I’ll be writing followup posts with more detail describing exactly how I use some of these tools. All tools described work on both Windows and Mac.

1. One developer per sandbox

Each developer should get their own sandbox or developer edition to work in. All changes should be made in their sandbox. This prevents a developer from making a change to a class in their IDE which hasn’t been refreshed recently overwriting a change another developer did recently.

2. Sublime Text with Mavensmate

The combination of Sublime Text with the MavensMate plugin is really powerful. MavensMate makes it easy to retrieve metadata from Salesforce and saving is super quick compared to the Eclipse IDE. I never want to open Eclipse again.

3. Use Source Control to Track Changes

I prefer to use Git because that’s what all the cool kids seem to be using and the tools out there are fantastic. I use Bitbucket because they provide free private repositories for up to 5 developers. The nice thing is there are many options out there that are free/low cost and you don’t have to install a server locally. I like to use the free SourceTree client because I can never remember the git commands. It also lets me more easily see the changes I’m about to commit. As each developer works, they should be working on their own branch and then merging their changes into the master branch as they are finished.  I can’t tell you how many times I’ve used source control to go back and see the changes done. In one situation, a change caused major issues, I was able to go back, reverse the commit, and we were back in business really quickly. When a developer needs to bring their sandbox back in sync with the master branch, they can use the Migration Tool to deploy all the changes back into the org.

4. Use a CI Tool to Build to a Staging Sandbox

Now that you’ve got everything merged into source control, you need an org to test everything in. You could have each developer deploy their changes manually to a staging org, but I prefer to use a Continuous Integration tool to do it for me. I recently found and it is really easy to setup to automate the deploy of all metadata to your staging org. adds hooks to Bitbucket so when a change is committed to the repository, it automatically begins a build using the migration tool. You can get emails on successes and failures. The one drawback is that there isn’t a way to deploy destructive changes automatically. Any deletion of objects, classes, pages, etc need to be done by hand.

I hope this description of my environment helps you get your team up and working peacefully together!