Configuration Management (CM) Environments

You might have noticed the following lines in our Ant build.xml file.

<property name="env" value="local"/> <property file="local.properties"/>

Although local.properties is our default properties file, this can easily be substituted with another filefor example, test.propertiesusing a command such as the following (on the command line):

ant -Denv=test

This provides the capability to use different files for different deployment environments. For example, Figure 10.8 demonstrates how we could have the same architecture across different environments, from development through production and everything in between, using unique host/server names for our web server and database server in each environment.

Figure 10.8. Our sample application in different environments.

Using external files versus embedding everything in the Ant build file provides us the advantage of saving password and other information in a separate, presumably smaller and simpler, properties file versus a big build.xml file. For example, I have come across the following environments in many companies.

• Local Individual development on a personal computer

• Dev Integrated team-based development on a server

• Test Used for functional testing (also known as quality assurance, or QA)

• User-acceptance testing (UAT) Also known as staging area and used for user testing

• Production Live deployment of the application

For smaller projects, one or two of the preceding environments can be eliminated. For example, if the project uses smaller iterations (two-week fixed cycles, for example) or has a small team (two to four developers), the integrated development environment can be used for functional testing. Alternatively, the UAT and Test environments could be combined into one. So pick and choose the environments that best suit your needs. In short, our Ant file can accommodate various environments by having different property files and using the Denv parameter I demonstrated.