You are viewing an old version (v. 34) of this page.
<< View previous version | view page history | view next version >>
SCM
SCM refers to Source Code Management system, Example of SCM systems are Cvs, Subversion, Visual Sourcesafe, ClearCase, Perforce, and Starteam
Configuration holds all the configuration information needed to generate builds. It includes information about what to build, how to build, and when to build, etc. Configurations are organized in a hierarchical structure. To refer to a configuration, the names of all its ancestor configurations should be chained together and concatenated with forward slash, for example: root/department1/project1/nightly. This is called configuration path. To refer to a configuration on the particular QuickBuild server, QuickBuild uses the format <configuration path>@<build server>. For example: root.department1.project1.nightly@buildserver1. Child configurations can inherit build settings from its parent, and they can selectively override some of the parent settings. This behavior is referred as inherit and override rule, which simplifies the build management of multiple projects.
Build is generated by running a configuration. When a particular configuration is triggered (either by user or by the scheduling system), the build condition of the configuration is evaluated. If the result of the evaluation is true, the configuration will be run to generate a new build.
Repository is the place, where the files used to generate builds are stored. It normally refers to various SCM systems which holds source files to generate the build. Repository definition follows the inherit and override rule: repositories defined in descendant configurations with the same name will override those defined in ancestor configuration.
QuickBuild repository is a special repository which holds published artifacts of a build.
QuickBuild uses steps to control how a build should be performed. Multiple steps can be chained sequentially or in parallel to define the build process of a configuration, and they can be configured to run on different build nodes (see the Build Node definition below) to perform remote builds. Step definition follows the inherit and override rule: steps defined in descendant configurations with the same name will override those defined in ancestor configuration.
Composite step is a special step which may be used to execute other steps sequentially or in parallel. It can recursively contain other composite steps which can be overridden in descendant configurations.
Master step acts as the entry point for build execution and it is always named master. When a build is started, it looks for master step and executes it. The master step is a special instance of a composite step so other steps can be executed as desired when a build starts.
QuickBuild 2.0 introduces the concept of a build grid to serve purposes including but not limited to:
- Accelerate the build process of a single build. As described earlier (see step definition), build process is defined by steps and they can be configured to run in parallel on different grid nodes (grid node represents a build machine with QuickBuild installed) based on load balancing algorithm.
- Run build tasks on build agents to reduce load of central build server. Steps can be configured to run on server or agent, however you should configure CPU and I/O intensive steps to run on agent nodes.
- Build, test or package multiple platform products. It is not unusual that a product contains components that need to be build or tested on different platforms. In QuickBuild, this can be easily achieved by specifying proper node match condition of the corresponding steps. For example, you can specify that a step compiling Linux components runs only on Linux nodes with GCC 4.0 installed, or it runs only on a node with the specified IP address or with the specified host name, while another step compiles Windows components and runs only on Windows nodes with Visual Studio 2008 installed.
Build grid consists of build nodes, where one build node is always the build server. Other build nodes are build agents connected to the build server.
Build server represents the QuickBuild instance configured to run as a server. It is responsible for overall central management of build tasks, and it distributes steps to the connected build agents based on defined rules.
Build agent represents the QuickBuild instance configured to run as agent. It must be connected to a running build server to join a build grid, and it can be upgraded automatically when the build server upgrades to a new version. As a member of the build grid, it executes steps sent to it from the build server
Build node represents a member of the build grid, it is either a build server, or a build agent. It is identified by the node address in the form of <node host>:<node port>, where <node host> represents the host name of the machine running the build node instance, and <node port> represents the port number the build node instance uses.
QuickBuild 2.0 introduces concept of proof build to build and test your uncommitted changes at server side. With proof build, the risk of polluting SCM with bad code will be reduced to minimum as developer can submit a proof build and only commit their changes if the proof build is successful.
The source code used to generate a proof build is first checked out from trunk of the SCM, and then patched with uncommitted changes collected from project work area at user's desktop (with the help of user agent which will be mentioned later).
User agent is installed on user's desktop and will connect to QuickBuild server to accomplish following tasks:
- Collect uncommitted changes and send them to server when running a proof build
- Resolve artifact dependencies (not implemented)
- Run local build (not implemented)
User agent is not necessary for all users, and only users who have user agent permissions can connect their user agents to the server.
Local change refers to uncommitted changes collected from project work area at user's desktop when running a proof build. It is called local from user's perspective, as they've not submitted to SCM.
Each configuration has its own virtual workspace in order to hold intermediate files during the build. And this virtual workspace can be mapped to different real directory on different node. By default, for a particular configuration, its workspace is mapped to a sub directory identified by the configuration path name under the global workspace directory on server. On agents, the workspace is mapped to sub directory identified by configuration path name under directory <agent install dir>/workspace. When mentioning the workspace on node x, we acually refer to the real directory the workspace is mapped to on that node.
Configuration Publish Directory
Every configuration has an associated configuration directory which uses the name of the configuration identifier, and resides under the configurations directory. This directory holds configuration log, various statistical information about the configuration, and the configuration workspace.
Every build has an associated build directory which uses the name of the build identifier, and resides under the builds directory. This directory holds build log, build artifacts, and various build reports.