The Agent, one per project, is a customer-implemented application operating as the ApartCI's representative inside the customer's development environment.


This is generally the name of ApartCI the non-blocking continuous integration product / system / method.
It is typically used to also represent the brain of the system - the cloud-based application driving the system's functionality.

ApartCI Integration Method

The patent-pending integration method on which the ApartCI system is based on.

ApartCI System

The system behind the ApartCI product implementation.

Baseline Label/Quality Level

The result matrix associated with each of the ApartCI-applied labels represents the project's baseline quality level at the moment when the respective label was applied.
The initial quality level is established by actually measuring it when the project is activated - by applying the initial label and performing the pre-commit QA verification on it.
Subsequent labels, applied after each primary bundle commit, get their baseline quality levels from the results of the respective primary bundles' verifications, which are checked to be as good as (or better than) the results of the previous primary bundle QA verification.


A "branch" represents the complete set of branches in all the project's VCS repositories and repository sets.


A bundle is a collection of one or multiple non-overlapping changesets grouped together to act as a single super-changeset for QA verification purposes.

Child Bundle

Exactly 2 child bundles are created during a split of a parent bundle.

Parent Bundle

A bundle subjected to a bundle split operation becomes a parent bundle and has exactly 2 child bundles.

Peer/Sibling Bundle

The 2 child bundles resulted from a bundle split operation are siblings to each-other.

Primary Bundle

Primary bundles are large low risk bundles, always processed sequentially in the pre-commit stage

in order to catch any conflicting changesets that might have eluded capture so far due to parallel QA verifications of the regular bundles, thus ensuring no regression can slip through.

Bundle Split

A bundle split occurs when a regression is detected in the QA verification of a bundle containing more than one changeset.

Bundle Status

The bundle status is a string value reflecting the bundle's status in the particular stage in the system's processing pipeline where it was created.
It changes automatically as the processing progresses and may occasionally be reset if/when processing restarts from scratch or repeats some processing step for whatever reason.
Eventually it reaches a final state which is no longer changed automatically.

Possible values:


A changeset represents the complete set of software changes submitted by a developer for integration into the project branch and metadata associated with it.
The changeset is stored by the Agent in the developer environment as a opaque blob and only the necessary metadata including a blob identifier is passed to the ApartCI application.

Conflicting Changesets

Conflicting changesets are changesets which do not cause regressions by themselves, but do so when they are present together in the same bundle and interfere with each-other.

Faulty Changeset

A faulty changeset is a changeset which causes regressions by itself, regardless of being alone or together with other changesets in a bundle.

Low Risk Changeset/Bundle

A low risk changeset is a changeset from a regular bundle which passed the pre-commit QA verification.
A low risk bundle is a bundle containing only low risk changesets. Low risk bundles and changesets exist only in the pre-commit stage.

Regular Changeset/Bundle

A regular changeset is a changeset which wasn't yet verified to be a low_risk one. A regular bundle is a bundle containing only regular changesets. Multiple regular bundles can be processed in parallel for scalability, in the pre-commit and the preliminary stages. All faulty changesets are caught in these stages. But it's possible that some conflicting changesets are not detected in regular bundle verifications - they will be caught in the primary bundle verifications.

Changeset Status

The Changeset status is a string value reflecting the changeset's status in the system. It is reset every time the changeset enters a particular stage in the system's processing pipeline and is changed automatically as the processing progresses. Eventually it reaches a final state which is no longer changed automatically.

Possible values:

Changeset Cancelled

A changeset can be cancelled for several reasons, which include:

Changeset Rejected

A changeset can be rejected for several reasons, which include:


A Job is a basic unit of work that ApartCI prepares for the Agent to execute in the development environment as needed by the system's operation.
The Agent periodically requests new jobs from ApartCI and notifies ApartCI of any status changes in the jobs previously requested and received.
ApartCI replies to Agent requests for jobs with any new jobs that need to be executed and reacts to the job status updates from the Agent as needed to complete the system's operation.


A "label" represents a specific version of the project's VCS branch. Depending on the VCS configuration labels can be physically applies to one, some or all of the project's VCS repositories and/or repository sets. Applying the label is executed by the Agent when requested by ApartCI via a labelling job. An initial label is applied when the project is activated and a new label is applied after every primary bundle commit.

Non-blocking Continuous Integration

A particular type of Continuous Integration (CI) which actively prevents blockages caused by regressions in quality of the software being integrated, as opposed to just monitoring for and reacting to their occurrences, as traditional CI systems do. A comparison between these types of CI systems is done here

Processing Pipeline

The processing pipeline represents the summary view of the end to end ApartCI system, containing one or more processing stages:

The changesets submitted by developers enter the pipeline at the ingress stage. Each preliminary or pre-commit stage performs its QA verifications on the changesets in that stage, rejecting the ones causing regressions and promoting the successfully verified ones into the next stage, if any. Changesets successfully verified in the pre-commit stage are being committed.

Processing Pipeline Capacity

The processing pipeline capacity represents the maximum number of changesets that can be simultaneously active in the pipeline. To be considered active a changeset must have been at least once selected in a bundle and must have not yet reached a final state.

The maximum capacity of a project's pipeline is dictated by the project's ApartCI license tier and the current pipeline usage of all projects sharing that license.


An ApartCI project is the representation in the ApartCI system of the software development project using the ApartCI integration method on a particular VCS system integration branch.

Quality Assurance (QA) Verification (Flow)

A set of quality verification steps of various types configured to form an arbitrarily complex verification flow that is used for qualifying the project's code base.
Each stage has a QA verification, with its own configuration.

Quality Assurance (QA) Artifact

A QA artifact is an artifact that is produced in one QA verification step and that can be used in a subsequent QA verification step from the same QA verification flow.

Quality Assurance (QA) Resource

A QA resource is an identifiable resource on which a QA verification step can be executed, for example a testbed, a build server, etc. QA resources serving the same kind of QA steps can be groups in resource pools, dedicated or shared.

Quality Assurance (QA) Run

A QA run is one execution of a QA verification. If the QA run is executed in the context of a bundle and does not pass cleanly, a baseline comparison is performed - checking every unsuccessful result against the same result in the baseline result matrix to determine if it really is a regression. Only if a regression is detected the overall result is considered to be failed.

Quality Assurance (QA) Step

A standalone unit of a QA verification flow that can be executed independently on an identifiable QA resource. Each QA step has its own configuration.

QA steps may be further split internally in sub-steps that can be mapped and executed as individual jobs.

Quality Assurance (QA) Step Run

A QA step run is an execution of QA verification step on a particular QA resource.


A regressions is declared if the result matrix of a bundle QA verification includes at least one which is worse than the baseline quality level.
If the bundle contains more than one changeset a bundle split is automatically performed in order to identify the culprit. If the bundle contains only one changeset that changeset is automatically rejected.


An extended period of operation of an ApartCI project's configuration can be simulated in just minutes. A separate project is created for simulation purposes, using a copy of the selected configuration.
The simulation uses a specially designed Agent emulating the actions of a real project Agent, except with a compressed timing. This way the same ApartCI application code used with real projects can used for simulation with practically no functional modifications. A simulation feed is used to generate in a pseudo-random manner changesets that the special Agent will submit (as real developers do in production) and the relative timing between their submission. The pseudo-randomness is based on seeds unique to each simulation feed in order to obtain changeset submission patterns reproducible across multiple simulations.

Simulations can be used for a variety of purposes, including: academic, evaluating project configurations prior to deployment or for project performance tuning, cost reduction, capacity planning, etc.


A stage in the processing pipeline is responsible for performing the corresponding QA verification on the changesets it receives.

Pre-commit Verification Stage

This stage is the last processing pipeline stage in which changesets can be rejected. This is where the primary bundles containing low risk changeset are sequentially subjected to the most complex QA verification, which defines the integration branch's quality level baseline.

Preliminary Verification Stage

Preliminary stages have QA verifications with gradually increasing complexity but which are always subsets of the QA verifications from the pre-commit stage.
Their role is to catch as many faulty changesets as possible as early as possible, using QA resources which are cheaper and/or have higher capacity than those in the pre-commit stage. For example a preliminary stage could just build an image, while the pre-commit stage would build the same image but also run it through expensive tests - this could potentially save many testbed hours compared to a project configuration without the preliminary stage.

Post-commit Verification Stage

The post-commit stage QA verification is applied only to the labels applied after each primary bundle commit, in a manner similar to the traditional CI systems - monitoring only. In fact its job could be simply to trigger an execution in an already functional such CI system.

The reasons for having such stage is to still monitor results for QA verifications not fit to be inserted in the pre-commit stage:

Version Control System (VCS)

The Version Control System of an ApartCI project represents the complete set of the project's repositories. In order to accommodate projects with a wide variety of VCS infrastructure ApartCI uses VCS repository sets and VCS repositories.

A top level project VCS repository set serves as container for all other VCS repository sets and repositories. This allows support for virtually any combination of flat and/or nested VCS repository structure.

Version Control System (VCS) Repository

An ApartCI VCS repository is a representation of a customer VCS system which is operated using a single VCS configuration and tool set - regardless if that hides underneath a collection of multiple other real VCS systems.

Version Control System (VCS) Repository Set

An ApartCI VCS repository set is a collection which may include: