Agent
The Agent, one per project, is a customer-implemented application operating as the ApartCI's representative inside the customer's development environment.
ApartCI
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.
Branch
A "branch" represents the complete set of branches in all the project's VCS repositories and repository sets.
Bundle
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:
- 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
Changeset
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:
- 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
Changeset Cancelled
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
Changeset Rejected
A changeset can be rejected for several reasons, which include:
- it was identified as causing a regression
- it failed to patch properly on the current baseline label
Job
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.
Label
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 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.
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.
Project
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.
Regression
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.
Simulation
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.
Stage
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:
- too expensive
- without sufficient capacity
- not stable/mature enough
- in testing prior to introduction into 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:
- a single or multiple VCS repositories
- a single or multiple other VCS repository sets