Agile release pattern: Merging configuration

If you want to release your code frequently, you have to automate the release process. If your software interacts with shared components or other applications, the release script may have to update shared configuration files. In this blog post, I recall when I solved this with a crontab file.

The problem

My application needs a cron job. However, the operating system user that runs the application has other cron jobs it also needs to run that don’t belong to my application. I want to script the release, so that all changes are executed automatically.

The solution

I create a directory cron.d/ which contains one file per application. When my application is released cron.d/application.cron is replaced with a new version. After copying out my application cron file, I create a merged crontab: cat cron.d/*.cron => full-crontab, and install it cron full-crontab. The underlying principle is to keep the configuration for separate applications as separate as possible, and only merge them together as late as possible.

In general

  1. Split your configuration into one fragment per independently released application (+ “the rest”)
  2. When releasing an application, replace this application’s fragment with a new copy included in the installation package
  3. Merge the fragments together. For sequential files like crontab files, this may be as simple as concatenating them. For XML files, it’s may a bit harder. But even then, it may be enough to do cat opening-tag.txt *.part closing-tag.txt.
  4. Install the merged configuration

Examples

  • crontab
  • Apache httpd/conf.d files are automatically merged, essentially implementing this approach unnecessary

Comments:

Lars Reed - Aug 27, 2010

+1

Additionally: consider splitting further into - a “delivery fragment” (controlled by the development team, part of the deployment) and - a “local fragment” (preinstalled in each runtime environment, controlled by the operations team – e.g. local URLs, DB names, whatever).

Jerome Lacoste - Aug 30, 2010

+1 to your solution and to Lars.

Basically, look at how Linux/BSD systems have been doing for years in the /etc directory. There’s plenty to learn from.