How we use MavensMate’s “mm” CLI tool, GitHub, and CircleCI to do continuous tests/builds
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.
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
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
mmgenerates to the build
Now, our functional consultants working in Salesforce.com know exactly who to track down when the build fails