ovh / cds

CDS: Continuous Delivery Service 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 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 • CDS Introduction: https://blog.ovhcloud.com/how-does-ovh-manage-the-ci-cd-at-scale/ • DataBuzzWord Podcast (French) : https://blog.ovhcloud.com/understanding-ci-cd-for-big-data-and-machine-learning/ • Continuous Delivery and Deployment Workflows with CDS: https://blog.ovhcloud.com/continuous-delivery-and-deployment-workflows-with-cds/ • Talk at conference Breizhcamp to introduce CDS (French): https://www.youtube.com/watch?v=JUzEQuOehv4 FAQ Why CDS? Discover the Origins • Self-Service • Horizontal Scalability • High Availability • Pipeline Reutilisability • Rest API • Customizable What is a CDS workflow? Most of the CI/CD Tools play with jobs inside a pipeline. CDS introduces a new concept named . 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 / Gerrit integration 2-way integration with most popular git-based products. • Ability to get notified and start a build when a change is pushed. • Ability to notify the git-based tool of the success/failure of the build. CDS natively supports GitHub, GitLab, Bitbucket Server, and Gerrit. 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. Yo…