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
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.
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
The underlying principle is to keep the configuration for separate applications as separate as possible, and only merge them together as late as possible.
- Split your configuration into one fragment per independently released application (+ “the rest”)
- When releasing an application, replace this application’s fragment with a new copy included in the installation package
- 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.
- Install the merged configuration
- Apache httpd/conf.d files are automatically merged, essentially implementing this approach unnecessary
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).
+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.