[opensourcedex]

cds is a free, open source cloud infrastructure management project written in Go and released under BSD-3-Clause. It has 4,843 GitHub stars, 453 forks and 160 open issues, and was last pushed 13 hours ago. On this registry it ranks #44 of 70 tracked projects in Cloud Infrastructure Management, with 5 head-to-head comparisons available.

What is cds?

CDS is an open-source, enterprise-grade continuous delivery and DevOps automation platform written in Go, for teams that build, run and own their own CI/CD workflows and want to script and scale them without depending on a hosted vendor.

What it is

CDS lives in the Go ecosystem, listed under the topics automation, continuous-delivery, continuous-deployment, continuous-integration, devops, devops-workflow and golang. It is described by its maintainers as an Enterprise-Grade Continuous Delivery & DevOps Automation Platform under active development, released under the BSD-3-Clause licence, with documentation published at https://ovh.github.io/cds/. Its central concept is the CDS Workflow, which chains pipelines together with triggers. A pipeline is structured in sequential stages, each holding one or more concurrent jobs, and a workflow can link pipelines with joins or forks. Pipelines also accept a context of zero or one application and zero or one environment.

The concrete problem it solves is the pipeline-only model that most CI/CD tools use, where jobs sit inside a single pipeline and nothing chains pipelines together. CDS replaces that model with workflows built from reusable pipelines, so a single workflow builder can deploy an entire microservice stack. The same pipeline may appear several times in one workflow, which means a team with hundreds of applications maintains one build pipeline and one deployment pipeline rather than hundreds. It also replaces browser-only workflow administration: the command line allows workflows to be created and managed as code.

Key capabilities

  • CDS Workflows chain pipelines with triggers, including joins and forks, so one workflow can deploy an entire microservice stack.
  • Pipelines run multiple jobs simultaneously while keeping isolation between them, organised into sequential stages.
  • The cdsctl command line scripts everything and provides commands such as cdsctl shell to browse projects and workflows without opening a browser.
  • An intuitive UI creates and runs workflows and lets users dig into logs when needed.
  • Workflow templates share and reuse workflows across multiple teams.
  • The platform exposes a REST API and is designed around self-service, horizontal scalability, high availability, pipeline reutilisability and customisation.
  • Production activity is measured with logs, metrics and monitoring, and all data is stored in the database with nothing kept on the filesystem.

Who uses it and how

  • It has run in production since 2015 at OVH, launching more than 7M CDS workers per year.
  • Teams with hundreds of applications keep one build pipeline and one deployment pipeline and reuse them across workflows.
  • Platform teams standardise workflow definitions and distribute them to other teams through workflow templates.
  • Operators drive everything from cdsctl and workflow as code, falling back to the UI for log inspection.
  • Self-hosters treat database backup as the whole backup strategy, since every piece of state lives in the database.

Getting started

Docker-Compose is the recommended first step, through the Ready To Run tutorials linked from the documentation. Official releases are published on https://github.com/ovh/cds/releases, and the full documentation lives at https://ovh.github.io/cds/.

How it compares

The provided facts name no competing CI/CD products and no list of paid tools that CDS replaces, so on that axis it stands alone in this registry. Its only stated contrast is conceptual: where most CI/CD tools work with jobs inside a pipeline, CDS adds chained pipelines as workflows on top of them.

When to use it — and when not to

A self-hoster must operate the platform and its database, because all state is stored there and nothing sits on the filesystem, so database backup discipline is mandatory. No hosted or managed option appears in the facts, which makes CDS a poor fit for teams that want a vendor-run CI/CD service rather than software they install and maintain. The public README excerpt is thin and defers most detail to the external documentation site, and with 160 open issues the project is clearly still evolving, so evaluate the docs and current releases before committing.

project readme (upstream, from github) — read inline

CDS: Continuous Delivery Service

Go Report Card GoDoc

CDS is an Enterprise-Grade Continuous Delivery & DevOps Automation Platform written in Go(lang).

This project is under active development

Documentation

Intuitive UI

CDS provides an intuitive UI that allows you to build complex workflows, run them and dig into the logs when needed.

Create and run workflow with CDS ui.

The most powerful Command Line for a CI/CD Platform

cdsctl is the CDS Command Line - you can script everything with it, cdsctl also provides some cool commands such as cdsctl shell to browse your projects and workflows without the need to open a browser.

See all cdsctl commands

Create workflow as code with CDS command line.

Want a try?

Docker-Compose is your friend, see Ready To Run Tutorials

Blog posts and talks

FAQ

Why CDS? Discover the Origins

What is a CDS workflow?

Most of the CI/CD Tools play with jobs inside a pipeline. CDS introduces a new concept named CDS Workflows. A CDS Workflow allows you to chain pipelines with triggers. A pipeline is structured in sequential stages containing one or multiple concurrent jobs.

