Concepts

Version 38 by Robin Shen
on Jun 27, 2009 02:27.

<< Changes from 37 to 38
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. 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. It is used by QuickBuild to checkout/update files from various SCM as part of the build process. 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. By checking out from this repository, artifacts of upstream builds (normally library projects) can be retrieved and used by downstream builds. This is how dependency handled in QuickBuild: the downstream builds depends on upstream builds and it uses QuickBuild repository to resolve the dependency.
  
 {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 normally defined as a composite step to exuecute other steps.
  
 {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:build promotion} *Build Promotion*
  
 Build promotion is a process of generating new build based on information of another build. It is used by QuickBuild to implement build life cycle. For example, a gold QA build can be identified and promoted as a Release build. Arbitrary custom actions can be configured for the promotion process so you can deploy the build to test servers, or to create tags on SCMs for release builds, and etc.
  
 {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
 # Run local build
 # Resolve artifact dependencies (not implemented)
  
 {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*
  
 Configuration workspace is the place to build your projects. It is used to hold files used during a build such as source files checked out from SCM, intermediate files generated during the build etc. The workspace maps to different directory on different node. For a particular configuration, the workspace on a particular node is mapped to the sub directory identified by path name of the configuration under directory _<QuickBuild installation directory>/workspace_. The workspace directory for a particular configuration is configurable for each node through configuration property _workspace path_.
  
 {anchor:configuration publish directory} *Configuration Publish Directory*
  
 Every configuration has a publish directory on server which is used to hold published statistics reports for the configuration. The default publish directory is a sub directory identified by configuration id under directory _<global storage directory>/configurations_. Place of this directory is configurable through configuration property _storage path_.
  
 {anchor:build publish directory} *Build Publish Directory*
  
 Every build has a publish directory on server which is used to hold published artifacts and reports for that build. The default publish directory is a sub directory identified by build id under directory _<global storage and resides under the _builds_ directory. Place of this directory is configurable through configuration property _storage path_.
  {children:all=true}
 {panel}