Mudbath is now a continuous deployment server

At this point Mudbath, originally a continuous integration server which I wrote in early 2012, has gone through two transitions. Though it remained true in its original intention, which is to be a tool which automates work and takes certain responsibilities off my mind.

One of my biggest concerns when working on my personal projects is to make deployment as easy and seamless as possible. Not only for me but also for my colleagues who have no knowledge of the infrastructure on which the apps run. And also, nothing is as frustrating as spending an hour to deploy a three line change in a CSS file (this is no joke, happened last Friday at $DAYJOB).

The last transition made Mudbath into a server which handles deployments. It is tightly integrated into and controlled though GitHub.

History and reasons for change

The first version of Mudbath was a CI server, completely standalone. Around December 2012, after GitHub released the commit status API I did a major rewrite to make use of that new API. Since then GitHub has updated its API once more, this time adding API to manage deployments.

The deployments API lets users create deployment requests on GitHub. What is a deployment request? It is essentially a branch name and some metadata which describes where you want to deploy it. For example: Deploy master to production. Or deploy some-feature-branch to server B. External services which are configured to be notified on those events can then react accordingly. There also are some other goodies in the API which you can read about on the deployments API documentation page.

Now back to Mudbath. It is one such service which can receive the deployment events from GitHub. When mudbath receives such an event, all it does is run an executable. It can be a shell, ruby, python script, or a compiled C program. Mudbath doesn't really care.

Building and Configuration

Mudbath is written in Haskell and compiles into a single, mostly static executable. The only external dependency which is not readily available on Linux systems is libgmp. The little bit of configuration which it needs is done through environment variables. See its README for more details.

The executables are expected to be in a ./config subdirectory of the current working directory. The full path is constructed using {workingdir}/config/{user}/{repo}/{environment}. As you see the environment is part of the path, so you can have separate executables for each environment. Currently Mudbath does not make the extra payload available to the scripts.

Triggering deployments

If you treat your master branch as always deployable, and have a sensible CI setup which will tell you when the branch is green or not, you can allow anyone to say deploy master to production.

Instead of entering that into a terminal as a sequence of shell commands, it is far easier for everyone to enter that into a shared chat room (Such as IRC, Campfire, Hipchat, Slack). That way anyone sees what's happening around the project.

The term which is often used for this setup is ChatOps. It's a play on DevOps, emphasizing the fact that everything is being done through chat instead of a terminal. GitHub has been using ChatOps internally for a long time. They even wrote their own chat bot: Hubot. Now there is a large ecosystem of plugins available.

One of those plugins is hubot-deploy, its purpose is to listen to deploy X to Y messages and create corresponding deployment requests on GitHub.

With Hubot and Mudbath in place, deployments become so easy that you don't even have to think about them. You just push new code to your GitHub repository and then announce to your chat room that you want to deploy the new code to your servers.

Similar projects

GitHub has recently opensourced Heaven. It is Rails server with similar purpose as Mudbath. It requires a SQL database and Redis, so is lot more difficult to set up than Mudbath.