Can I use it in production?

Yes! CDS is used in production since 2015 @OVH and it launches more than 7M CDS workers per year. You can install the official release available on https://github.com/ovh/cds/releases

CDS provides everything needed to monitor and measure production activity (logs, metrics, monitoring)

How to backup?

All data are stored in the database - nothing on the filesystem. Just backup your database regularly and you will be safe.

Need some help?

Core Team is available on GitHub

CDS User features

Pipeline

Ability to run multiple jobs simultaneously while keeping an isolation between them. See doc about stages & jobs inside a pipeline. A pipeline is started with a context: 0 or 1 application, 0 or 1 environment.

Workflow

A Workflow makes it possible to chain the pipelines. This is a key feature of CDS. You can create workflows using one or more pipelines, pipelines that can be linked together with joins or forks.

You can imagine having only one workflow builder and deploying your entire microservice stack. The same pipeline can be used several times in a workflow, you can associate an application or an environment. You will only have one deployment pipeline and one build pipeline to maintain, even if you have hundreds of applications.

Workflow templates

A workflow template allows you to share and reuse workflows across multiple teams. Any user can create a Workflow Template, maintain it as code or from UI, and bulk update a set of workflows with a single action.

As a company, you can offer a predefined catalog of Workflows allowing you to standardize test and deployment practices across all your teams.

This also reduces the maintenance efforts since templates allow a scalable centralized management.

Visual configuration with Web UI

You can configure everything with the web UI. Even if you have complex use cases, it's usually easier to create your workflows graphically.

Configuration on Git Repository

Pipeline as code is a well-known concept of CI / CD tools. CDS goes a step further and offers workflow as code. This is done by git-pushing using yaml configuration files of your workflow (+ pipeline, + applications, + environment). This is particularly useful as you can test your new workflow on a dev branch, before merging the changes on the master branch.

Configuration as code on UI

You can modify your workflow with the UI, you can also modify the configuration by editing the yaml file directly in the UI if you wish. This is an excellent way to learn how to use the workflow-as-code feature.

Native Git branching

Ability to launch builds based on a branch pattern. This allows, for example, to deploy dev/* branches to "staging" and deploy the master branch to "prod".

Note that CDS's default behavior is to launch the whole workflow on every git commit. This behavior can be altered using "run conditions".

Native GitHub / Bitbucket Server / GitLab integration

2-way integration with most popular git-based products.

  1. Ability to get notified and start a build when a change is pushed.
  2. Ability to notify the git-based tool of the success/failure of the build.

CDS natively supports GitHub, GitLab, and Bitbucket Server. The link between your git repo and CDS is via a CDS application: 1 Git repository == a CDS application. Through this integration, CDS will push the build status of your commits : Building, Success, or Failed.

Multiple VCS Support in Pipeline/Job

CDS gives you the possibility to clone from different git repositories within a single workflow. A CDS workflow can involve several different applications - or none if you do not want to have a connection with a git repo.

Job's Services

Ability to start ephemeral services (a database, a web server, etc.) to support your job. This is particularly handy while testing your code.

In CDS these services are called Service Prerequisites. You just need to specify the corresponding docker image and run params.

Take a simple example: you have a pipeline that builds a docker image containing your application. Your application needs a redis and a PostgreSQL to work. You can, in a CDS job, put three prerequisite services: a redis, a PostgreSQL, and your application. CDS will take care of making a private network between its services so that they can communicate with each other. Your CDS job can thus perform integration tests on your application starting with a real database and a real cache.

Please read: https://ovh.github.io/cds/docs/concepts/requirement/requirement_service/

Secure Remote Caching

A remote cache is used by a team of developers and/or a continuous integration (CI) system to share build outputs. If your build is reproducible, the outputs from one machine can be safely reused on another machine, which can make builds significantly faster

Doc: https://ovh.github.io/cds/docs/components/worker/cache/

Enterprise Notification Bus

As an Enterprise-Grade platform, CDS can send a wide range of its internal events (e.g. build finished) in an event bus. This event flow can then feed other services (reporting, notifications, etc., ).

Built-in Hooks

Ability to launch a workflow manually or with git pushes or via a scheduler or via a webhook. In addition to the above, CDS can also be triggered using an event bus (kafka or RabbitMQ).

Continuous Deployment & Environment Support

Ability to manage multiple environments (e.g. dev/prod/staging) in a secure way with segregated access rights. In practice, an environment is a set of variables that you can use within your workflows.

With CDS, You can use a deployment pipelin

readme truncated — read the full docs on github

Frequently asked questions

Is cds free to use?

cds is open source under the BSD-3-Clause licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does cds do?

Enterprise-Grade Continuous Delivery & DevOps Automation Open Source Platform

What is cds written in?

cds is primarily written in Go. Its source is publicly available at https://github.com/ovh/cds, and it has 4,843 GitHub stars.