replace-properties from sql/.create-table.sql to sql/create-table.sql

Configuration variables do not have to be included and can be specified at configuration time. This allows the administrator to keep the security sensitive properties apart from the general settings.

Cheers,

Mark

I can see how the customization descriptor, assuming it is written in a fairly human-readable way, can provide some visibility into the customization process, especially if the customizations for the entire package can be reviewed in one file. Pointer syntax (think XPath) can be hard to interpret, but that be mitigated by including a plain text description of what is actually being pointed to.

I’d be more curious to know how this approach provides safety, however. Idempotency prevents you from screwing up if you run the customization multiple times, but that doesn’t address the issue of customizations not being applied at all. Of course, your tool may somehow integrated with the app server…

Regarding the other points:

> 1. Pointer based is precise. You will NOT have any accidental replacements and
> if it performs a incorrect replacement, it is consistently incorrect

Agreed, although with a suitable placeholder syntax (${...} or whatever) accidental replacements should not happen either. Certainly, plain string search’n'replace is something to avoid if at all possible.

> 2. Pointer based is non-intrusive: No changes are required to the source
> files themselves.

Indeed – perhaps the main reason why pointer-based replacement scores ‘High’ for convenience.

> 3. It supports strict separation of responsibility between developer and
> deployer, although best results are achieved when they cooperate.

That depends largely on whether or how the customization descriptor splits the pointer specification from the specification of the actual values. This also determines, to a large extent, how well the system can deal with sensitive data that should only be seen by deployers (the production database password, for instance).

> 4. Above two features allows you to configure any deployment unit, not just the
> once that were prepared by the developers.

Indeed – that’s what I meant by “Ironically, this can be useful in order to “patch” packages that were not written in a customizable way.” It shouldn’t be forgotton, though, that pointer-based replacement only works if the targeted files have a suitable structure where elements can reliably be pointed to.

For .properties files this is fairly trivial, and XML supports powerful, fine-grained pointers via XPath (although constructing these for e.g. a piece of WebSphere configuration XML can be a non-trivial exercise!), but modifying an SQL script via pointers can present some interesting challenges.

Nice article and good to see that you have named the different styles of customizing deployments.

In a solution that I created for a customer I introduced the concept of configurable deployment units. A configuration deployment unit contains all the relevant instructions to tailor the deployment unit to a specific environment. A important feature of this deployment unit is that the configuration operation itself is idempotent. Repeated configuration of the same deployment unit delivers the same result (unless the parameter values change).

A self contained configurable deployment unit is a specialization which also contains all the parameter values for the different environment (D, T, A and P).

The deployment configurator executes the actual instructions, provides the visibility and safety features that you claim are inherent disadvantages of the pointer based replacement pattern. You could even improve the tooling surrounding the configurable deployment unit to provide more insight into the configuration process to the developer and deployer alike (For instance through an eclipse plugin).

In addition, the configurator does support token based replacement as well but you have to explicit instruct it and provide a source and target name to ensure idempotency of the configuration.

The reasons I prefer pointer based above token based are:

1. Pointer based is precise. You will NOT have any accidental replacements and if it performs a incorrect replacement, it is consistently incorrect
2. Pointer based is non-intrusive: No changes are required to the source files themselves.
3. It supports strict separation of responsibility between developer and deployer, although best results are achieved when they cooperate.
4. Above two features allows you to configure any deployment unit, not just the once that were prepared by the developers.

Cheers,

Mark