📄️ SCM
SCM refers to Source Code Management system, Example of SCM systems are CVS , Subversion , Visual Sourcesafe , ClearCase , Perforce , and Starteam.
📄️ 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.
📄️ Configuration Hierarchy
For a particular configuration, the configuration hierarchy refers to the configuration and all its parent configurations (direct and non-direct).
📄️ Configuration Subtree
For a particular configuration, the configuration subtree refers to current configuration and all its child configurations (direct and non-direct).
📄️ 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.
📄️ Build Pipeline
Build pipeline is a set of builds connected with promotions, visualizing different stages in a build or deployment process with commit information displayed on each stage. Defined promotion actions can be taken directly on the pipeline to push commits going through different stages.
📄️ 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.
📄️ 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.
📄️ 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.
📄️ 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.
📄️ 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.
📄️ Step Path
Step path can be used to reference an executed step. Since QuickBuild 3.0, the same step can be reused in a single build, therefore it is not sufficient to reference an executed step simply with a step name. Path of a particular step instance can be constructed by concatenating names of all its container steps with character "\>", from outer-most to inner-most, with the last element being name of the step itself. Below screen explains how to construct step path of various steps:
📄️ Build Grid
QuickBuild 2.0 introduces the concept of a build grid to serve purposes including but not limited to:
📄️ 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
Build agents connect to build server to form a build grid. Since a grid node (server node and agent node) can only run one build at a time, multiple build agents means the ability to run multiple builds concurrently, which is important to a busy build system. It also make multi-platform build/test possible as a build can distribute different steps to different agents for execution. Build agent can be upgraded automatically when the build server upgrades to a new version.
📄️ User Agent
User agent is installed on user's desktop and is mainly used for the purpose of Proof Build. It responsible for collecting uncommitted changes from user's desktop and send to build grid for verification. It can be upgraded automatically when server upgrades to a new version.
📄️ Grid Node
Grid node represents a member of the build grid, it is either a build server, a build agent or a user agent. It is identified by the node address in the form of \:\ , where \ represents the host name of the machine running the build node instance, and \ represents the port number the build node instance uses.
📄️ Resource
Resource means any physical or virtual component of limited availability within the grid, and is provided by grid nodes. A build step can declare to require certain resources to run. If some nodes are found with desired resources, the step will run on the fastest node; otherwise, the step will wait until a node with free resource is available. This way, the resource contention problem between builds and steps can be solved efficiently.
📄️ Cloud Profile
Cloud profile exists to support launch build agent on demand in cloud environment. It defines how to launch build agents as well as describing characteristics of the build agents. Build agents launched by the same cloud profile will have same characteristics. Often you need to define multiple cloud profiles to satisfy different build requirements.
📄️ 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.
📄️ Build Promotion
Build promotion is a process of generating new build based on information or artifacts of another build. It is used by QuickBuild to implement build life cycle management. For example, a gold QA build can be promoted as a release build. Arbitrary custom actions can be configured for the promotion process so that you can deploy the build to test servers, create tags on SCMs for release builds, or send notifications to interesting parts.
📄️ 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. For distributed version control systems, local change refers to local commits which will be pushed to a central repository.
📄️ 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. In a grid environment, each node has a separate workspace for each configuration. By default, workspace for a particular configuration on a particular node points to the directory named by configuration path under QuickBuild's installation directory on that node.
📄️ Storage Directory
Storage directory is a place on build server or agent to store below contents:
📄️ Configuration Publish Directory
Configuration publish directory is a place on build server to hold published materials of the configuration such as various statistics reports. Each configuration will create its own publish directory named by configuration id under the configurations sub directory of storage directory.
📄️ Build Publish Directory
Build publish directory is a place on build server to hold published materials of the build such as build artifacts and various build reports. Each build will create its own publish directory named by build id under the builds sub directory of storage directory.