- to PCs on a network that the end users have access to.
- Create an install package such as a MCI that contains all the run-time components for the Application and how to install them and then create media (CDs, DVDs) that can be distributed to end users.
The process of creating the install packages is usually accomplished with a language/platform specific tool and is only executed by a manager at appropriate times relative to a release schedule.
Multiple-Tier Web Build and Deployment
This second topology deals with the Build and Deployment of a Multi-Tier Web Application. This topology is usually seen with larger scale enterprise Web Applications that use a J2EE framework where you have different servers performing different run-time tasks (i.e. Application Server, Web Server, Database Server).
The previous discussion of Build and Deploy concepts are the same for this version of the Build and Deploy with a few exceptions.
A Build will use compilable CIs such as:
- Java source
- Enterprise Java Beans
Other CIs that may exist but are not compiled (but may be required to perform a compilation). They could include:
- Struts components
- Java Server Pages
- XML files
- gif, jpeg, or other graphic entities
These CI types should be segregated by directory structures so that a build process can distinguish between them.
The deployment targets for this version of the Build and Deployment Design Pattern are remote servers that may be in a different geographical location like a secure data processing center. The deploy step involves deploying CIs to these multiple servers that are segregated by function. This means that a deploy script will be more complex as it will have to copy the run-time Application CIs to a different location and different servers.
To accomplish this you must first bundle up the Build using utilities such as JAR and/or TAR. Then, using transport utilities such as the File Transfer Protocol (FTP) you export the Application to the target run-time servers. Once the bundled files reach the run-time servers they must be expanded back to their original state and deployed to locations (Web Servers, Application Servers) usually defined in files called deployment descriptors.
Deployment scripts must also be aware of which target servers the Build is destined for (Development - Production). There can be different configurations/numbers of servers in a target environment. This is most commonly seen in the Production State where there may be a need for additional capacity and redundant servers for failover capabilities not seen in the lower States. The lower States (Development - UAT) are used by a much smaller group of development/testing users so they do not require the same "Production Hardening" that the Production environment must support.
All servers involved in the update are usually recycled (re-booted) so that you are sure that the changes made are reflected in the run-time Application environment. This is true of all the Sates except Development where the builds are ad-hoc. Database changes are usually deployed with special tools unique to the database product.
The production targets for this version of the Build and Deploy Design Pattern is the Web, and if necessary, media (CDs, DVDs) to install on other remote servers. If the final form of the Application is media you may need to develop an installation script that will load the software onto your target platform.
In this Design Pattern it is important that a SCM tool provide a robust command-line interface (some times known as an application program interface - API) to control functions of the SCM tool programmatically. The primary functions necessary here are the mass checkout and the passing of