At MetaBroadcast, we’re always trying to improve our workflow, and one of the ways we do this is by constantly reviewing our tools to ensure they are making us more productive. Every quarter, we all get together somewhere away from the office where we discuss the progress we’ve made and how we can improve in future (we call these “Away Days”). The topics to discuss are different at each Away Day, and this time I was on a team discussing how we can improve our build process.
I think we have a very good build process, but there is always room for improvement and there were some elements in particular that we felt could be improved. With new and better tools being released all the time, the tools we use are under constant review, but a change should not be made unless it’s justifiable and carefully considered first. Here are a few things we decided to look at:
remove “black boxes” from the build process
make hubot commands more flexible
Internally, we use Skype for communicating asynchronously with each other. We use Github’s Hubot automator in order to build projects directly from a Skype room. We generally have a room in Skype per project and have commands to deploy projects from a branch of one of our Git repositories, to either staging or production environments. While this is certainly great for making quick deploys, we could probably make the commands a little more flexible. For example, why shouldn’t Hubot know what room it’s in and then assume that’s the project we’d want to deploy? This seems like a small common sense change to allow us to be more productive. Also, it can be somewhat confusing trying to remember the different commands without flooding the chat room with
hubot help. We’d like there to be more ways to give the same command to Hubot, so we can guess commands and, most of the time, be right!
move away from jenkins
Just recently, we’ve been growing dissatisfied with Jenkins, which we use as our continuous integration server. It’s a pain to configure, a bit on the slow side and the UI is somewhat frustrating to use. We’ve made a commitment to start looking at alternatives to Jenkins, that are able to build Atlas, Voila and Engage quickly and with minimal developer frustration.
see how docker fits in with our current process
As time goes on, we’ve been deploying more Node.js applications to our servers, and we plan to deploy other types of web applications in the future that don’t fit our current deploy process for Atlas. In the interest of keeping up with the current trends as well as finding the best tool to handle these kind of deploys, we’re looking into how Docker can improve this process for us.
The aim of Docker is to to package applications into a container, deploy it and run it on a server. Docker packages extend the LXC container format and create namespaced and isolated virtualisation on a single Linux kernel. It’s hardware and language agnostic – giving us the ability to be able to quickly deploy an app written in any language on any hardware. We’re excited to see whether this is a good fit for the kinds of applications we make at MetaBroadcast, and possibly for Atlas in future, too.
anything to add?
Have you been reviewing your build process recently? We’d love to hear your suggestions on how we can continue to improve ours. Feel free to leave us a comment below or send us a tweet!