Six Tips for Automated Releases Oct 14, 2008 • 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.