Continuous Delivery can be viewed as Continuous Deployment with the final step (deployment into
production) being a manual one dictated by the business rather than the development team.
12.2. Implementing Automated and Continuous Deployment
In its most elementary form, Automated Deployment can be as simple as writing your own scripts to
deploy your application to a particular server. The main advantage of a scripted solution is simplicity and
ease of configuration. However, a simple scripted approach may run into limits if you need to perform
more advanced deployment activities, such as installing software on a machine or rebooting the server.
For more advanced scenarios, you may need to use a more sophisticated deployment/configuration
management solution such as Puppet or Chef.
12.2.1. The Deployment Script
An essential part of any Automated Deployment initiative is a scriptable deployment process. While
this may seem obvious, there are still many organizations where deployment remains a cumbersome,
complicated and labor-intensive process, including manual file copying, manual script execution, hand-
written deployment notes, and so forth. The good news is that, in general, it does not have to be this
way, and, with a little work, it is usually possible to write a script of some sort to automate most, if
not all, of the process.
The complexity of a deployment script varies enormously from application to application. For a simple
website, a deployment script may be as simple as resyncing a directory on the target server. Many Java
application servers have Ant or Maven plugins that can be used to deploy applications. For a more
complicated infrastructure, deployment may involve deploying several applications and services across
multiple clustered servers in a precisely coordinated manner. Most deployment processes tend to fall
somewhere between these extremes.
12.2.2. Database Updates
Deploying your app to the application server is often only one part of the puzzle. Databases, relational
or otherwise, almost always play a central role in any application architecture. Of course, ideally, your
database would be perfect from the start, but this is rarely the case in the real world. Indeed, when you
update your application, you will generally also need to update one or more databases as well.
Database updates are usually more difficult to manage smoothly than application updates, as both the
structure and the contents of the database may be impacted. However, managing database updates is
a critical part of both the development and the deployment process, and deserves some reflection and
planning.
Some application frameworks, such as Ruby on Rails and Hibernate, can manage structural database
changes automatically to some extent. Using these frameworks, you can typically specify if you want to
create a new database schema from scratch at each update, or whether you which to update the database