CDS (Continuous Delivery Service) Documentation

CDS (Continuous Delivery Service) is composed of several key components that handle different aspects of the CI/CD lifecycle:

• cdsctl: The command line interface used for scripting and interacting with the platform. It includes features like cdsctl shell for browsing projects and workflows via the terminal.
• Hatchery: A service responsible for spawning and killing workers based on the current build queue requirements.
• CDS Worker: The execution unit for Jobs. A pipeline consists of stages containing jobs, and each job is executed by a worker binary available from a CDS Job.
• Engine: The core component of the CDS platform.
• CDN: A service dedicated to the reception and retrieval of logs.

A workflow template allows you to create or manage multiple workflows using a single, generic definition. Templates are versioned and contain workflows, pipelines, applications, and environments in YAML format.

Each YAML file in a template is evaluated as a Golang template using [[ and ]] delimiters, enabling the use of loops and conditional logic.

By linking a repository to your CDS project, you can manage several core entities using a 'Configuration as Code' approach. This allows you to version control and automate the lifecycle of the following entities:

• Workflows: The definition of your CI/CD pipelines.
• Actions: Reusable steps or logic used within workflows.
• Worker Models: Definitions of the execution environments for your tasks.
• Workflow Templates: Pre-defined workflow structures that can be reused across different projects.

CDS uses a hierarchical structure for CI/CD automation:

• Workflows: The highest level of abstraction. A Workflow allows you to chain multiple pipelines together using triggers, joins, or forks. You can manage entire microservice stacks by defining workflows that reuse the same pipelines for different applications or environments.
• Pipelines: A sequence of stages that contain one or more concurrent jobs. A pipeline is typically started with a context consisting of an application and an environment.
• Jobs: The individual units of execution within a pipeline stage.

When the Kubernetes integration is configured by a CDS administrator, end-users gain the following capabilities:

• Use Worker Models of type Docker.
• Use Service Prerequisites on CDS Jobs.

The cds-contrib repository contains ready-to-use extensions for the CDS platform. These extensions allow you to extend the core functionality of CDS through several mechanisms:

• Actions & Plugins: Custom logic or integrations.
• Worker Models: Specialized execution environments for tasks.
• Workflow Templates: Pre-defined workflow structures.
• µServices: Microservices that integrate with the platform.

A pipeline in CDS defines the execution order required to achieve a result. Pipelines are scoped to a single project and can be used by multiple applications within that project.

Key structural components:

• Stages: A sequence of execution steps. Stages are executed sequentially; a stage only runs if the previous stage was successful.
• Jobs: Contained within stages, jobs are the actual units of work. Multiple jobs within a single stage run in parallel.
• Parametrization: Pipelines can be parametrized to allow reuse across similar workloads (e.g., using the same pipeline for both pre-production and production environments).
• Trigger Conditions: You can define conditions on a stage to enable or disable it based on specific criteria, such as the Git branch (e.g., running a Packaging stage only on master or develop branches).

CDS is composed of two primary binaries available via CDS Releases:

• worker: The binary used to execute a CDS Job.
• engine: The binary used to run all CDS µServices (microservices).