We’ve been shipping a lot of code at Percolate recently: we’ve deployed to production at an average of 9.4 times a week for the past few months. That’s a pretty breakneck pace for an enterprise software application, and, as you can probably imagine, it requires tools and processes that mitigate the complexity and hazard of daily deploys.

Recently, we’ve taken to developing our own tools to help us ship safely and quickly. In this post, I’m going to talk about one particular homespun tool, Jennifer.

On the Percolate dev team, we use (and love) Github for managing concurrent feature development. We structure our development process around pull requests, which give us a kind of single-point-of-truth for the status of a feature.

We’ve found that a rich test-suite is very useful for keeping our code free of bugs and our deploys frequent. Percolate is covered widely by unit- and integration-level tests, so that we can be more confident that a new feature branch isn’t going to introduce problems when we merge it in.

But a test-suite that isn’t run regularly is useless, so to avoid any kind of test-related negligence, we introduced Jenkins into our infrastructure. Jenkins  automatically runs the test-suite against our mainline codebase after each pull request is merged in.

A few months ago, we realized it would be really nice if we could have Jenkins build and report on each pull request via Github comment, instead of waiting to see if things broke after merging in a particular feature. Despite the wide variety of Jenkins plugins available, there wasn’t any easy solution for per-pull-request Github integration. So, we wrote one:

Jenkins jobs created dynamically based on open pull requests.

Jenkins, meet Jennifer

Jennifer is a small daemon that syncs Jenkins jobs with Github pull requests. For each open pull request in Github, a Jenkins job is created and builds whenever the associated branch is pushed to. After each build, success or failure is posted back to the pull request’s comment thread.

Comments are posted to Github that correspond to Jenkins builds.

This has a few beneficial effects on the development process. First: no one ever has to remember to run the tests before a merge happens; we just wait on Jennifer to get back to us with a success or failure before we hit the big green merge button.

Second: it reduces time to deploy. We don’t have to track down a dev to ask if he’s run the tests, since Jennifer has already made that information public, automatically.

Try Jennifer

We’re opening up Jennifer to the public because it’s been useful to us, and Jennifer herself was only made possible by the OSS community. We hope that Jennifer will help others using Github and Jenkins make their development process even smoother.

You can find Jennifer’s source here.

Jennifer helps keep test visibility high and deploys safe. We’re fans.