This post is partly a definition and partly describes ideals that have served me well – it is not meant to be prescriptive – please provide constructive feedback!
Useful deployment automation describes EVERY change required to install and configure a complete service.
A separation of concerns is required to describe the essentials here. I have used the word “scripts” but flat file input to any deployment automation tool could be used.
Ideals:
The following ideals have served me well:
- NO ENVIRONMENT specific information should be embedded in the scripts. This enables the same script to be tested thoroughly and, when appropriate, used from development, build, staging and in production see Environment Configuration.
- Scripts have to be stored in source control.
- Where possible, ALL script dependencies should be stored in the same repository and use RELATIVE paths.
- When dependencies are not stored (e.g. deployable artifacts) – they should be referenced unambiguously (CRC’s serve well here).
- Any script language or flat file input to a tool that is appropriate to the task should be used.
- Any automation should check every input and fail if ANY step is unsuccessful (problem solving is easy when detected at the point of failure).
- All automation should reuse the same building blocks by breaking down the entire system requirements into deployment
The separation of configuration from automation is the most important point here to enforce repeatable testable deployments. Doing this properly is at the heart of Release Management.
Tools:
The simplest tools with the least system dependencies are the best fit for some of the ideals I express above.
At its simplest, environment management can be easily implemented by even Batch and Shell scripts with a little help from run XSLT processors. XML configuration can easily provide all the environment specific input.
Other scripting languages that are equally applicable to system management and provide better support for XML configuration input include Perl, Ruby and on Windows; PowerShell.
More recently, tools which try to holistically solve deployment automation include RPath, Nolio and build servers like AnthillPro. These tools introduce very specific ways to working which need a high commitment to a single vendor without the ability to easily share the solutions.
Orchestration
In the spirit of separating concerns it seems best to separate the actual release that can take place on one host from the steps that coordinate the release across multiple computers. The same orchestration steps can then be carried out on a single node (e.g. development) or systems with varying number of nodes (e.g. test, staging or even separate production installations for separate customers).
The specific host names and the mapping of roles that they carry out should be stored separately from actual orchestration steps (which should be concerned with roles only). This information forms part of the Environment Configuration.
