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