EC2 Continuous Deployment: Hello world

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.

Continuous integration

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.

Target  stack

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

Outline

The series is comprised by the following articles:

About these ads

One response to this post.

  1. really cool series. thanks Jeppe

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: