Note: This is the fifth (and last!) article in the series on continuous deployment. If you want to start with the overview, go here.
Finally, we’re coming to the end of the road. The only things left in order to finish the continuous deployment cycle are these steps:
- Run integration tests
- Shutdown instance
- Add new nightly job to Hudson that runs the integration tests
Note: This is the fourth article in the series on continuous deployment. If you want to start with the overview, go here.
What we’ve done so far is a pretty basic Continuous Integration setup. To take this to the next level, we’ll add a new job, to be run at night, that provisions and configures a new EC2 instance, deploys the application and runs the integration tests.
The steps that needs to be executed are
- Start a new EC2 instance
- Configure the instance with all the software needed to run the application (in our case Jetty & nginx)
- Deploy the application
- Run the integration tests
- Shutdown the instance
Note: This is the third article in the series on continuous deployment. If you want to start with the overview, go here.
We can now build our application manually, but need to automate the actual build process. For this I’ll be using the Hudson Extensible continuous integration engine. I’ve been using CruiseControl for many years, and while it does the job, I’ve been annoyed enough that I’ll try something new.
Note: This is the second article in the series on continuous deployment. If you want to start with the overview, go here.
The app we’ll deploy will just be a simple “Hello World” application, written using Lift, a very nice Scala web framework. I will not go into any Scala or Lift specifics in this article, but will show how to build it.
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.