You are viewing an old version (v. 27) 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 it, and when to build it, etc. Configurations are organized in a tree 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, 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 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 the particular configuration is about to be executed (either by user or by the scheduling system), the build necessary condition of the configuration is evaluated. If the result of the evaluation is true, a new build will be generated and started.
QuickBuild 2.0 introduces concept of proof build to build and test your uncommited changes at server side. With proof build, the risk of polluting SCM with bad code will be reduced to the 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 the merging result of SCM trunk and uncommited changes collected from working spaces 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 below tasks:
- Collect uncommited changes and send to server when run 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 is authorized with user agent permission can connect their user agents to the server.
Local change refers to uncommited changes collected from working spaces at user's desktop when running a proof build. It is called local from user's perspective, as they've not submitted to SCM.
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 configuration has an associated workspace directory named 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 to its sub directory based on configuration repository setting), and build script will be executed in this directory (or its sub directory based on configuration build setting) to generate build artifacts, etc.
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.
Repository is the place, where the files used to generate builds are stored. It includes various source code 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 local 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 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 is may be used to call other steps sequentially or in parallel. It can recursively contain other composite steps and which can be overridden in descendant configurations.
Master step acts as the entry point when build runs and 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 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, for an 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 usual 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, and 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.
To achieve flexibility, QuickBuild introduces the concept of dynamic string. Dynamic string is a string containing [expressions], which will be evaluated and insert into the original place when the string is used. The expression should be enclosed by ${...}, and multiple expressions can be inserted in the string. For example, the next build version property of a configuration can use a dynamic string to make the build version flexible like below:
foobar-${var["major"]}.${var["minor"]}_${var["revision"]}
This string contains three dynamic parts, respectively ${var["major"]}, ${var["minor"]} and ${var["revision"]}. When the build version is used, all expressions inside the dynamic parts will be evaluated and the evaluation result will replace corresponding dynamic part. Assuming the configuration has below variable values at the time of using the build version:
major=1 minor=5 revision=12
The build version will be foobar-1.5_12 when it is used.