Six Tips for Automated Releases
• Julian Simpson
(image taken from the JetBrains Team City Photostream)
Today's guest post is from Paulo Schneider at YouDevise. YouDevise is a financial markets information company based in the City of London, and they are hiring! You can also check out their developer blog.
A common goal of agile methodologies is releasing often. With shorter
feedback loops you can be more in tune with your users' needs, and adapt
the development tasks accordingly. However the release process can be a
hurdle if a lot of manual work is required. Here are some tips for
automating your release process:
1- Releasing to test environments should be the same as releasing to
production: during the development cycle we release quite often to our
internal test environments. Thus, it is quite sensible that the release
process should be as straightforward as releasing to production and it
keeps us from having to deal with special cases.
2- Deploy successful builds from continuous integration: it is easy to
automate our release process to grab and build the code from source
control. However, how do we guarantee the commited code is not broken?
If we use a continuous integration tool (such as CruiseControl or
Hudson), it should provide us with completed, deployable build artifacts.
Why not use these instead of source control to get the code for deployment?
At least we know for sure that they have passed the unit and functional tests.
3- Keep per server configuration separate from application: application
configuration is hard. To avoid complicating the automated release process,
separate the configuration of the application from the application
itself. This way we can release the same application to multiple
servers and leave the hard work of configuration to the humans. For instance,
if your application reads a Java properties file on startup, put that file
in a known location on each server, say $MYAPP_CONFIG/config.props, rather than
deploying it as part of a release.
4- Use shell scripting instead of more general scripting languages: the
process of deployment involves a lot of low-level commands and monitoring
system processes, which are suited for shell scripting. If we used a more
general scripting language such as Perl and Python, we would be forever
calling "exec" or "system" and parsing result codes.
5- Use rsync for file transfers: nothing brings down the excitement of a
release than a slow file transfer to production machines. But in this modern
day and age there is a magic pill called rsync
to bring the excitement back. Rsync provides fast file transfers by only transmitting
the bits of the new application that differ from the old version on the
production machine.
6- Use the SSH "authentication agent" to forward credentials: running commands
remotely is a very common task for releasing, and if we run a server farm, we'll
need to access several machines during the process. For security, we should use
SSH to connect to the servers - but it would hardly be an automated
process if we have to enter a password for connection to every server. Using the SSH
agent-forwarding option, you can forward the security credentials and sidestep
the whole login process for all but the first login. Just type "ssh -A myserver"
and you'll be on your way.