You are viewing an old version (v. 13) of this page.
<< View previous version | view page history | view next version >>
Configuration holds all configuration information needed to generate builds. This information includes what to build, how to build it, and when to build it, etc. Configurations are organized in a tree structure. To refer to a configuration, name of all its ancestor configurations should be chained together and connected with forward slash, for example: root/department1/project1/nightly. This is called configuration path. Further, to refer to a configuration at particular QuickBuild server, we use 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 settings. This behavior is referred as inherit and override rule, which makes build management of many projects quite easy.
Build is generated by running a configuration. When the particular configuration is requested to run (either by user or by scheduling system), the build necessary condition of the configuration will be evaluated. If the result of the evaluation is true, a new build will be generated.
Every configuration has an associated configuration directory which is named by the configuration identifier, and resides under the configurations directory. This directory holds configuration log, various statistics information about the configuration, and the configuration workspace.
Every configuration has an associated workspace directory which is named by workspace and resides under the configuration directory. The workspace is the place where the build for the associated configuration actually happens, for example, source code will be checked out to this directory (or its sub directory based on configuration repository setting), and build script will be called from this directory (or its sub directory based on configuration build setting) to generate build artifacts, etc.
Every build has an associated build directory which is named by the build identifier, and resides under the builds directory. This directory holds build log, build artifacts, and various build reports.
Repository is a place where files used to generate builds are stored. It includes various source coee control systems such as CVS, ClearCase, Subversion, etc. Ordinary directories can also be treated as a repository (in case you store your source code in a file system folder, instead of a version control system). 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 uses steps to control how a build should be performed. Multiple steps can be chained sequentially or parallely to define the build process of a configuration, and they can be configured to run on different build nodes (refer to Build Node definition below) to achieve 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 is designed to call other steps sequentially or parallely. It can recursively contains other composite steps and they can be overrided in descendent configurations as well.
Master step acts as the entry point when build runs and is always named as master. When a build is started, it only looks for master step and execute it. The master step is generally designed to be a composite step so that other steps can be executed as desired if a build starts.
QuickBuild 2.0 introduces the concept of build grid to serve purposes including but not limited to:
- Accelerate 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 parallely 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, for a overloaded server, you should configure CPU and I/O intensive steps to run on agent nodes.
- Build, test or package multiple platform products. It is quite offen that a product contains components which need to be built or tested on different platforms. In QuickBuild, this can be easily achieved by specifying proper node match condition of corresponding steps. For example, you can specify that a step compiling linux components runs only on linux nodes with GCC 4.0 installed, or runs only on node with specified IP address or host name, while another step compile windows components runs only on Windows nodes with Visual Studio 2008 installed.
Build grid is comprised of build nodes, with one build node always being the build server, and other build nodes being build agents connecting to the build server.
Build server represents the QuickBuild instance configured to run as server role. It manages build tasks centrally, and distribute steps to connected build agents based on some rule. It is identified in the form of <server host>:<server port>, where <server host> represents host name of the machine running QuickBuild server instance, and <server port> represents port number of the build server instance.
Build agent represents the QuickBuild instance configured to run as agent role. It must connects to an existing build server to join a build grid, and can be upgraded automatically when the build server upgrades to a new version. As a member of the build grid, it executes steps sent from the build server. It is identified in the form of <agent host>:<agent port>, where <agent host> represents host name of the machine running QuickBuild agent instance, and <agent port> represents port number of the build agent instance.