Once in a while I find myself in a conversation on builds and releases. Ā It’s one of those where before the conversation everyone seems to be on the same page, but immediately after the conversation starts, there’s a massive fight and argument as to how the world works today and what’s the best path into the future. Ā And it gets messy.
I believe that the old approach of one release a decade is dead. Ā Especially in web application development. Ā The world is much more dynamic now, and so should be the release plans. Ā This seems obvious to many, and yet, not a lot of people understand the implication of this. Ā Making releases more dynamic means making the release operation cheaper, ideally – free. Ā Can you release a new version of the project once a day? Ā How about every hour? Why not? Ā You should be able to. Ā Regardless, whether you will actually release every second or not, the path to making releases cheap is automation. Ā And that means you have to have some form of software version control, and some form of build or deploy script. Ā And, of course, some form of rollback script for those times when things go hairy.
One of the things that I do at my current job is setting up such a deployment process. Ā I’ve done it before, but it’s been a while, and given how fast these things change and improve, I’ve been looking around for new tools and ideas. Ā While doing so, I came across an interesting GitHub blog post. Ā And while their requirements and environment are different from mine, I still found it useful. Ā One of the things that shows how well their process works is the stats at the end of the post. Ā Just look at them.

That’s about 100 deploys per day! Not bad, not bad at all.