How we use MavensMate’s “mm” CLI tool, GitHub, and CircleCI to do continuous tests/builds

Posted by in mavensmate, salesforce

As Mavens has grown over the past 5 years, the projects we work on have only become more complex, often using a mix of platforms, frameworks and programming languages (Force.com, Heroku, Amazon, Apex, Python, AngularJS, Ruby on Rails, etc.). Over the past 6 months, we’ve started to standardize our build/test automation on a service called CircleCI. For Force.com specifically, many of our projects follow a model that could be interesting to some:

  • we write code in Sublime Text using MavensMate
  • we commit code to GitHub
  • we use CircleCI to run our automated tests/builds/deploys
  • we use Chatter to ensure everyone’s aware when the build is broken

How does CircleCI know whether our build is passing or failing? We use the mm command line tool that’s packaged with MavensMate.app to run a build for our project. MavensMate also has some pretty nice UIs for things like Apex unit testing, deploying, etc., so we tell mm to generate us a pretty code coverage report and create some log files as well. So, let’s take a look at how it all works.

Build Script

First, we have a basic Python build script (buildtest.py) in our project’s “test” directory. Here’s what it contains:

As you can see, we’re running a simple Python unit test, however, the script is calling the mm command line tool’s “build” command and passing in some tests we want to run as part of the build. mm will do its thing, print the output, and place log files and a test coverage report in the project’s test/result directory.

mercury-force.sublime-project — mercury-force 2014-02-28 12-53-41

MavensMate 2014-02-28 12-59-21

GitHub/CircleCI

CircleCI is a nice little tool that does continuous testing/building/integration in the cloud. It has seamless GitHub integration, so we simply tell CircleCI to watch one of our GitHub private repositories. Then, when it detects a push to one of the repository’s branches, it will attempt to build the project. Of course, CircleCI does not natively know how to run Apex unit tests and compile our project. However, CircleCI is incredibly flexible, so you can set your own environment variables, run custom build commands, save build artifacts, etc. So, in our case, we tell CircleCI to run our custom Python build script. Here’s our circle.yml configuration file:

You’ll notice two things:

  • CircleCI can notify an external endpoint with the results of the build (in our case: https://custom-mavens-app.appspot.com/build-notify). At this endpoint we have a short script that logs in to Salesforce.com on behalf of the committing user and posts the CircleCI build results to Chatter for all to see.
  • CircleCI can associate what it calls “artifacts” to your build. We use this feature to associate the test log, result and unit test report that mm generates to the build

Group: Mercury Builds ~ salesforce.com - Enterprise Edition 2014-02-28 13-09-17

Now, our functional consultants working in Salesforce.com know exactly who to track down when the build fails :)