I’m a strong believer in agile development and one of the biggest benefits I see is to get working software in front of the customer as fast as possible. The term ‘working’ may mean different things to different people but it does imply that there’s some level of quality that needs to be achieved.
Many developers consider their job done when they’ve committed a feature and the build is successfull (you do run some sort of CI don’t you?). But this does not bring the software in front of the customer. In many places, doing a production deployment is a large, manual process with lots of opportunities for mistakes, which means that deployments either take longer than necessary or happen infrequently.
Timothy Fitz wrote an interesting entry about Continuous Deployment, basically deploying to production after each commit. While I don’t think deploying to production after every commit is workable for everybody, the idea of actually deploying the latest code automatically is very valuable. This article series will cover the basics on how to get a simple software product deployed automatically.
I’ve found the following CI setup useful:
- On every commit, a smoke test build is performed. This generates all the artifacts and runs all the unit tests. This build should execute quickly (less than 5 minutes) in order to provide quick feedback to developers.
- At predefined intervals (i.e. nightly) a full system deployment is made and all automated integration tests are run. The rationale is that the integration tests usually take too long time to include within the normal build since you need to deploy, databases are usually involved etc.
The last point implies that deployment should be automatic, but I’ll take it one step further and also automate system provisioning. Since we’ll be running the production site on EC2, why not take advantage of this during testing and launch new instances for testing? In this way, we’re also testing our system configuration scripts.
These articles are not meant to be tutorials for all the software involved, entire books could be (and have been) written on these subjects, but just to show how to get a basic stack up and running. So without further ado, this is the software I’m going to use
- The Lift web framework, written in Scala. While I’m no Lift (or scala) expert, I do like what I’ve seen so far and would try to base future projects on this.
- Gradle for building. I’m sick of Ant scripts and while Maven has the right ideas I think the XML files are a nightmare.
- Hudson for Continuous Integration
- Jetty as App server. I’ve been using Tomcat for many years, but have recently switched to Jetty for development, since you can setup a nice development environment with quick turn-around times.
- nginx as frontend/loadbalancer
- Chef as system configuration tool
- Amazon EC2 as deployment platform
The series is comprised by the following articles:
- Building the software – Shows how to build a simple Lift webapp using the Gradle build system
- Managing the build process – Shows how to setup the Hudson continuous integration server to automatically build the software
- Cooking with Chef and a stint of Gradle – Shows how to provision a new EC2 instance using Chef and Gradle
- Wrapping Up – Perform a crude integration test and outline some possible next steps