Jobs are the outermost and coarsest entities. A typical job is to perform and reporting all tests of a project. Another job, in the sense of true continuous integration, might be the deployment of an application or service. Jobs can depend on each other. In the case of tests and deployment it is for example desirable to prevent deployment unless all tests have passed. Further, Cider-CI provides full automation via events.

A job consist of tasks. Every job has at least one task. Typically, a deployment will have exactly one task. Also typically, a test will consist of many tasks. A certain feature to be tested is a good candidate for a task for example. Tasks are independent from each other. Therefore, tasks can be run in parallel and even be retried. These properties provide efficiency and resilience which are hallmarks of Cider-CI. A task is conceptually a blueprint for a trial. Much in the same way as in many programming languages a class is the blueprint for it's instances.

A task contains of one or many scripts. Scripts are the actual entities of execution. A unit test might be modelled with just a single and rather trivial script. More complex scenarios, e.g. integration tests, benefit highly from the possibility to run multiple scripts. Further, the scripts executing in the context of a trial can depend on each other in several ways.

Cider-CI is highly git aware. It knows and interacts with the concepts of a branch, a commit and in particular with the git tree in many ways. As a consequence, Cider-CI requires that the source is managed with or at least convertible to git. This is a mild restriction since many legacy SCMs can be converted to git. The upside of this tight integration with git easily overweight this limitation. The gained performance, the possibility to reproduce results, track and link them to source code at any time after the run of a job stand out.

A running instance of a Cider-CI stack consists of a Cider-CI Server and any number of Cider-CI Executors.

Executors execute the scripts of a trial. They aggregate and evaluate the all scripts to a result which is the outcome of the trial. An executor in Cider-CI has much more build-in intelligence compared to similar components of many other CI systems. It can thus act more autonomously which provides resilience and flexibility on an other level.

The server builds the tasks of a job. It instantiates trials, and dispatches them to matching executors. It receives the results from the executors, aggregates, and evaluates them. The result of this process is finally reflected in the corresponding job.