Supporting Multiple Environments - Part 2
•
(see part one of this series here)
(A guest post kindly written by EJ Ciramella)
In this installment, I’m going to cover the four cheap-fast ways I’ve seen discussed to generate configuration for your application.
Managing Configuration
There are a few ways I've found or seen discussed over the years for managing the configuration portion of a deployment (local or otherwise). I don't think one way is the best way for everyone, each company is unique. The decision should be based on what suits your company best, not how many plugins you can configure or how can you change the way business operates (within reason). There are other, more complex ways; like Spring based configuration. This discussion is limited to the cheapest (simplest) way to manage configuration. Below are four very common approaches.
- Spin a version of your deployable unit (preconfigured) for each deployment option (one artifact)
This is the most expensive (with regard to time and space) option of the four. This option assumes that you have very few deployable units and very few stacks to deploy to. This option can be configured via profiles in the POM and leverage values either stored in profiles or in a settings.xml (or a host of other inconvenient ways). After what I've seen during my recent stint interviewing and what I've seen come across the Maven mailing lists, I think this is no longer an option for most. This becomes painfully obvious when the artifact starts getting beyond 50 MB. This concept fails to scale with the addition of machines or deployment environments.
- Spin a single version of your deployable unit and build multiple configuration artifacts (two artifacts)
At a previous employer, this was the initial choice for a first foray into configuration for our deployable units. This regularly took about three hours to finish and each additional machine was painful to manage (all stored in the build user's settings.xml checked into Perforce), let alone adding additional stacks. To add insult to injury, having to sit through another three-hour build because ONE machine in ONE stack had ONE property tweaked was both painful and embarrassing. This option also fails to scale with the size or complexity of the environments you're trying to support. Each additional stack could add upwards of 10 minutes each.
- Spin a single version of your deployable unit and have it include templates and configuration for those templates (one artifact)
This is a step in the right direction. But the configuration is still bound to the artifact you're attempting to deploy. It seems like a waste to generate a new deployable unit if the configuration for a particular application in a given deployment environment has changed. To a degree, this approach also fails to scale. You'll end up including more and more configuration.
- Spin a single version of your deployable unit and have it include templates with separate configuration (two independent cycling artifacts)
This is the final evolution I chose. Breaking out the configuration from the actual deployable unit and making the configuration its own artifact (ie pushed to our repository manager) allowed the same version of an application to be instantly redeployed (with the option of just reapplying configuration to an already deployed application) with a configuration change that took merely seconds to build.
Continued...
In the next installment, I’m going to cover the configuration storage mechanism for this separate configuration jar approach.