Using CM to Manage Application Deployment

be difficult to automate the deployment process. I like to use a bit of shorthand for these methods:

• Fixed Location: ""
• Target Directory: "/="
• Tree Under Target Directory: "/*"
• Sub-tree Under Target Sub-Directory: "/+"

So, for example, I might have the following deployment directives for an application:

(1) Deploy all system files to their fixed locations. The fixed location would be part of the configuration data for each file, and would itself be under revision control so that the location could change over time if required by either the platform or the application:

deploy System-File-List

(2) Deploy all *.help, *.pdf and *.chm files to the "/help" directory. Here is a customer defined location for deployment of the application. Similarly, all executables (*.so *.dll *.exe *.sh *.bat) files are deployed to the "/bin" directory:

deploy *.help, *.pdf, *.chm -to "myapp/help/="
delpoy *.so, *.dll, *.exe, *.sh, *.bat -to "myapp/bin/="

(3) Deploy all "myapp_*" directories, sub-directories and files to the "" directory under the respective directory paths:

deploy myapp_* -to "myapp/*"

(4) Deploy a few relative application directories (and their sub-directories) where they need to go:

deploy client_data_common -to "myapp/data/+"
deploy client_data_option1 -to "myapp/data/+"
deploy images -to "myapp/runtime/images/+"

If the CM tools provides this level of capability, so that you can specify a set of objects, how they are to be deployed and, implicitly or explicitly, where they are to be deployed, not only will deployment be easier, but a more natural organization of your files will typically result to facilitate deployment automation.

Other Deployment Issues

There are a few other issues that need to be addressed when we discuss deployment.

File Format - Unix or Windows (or Mac)

When it comes to deploying files for different targets and/or on different targets a CM tool can be invaluable. But for some reason, many tools don't deal with this issue well. Here's all that is needed:

1. When ascii source is submitted to the repository, the CM tool should allow any of the native formats to be used and then should store the source file in a canonical form, possibly with no line end indicators at all (e.g. store the size of the line instead). If this is not done, then the ascii file is really being treated as a "binary" file without binary characters. This is fine in some applications (e.g. Windows-only applications when the CM tool is also on Windows).

2. When binary source is submitted to the repository, the CM tool should leave it alone (possibly compressing it, or even delta-compressing it, but always so that it can be retrieved identically).

3. When ascii source is retrieved from the repository, the CM tool must provide the following options:
a) If the retrieval command/action indicates a preferred format for retrieval, use that format
b) Otherwise, if the file class of the object being retrieved indicates a preferred format, retrieve it in that format
c) Otherwise, retrieve it into the format of the native machine

If the CM tool provides these options, and the associated mechanisms for providing them (e.g. file class definitions), the end-user will be happy.

Shared Files and their deployment

Files are often shared in the source tree in multiple locations. Perhaps there are Enterprise, Professional and Home configurations of the product which share files for common features. Or maybe two different deliverables are built using the same database engine. The handling of shared files by the CM tool, and especially with respect to deployment is a key issue.

When there are no shared files, the object itself may be used to indicate the location of the deployment. When a