Increasingly Application Deployment is a focus of the total CM picture. Why should it be? Isn't it something separate? Integration of Application Deployment with Configuration Management can both simplify the process and, in the optimal case, permit multiple simultaneous deployments without any additional effort. A goal here might be to allow different users to see a different versions of the application. Or it might be just to automate deployment. In this article, we'll look at the two main trends in deployment - the single point network application deployment, and the more traditional deployment for either installation packaging or in-house use.
Let's start with the network application, and let's keep it simple. I have a web site and I want my competitors to see one version of it, my customers to see another version, my web developers to see another version and everyone else to see the official current version. This is a reasonable deployment example because more and more applications are being deployed as Java or similar applications. That is, the application is deployed in one place and the clients pick up the application automatically as part of their web browsing. For example, your Best Buy or Future Shop on-line shopping is accessed by thousands of clients all accessing a single deployment of the on-line shopping application at the web site. So, how do we go about this.
First of all we could have four different copies of the web site, but then if we want to make changes to common portions, we have to make it in four places instead of one. Sound more like a CM issue? So how do we proceed?
Classical CM Support For Multiple Versions of a Web Site
The classical view would be to maintain the Web site using a CM tool which is capable of sharing common code across Web development streams (i.e. branch only when necessary). Then I only have to make common changes once, and then re-deploy. And this works fairly well. The problem comes when the number of views starts to grow. Perhaps the legal department needs to see all "official" versions of the web site used in the past 2 years.
The Dynamic Web Site
The next logical improvement would be to have a dynamic web site which generates or locates pages based on a view specification. When you access the web site, the view is specified (for example, based on how you accessed it or where your client IP address is located). Based on this view, the Web Server would dish out the appropriate pages. Such a strategy requires a bit of technology, but can provide additional benefits as well.
To implement this stategy, you need a repository of Web pages which can be served up based on the view. Selecting from a number of pre-deployed pages is a solution which is not really any different from our initial classical view. This is where we really want to start integrating with the live CM tool. Based on the view setting, we should be able to access a page from the CM tool which reflects the view. To do this, we need to have the Web Server integrated with the CM tool, perhaps through CGI scripts, so that the requested page can be retrieved from the CM tool and served up to the web client. This obviously has to be a quick operation. If 100 deltas need to be applied in order to genreate the requested page, response times might not be acceptable. This is especially true if there is heavy traffic on the server, with hundreds of clients accessing pages simultaneously. Traditional RCS- and SCCS-like storage techniques likely won't cut it. As well, you have to consider how many client programs for the CM tool need to be active to provide adequate performance. If the CM tool can rapidly change views, the same CM client might be able to serve all of the Web clients. If context setting is not a rapid operation, it may be necessary to have a CM client per view - which could possibly bog down the server.
Web Sites on a CM-Supported Virtual File System
Now let's try to go one better. With