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 period, for example: root.department1.project1.nightly. This is called configuration hierarchy name. Further, to refer to a configuration at particular QuickBuild server, we use the format <configuration hierarchy name>@<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 always associated with its version. It is generated by running a configuration. When the particular configuration is triggered (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, the configuration will run, and a new build will be generated. The information about the particular build can be accessed online, including published artifacts, build logs, revision logs, etc.

Repository is a place that stores files needed to generates builds. It provides information about "what to build" for given configuration. It includes the version 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 plain file folder, instead of a version control system). Generally, any place able to store build artifacts (either source code, or other build artifacts such as libraries, which may be used in a build process), can be treated as a repository. Repository configuaration follows the inherit and override rule, which means that repositories defined in descendant configurations with the same name will override those defined in ancestor configuration.

Builder defines how to perform a build. After necessary files have been checked out from configured repositories, QuickBuild calls related builders to actually run the build. Currently Ant builder, NAnt builder, Maven builder and a command line builder are supported. However, any builder facilities with a command line interface should be able to work with QuickBuild. Builder configuaration follows the inherit and override rule.

Notifier defines how to notify users about the most recent build. Notification message can be customized by using Velocity templates. Currently QuickBuild supports Email notifier, Jabber notifier, MSN Messenger notifier, and Google Talk notifier. Thanks to the inherit and override rule, you can define notifiers in high level configuration, and reuse them in descendants to minimize your configuration work.

In order to make the build process more flexible, the step concept is introduced in QuickBuild. It defines the build process for a particular configuration, and you can control which parts of the build process can be executed simultaneously, and which parts should be executed serially. The step configuration follows the inherit and override rule.

Login mapping is used to map repository logins to QuickBuild users in order to perform certain actions such as sending out build failure notifications to the users who has checked in code into repository recently, etc. You can define multiple login mappings, and associate different login mappings with different repositories. This is very useful, when you have multiple repositories and login name for the particular user is not consistent throughout these repositories. The login mapping configuration follows the override and inherit rule.

Schedule defines "when to build" aspect of the configuration. By defining a schedule, builds can be triggered at specified time, or they can be triggered periodically.

Triggering of a configuration is called a triggering instance. Triggering instance will be placed into the build queue if all working threads for that queue are busy. Execution of a triggering instance does not necessarily generates a new build. The decision to generate or not to generate the build is determined by the build necessary condition. However, if you set value of the build necessary condition as true (by choosing force build from the build necessary condition drop down menu), a new build will always be generated when this triggering instance is executed.

Every configuration is associated with a build queue (if not set explicitly, parent configuration build queue will be used), which is used to control the maximum number of the concurrent builds in this configuration (and its descendants if inherited). When a configuration is triggered, some of the triggering instances will be queued if all configured working threads in the queue are busy.

Build promotion is a process of generating build based on information of another build. Build promotion is done by choosing an existing build, and promote it to another configuration (may be on another machine) by clicking on the promote button. The build selected for promotion is called source build, and the newly generated build is called promoted build.

Every configuration has working directory, which is used to hold configuration logs, checkout directory, and child configuration working directories. Let's assume that you have installed QuickBuild under /opt/quickbuild, the default working directory for the configuration root.department1.project1.nightly will be /opt/quickbuild/working/root/department1/project1/nightly. If you have changed working directory setting for the particular parent , working directories of the child configurations will be derived in the same way starting from that directory.

Configuration checkout directory is located in a sub directory called checkouts under configuration working directory. It is used to hold checked out artifacts from the various repositories.

Every configuration has publish directory, which is used to hold finished builds and child configurations publish directories. Let's assume that you have installed QuickBuild under /opt/quickbuild, the default publish directory for configuration root.department1.project1.nightly will be /opt/quickbuild/publish/root/department1/project1/nightly. If you have changed publish directory setting for a particular parent , publish directories of the child configurations will be derived in the same way starting from that directory.

Build publish directory is used to hold artifacts directory, various logs and reports generated by a build. It is named by version number of the build, and it is located under builds sub directory under configuration publish directory. Continuing with the example in the last section, if the build project1-3.0.0 is produced by configuration root.department1.project1.nightly, its publish directory will be /opt/quickbuild/publish/root/department1/project1/nightly/builds/project1-3.0.0.

Build artifacts directory is used to hold published artifacts for the particular build, and it is located under a sub directory called artifacts in the build publish directory.

Build JUNIT html report directory is used to hold JUNIT html reports generated by the particular build, and it is located under a sub directory called junitHtmlReports in the build publish directory.

Build Clover html report directory is used to hold Clover html reports generated by the particular build, and it is located under a sub directory called cloverHtmlReports in the build publish directory.