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

Creative Commons License
Agile release pattern: Merging configuration by Johannes Brodwall, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 Unported License.

About Johannes Brodwall

Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. He trains distributed teams and contributes to projects halfway across the world. He is an active contributor to the programmer community in Oslo and Sri Lanka and a veteran speaker in Norway and abroad.
This entry was posted in Agile Release Patterns. Bookmark the permalink.
  • http://twitter.com/llrree Lars Reed

    +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).

  • http://www.google.com/profiles/jerome.lacoste Jerome Lacoste

    +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.