Concepts

Version 34 by Robin Shen
on Jun 27, 2009 00:27.

<< Changes from 33 to 34
compared with
Current by Robin Shen
on Jul 27, 2009 18:56.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 2 changes. View first change.

 {anchor:SCM} *SCM*
 SCM refers to _Source Code Management_ system, Example of SCM systems are _Cvs_, _Subversion_, _Visual Sourcesafe_, _ClearCase_, _Perforce_, and _Starteam_
  {panel:title=Concepts|borderStyle=solid|borderColor=#AAAAAA|titleBGColor=#CCCCCC|bgColor=#ffffff}
  
 {anchor:configuration} *Configuration*
  
 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.
  
 {anchor:build} *Build*
  
 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.
  
 {anchor:repository} *Repository*
  
 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.
  
 {anchor:quickbuild repository} *QuickBuild Repository*
  
 QuickBuild repository is a special repository which holds published artifacts of a build.
  
 {anchor:step} *Step*
  
 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.
  
 {anchor:composite step} *Composite Step*
  
 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.
  
 {anchor:master step} *Master Step*
  
 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.
  
 {anchor:build grid} *Build Grid*
  
 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.
  
 {anchor:build server} *Build Server (or Server Node)*
  
 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.
  
 {anchor:build agent} *Build Agent (or Agent Node)*
  
 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
  
 {anchor:build node} *Build Node (or Grid Node)*
  
 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.
  
 {anchor:proof build} *Proof Build*
  
 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).
  
 {anchor:user agent} *User Agent*
  
 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.
  
 {anchor:local change} *Local Change*
  
 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.
  
 {anchor:configuration workspace} *Configuration Workspace*
  
 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.
  
 {anchor:configuration directory} *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.
  
 {anchor:build directory} *Build Directory*
  
 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.
  {children:all=true}
 {panel}