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.
The patent-pending integration method on which the ApartCI system is based on.
The system behind the ApartCI product implementation.
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.
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.
- queued - waiting for processing
- qa_running - started processing, the QA run's status has more info
- qa_passed - final state for successfully verified bundles
- qa_failed - final state for bundles if regressions were detected
- committing - transient state while the bundle's changesets are being committed
- committed - final state for successfully processed bundles
- cancelled - final state for cancelled bundles, a cancellation reason is present
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.
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.
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.
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.
- submitted - transient state during submission until fed into the processing pipeline
- queued - waiting for processing in a pipeline stage
- bundled - started processing, the bundle's status has more info
- committing - transient state while the changeset is being committed
- committed - final state for successfully processed changesets
- rejected - final state for rejected changesets, a rejection reason is present
- cancelled - final state for cancelled changesets, a cancellation reason is present
A changeset can be cancelled for several reasons, which include:
- a cancellation was requested by the submitter
- a cancellation was requested by one of the project's admins
- a cancellation was requested by one of the project's team members and approved by the project's admin
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.
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
- the pre-commit stage, one per pipeline, mandatory
- preliminary stage(s), optional, placed in front of the pre-commit stage
- the post-commit stage, one per pipeline, optional, behind the pre-commit stage
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.
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.
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.
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.
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.
QA steps may be further split internally in sub-steps that can be mapped and executed as individual jobs.
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.
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 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.
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:
- too expensive
- without sufficient capacity
- not stable/mature enough
- in testing prior to introduction into the pre-commit stage
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.
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.
An ApartCI VCS repository set is a collection which may include:
- a single or multiple VCS repositories
- a single or multiple other VCS repository sets