I have the same requirements for Dev, Test, QA, Prod and use Drew's approach.
Interestingly, to me... On Wed, Dec 1, 2010 at 12:33 AM, Drew Wills <awi...@unicon.net> wrote: > I think one of the more significant groups who *aren't* interested in this > approach are those who, by preference or through organizational fiat, hope > to deploy the same built artifact to every environment: the *exact same > build* goes to dev, then QA, then perf test, and ultimately to prod. This > group is sometimes interested in building the portal with the filter tokens > intact, then performing the replacement as a part of the deployment process. ... a variation on this is something I kind of expected to find. The goal of using the exact same build is appealing, but invading the build during deployment to find and replace configuration values is not. My preference would be to read values from configuration files that were external to the build. A nice example of this is Tomcat. We can deploy a CATALINA_BASE separate from the Tomcat software and the environment variable tells Tomcat where to find it. Tomcat's configuration files are not embedded in with the code. Chief among my concerns is establishing a demarcation point between operational and engineering roles. SysAdmins (operations) need to be able to edit some parts of the configuration, such as to change a host name for a database server. I don't think it is appropriate for SysAdmins to be editing files deep within a build, but clearly they're used to editing configuration files in /etc, for instance. A positive side-effect of this approach is that having separate configurations for different runtime environments -- using the same build -- is usually easy. -- Bruce Tong Software Engineer Office of Information Technology Ohio University -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
