Tip #2: Use a Spreadsheet
Okay, using a spreadsheet sounds odd, but I've seen it serve as a lifesaver in more than one instance. Managing parameters is really about documenting and tracking the configuration of each server and the infrastructure. Providing this information in a spreadsheet does two things. First, it provides a central location for all of the configuration information that can be managed by different people. Second, the information from most spreadsheet programs can be exported in a format that can be used as part of an automated process. Microsoft Excel spreadsheets can be saved as either XML or comma-separated-variable (CSV) files. The XML file can be processed with XML Path Language (XPath) using the Ant XSLT task, and the CSV format lends itself more to processing by Perl. Table 1 lists typical spreadsheet column names, while Table 2 lists typical rows for managing runtime values.
| Column | Cell Content |
| Environment | Identifies the type of environment such as development, testing, or production. |
| Instance | Indicates a particular server when more than one may be in the same environment. |
| Archive | The name of the JAR, WAR, or EAR file to be changed. |
| File | The name of the file that contains values that change between environments and instances. |
| Name/XPath | Locates and identifies the value to change. |
| Value | Sets the parameter value that is to be used for the environment and instance indicated in that row. |
In large organizations, it's a good idea to use two spreadsheets—one for application-specific values determined by developers, and the other for runtime infrastructure values. Security, change control procedures, or simply the size of an organization may require that a production control team separate from developers maintain the infrastructure spreadsheet. A Microsoft Access-type database can also be used, but you lose the advantage of file-based version control. If you have properties files all over the place, run—don't walk—to your favorite spreadsheet tool.
