A Build is defined as the process of compiling and executing any needed activity that makes up the process of creating your run-time Application. This will usually be driven by what development language/environment/platform you use.
A Deployment is the task of packaging up and copying your run-time application to an environment in which the SCM stakeholders and ultimately the customer can access and run the application. We will continue to use the Multiple State Development design pattern, but now we are going to superimpose two execution/hardware topologies that will highlight two Build and Deployment strategies.
Standalone PC Application Build and Deployment
This first topology deals with the Build and Deploy of a Standalone PC Application. This topology is usually seen with smaller applications that do not require enterprise-wide system resources.
For most SCM systems the Build process executes outside the SCM system itself. An analogy might be that the SCM system is a filing cabinet and you have to take things out of the filing cabinet before you can work on them. To start a Build you first need to perform a mass "Check Out" of all the needed CIs from the SCM system to a designated server (usually the one that the SCM system runs on but in some situations it could be a remote server).
Once checked, out the process of compilation executes outside the domain of the SCM system. This is indicated in Figure 12 by adding the term "staging" to the States and showing the Runtime icons (triangles for incremental builds, octagons for complete builds) outside the State boxes. This first step, mass check- out, is usually accomplished by a command line interface of the SCM system with scripts to control the Build and Deploy. This Standalone PC Application environment uses a shared run-time server that is partitioned with the target SCM environments. This implementation is targeted towards a single server so you don't have to transfer the CIs to multiple locations during the State deploy stage.
For this implementation we might see compilable configuration items (CIs) such as: For this implementation we might see compilable CIs such as:
- Visual Basic source
- C source
- C++ source
Other CIs that may exist but are not compiled (but may be required to perform a compilation). They could include:
- .Net components
- C Header files
- Make 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.
In the Development area we have two sets of build environments: the build environment that is present in the developers' IDE and the build environment in the Development State itself. These builds are usually defined and executed by individual developers on an as-needed basis. They may contain variations in how the Build is executed due to a lack of a complete infrastructure with components such as Databases, as well as other developers' code.
The Integration through Production States must use a standardized Build process that will be executed by a Manager. A manager makes the decision when a compile is needed based on input from a CCB or other stakeholders. A standardized build process is a key component of maintaining the consistency and quality of the Application as CIs move through the States.
Once the Application has been Built, you have two sets of CIs to deal with - the source code and other CIs in the SCM system, and the Runtime CIs on the SCM Server. The source CIs are the elements that you are going to keep and maintain in your SCM system. From this perspective the SCM system functions as a repository for the Application. You can always create the Application's run time version from these CIs. The run-time CIs (which are the output of the Build process) are more transient since you can create them whenever you want using the standard Build process.
Deployment is the process of taking your run-time Application and moving it to an environment where it will be executed and Stakeholders can access it. In this Stand Alone PC Application it may be as simple as copying the run time CIs to a run-time Server. Once your Build and Deployment is complete it is important to do some cleanup. You do not want the run-time code generated by the Build process to hang around the SCM server, so they should be deleted. If they are not deleted it might cause errors the next time you execute a Build. If there are intermediary deployment files on the target run-time server you will want to delete those as well. Your Build and Deploy script should execute these actions.
In the development area we have two sets of build environments: the build environment that is present in the developers' IDE and the build environment in the Development State itself. These builds are usually defined and executed by individual developers on an as-needed basis. They may contain variations in how the Build is executed due to a lack of a complete infrastructure with components such as Databases, as well as other developers' code.
The Integration through Production States must use a standardized Build process that will be executed by aManager. A manager makes the decision when a compile is needed based on input from a CCB or other stakeholders. A standardized build process is a key component of maintaining the consistency and quality of the Application as CIs move through the States. Once the Application has been Built, you have two sets of CIs to deal with - the source code and other CIs in the SCM system, and the Runtime CIs on the SCM Server.
The source CIs are the elements that you are going to keep and maintain in your SCM system. From this perspective the SCM system functions as a repository for the Application. You can always create the Application's run time version from these CIs. The run-time CIs (which are the output of the Build process) are more transient since you can create them whenever you want using the standard Build process.
Deployment is the process of taking your run-time Application and moving it to an environment where it will be executed and Stakeholders can access it. In this Stand Alone PC Application it may be as simple as copying the run time CIs to a run-time Server.
Once your Build and Deployment is complete it is important to do some cleanup. You do not want the run-time code generated by the Build process to hang around the SCM server, so they should be deleted. If they are not deleted it might cause errors the next time you execute a Build. If there are intermediary deployment files on the target run-time server you will want to delete those as well. Your Build and Deploy script should execute these actions.
Once all the CIs that comprise the Application have been promoted to the Production State they need one final deployment to the Production Targets. Two types of packages are required are required to accomplish this:
- Create an install package such as a MCI that contains all the run-time components for the Application and how to install them and electronically push the Application 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 variables (State to pull CIs from for the build and the target directory where the build will take place). A build/deployment tool must also be present. It must be able to invoke the mass check-out function as well as control the manipulation of CIs, execution of the compile, bundling up of CIs, deployment of CIs, cleanup of any CIs that are left over from the compile and logging of all these activities. This set of functions represents some of the more advanced features of SCM and Build Management tools available today.
Read Part 1 at SCM Design Patterns: Paper Forms
Read Part 2 at SCM Design Patterns: Version Control & Multiple States
Read Part 4 at SCM Design Patterns: Parallel Development and Content Management
About the Author
Jim Johnston has worked in the IT industry for over 20 years. He has held multiple positions including CAD/CAM programming, applications integration coordinator, manager of a application launch center for testing and integration verification of PC applications, and testing architect for major web systems. Jim has been involved with SCM for over 6 years primarily in the areas of enterprise web applications, retail web sites, SCM process development and J2EE build and deployment methodologies.
