I consider it best practice to *never* incorporate runtime configuration
information into a build. When asked to do so I also request that I be
given a "way forward machine" that will peer into the future and tell me
where it will be deployed.
Less flippantly, relying on "targeted" builds - builds specific to a given
environment - is not scaleable (environments are always growing in my
experience), aren't maintainable (someone always forgets to update all
the configurations), aren't flexible (someone needs to test on a new,
temporary environment right now and can't because a new configuration and
build have to be created.).
-steve
Stephen Nesbitt
CM Architect/Lead
The Cobalt Group
snesbitt@cobaltgroup.com
x8271
On Tuesday 27 February 2007 2:48:35 am Steve Loughran wrote:
>
> You are moving beyond build-time stuff here into the broader problem of
> configuration management; you are trying at build time to pick a
> specific target installation, because, as we all know, that is exactly
> what you have to do.
>
> 1. keep the separate files under SCM and at build time pick between
> them. Create WAR/EAR files with specific names if you want to reduce
> the risk of accidentally deploying a test configuration to production
> site
>
> 2. have one per host in the JAR and have it decide at run time which
> to use based on hostname or some system property.
>
> 3. Use one of the configuration management tools for java:
> http://www.manageability.org/blog/stuff/configuration-deployment-framew
>orks-in-java/view
>
> 4. eliminate differences between test, staging and production systems
> by having vmware or xen images for testing that match those in
> production: same OS, /etc/hosts set up so even the hostnames of the db
> server match, etc etc.
>
> Me, I use (4) and (3), though I've done #2 sometimes.
>
> -Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
--
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
|