Bonjour,
En quelques mots, CDS est un outils d'Intégration Continue et de Déploiement, soit de Continuous Delivery...
Quelques principes sur CDS :
- Vos applications sont buildées par des Pipelines, eux-même composés de Stage, de Job, de Step.
- Un pipeline peut-être utilisé par plusieurs applications
- Un projet contient des applications et des pipelines. Les applications utilisent les pipelines.
- Des variables peuvent être positionnées sur des projets ou des applications
- Une gestion d'environnement (prod, preprod, staging, etc...) est gérée au niveau projet.
En conclusion, vous avez 150 applications similaires à builder & déployer, vous avez la possibilité avec CDS de maintenir que 2 pipelines : un pour le build (Compilation, Test U, Analyse de Code, packaging) et un autre pour le déploiement.
CDS est HA, scalable et en fonction de vos besoins, il y a possibilité d'utiliser des services tels que Objet Storage (pour les artifacts) et Containers pour le provisionning des workers CDS.
Côté Archi:
- une API, une UI
- des hatcheries, qui s'occupent de provisionner des workers.
- Les workers sont peuvent être des containers Docker, des processus locaux sur un host, ou des VM sur OpenStack.
- Ces workers discutent avec l'API. Ce sont les workers qui exécutent les jobs.
Si vous souhaitez lancer CDS en local chez vous, vous pouvez juste lancer une instance d'API et un worker, après avoir buildé le tout à l'aide de Go (1.7 minimum).
Nous allons sortir la documentation associée dans les prochains jours, ainsi que des releases de binaires et des images Docker.
Ce message n'est qu'un aperçu de CDS pour les personnes n'ayant pas eu la chance d'être au Summit hier 
La mise à dispo du code source n'est que le premier pas de notre longue Roadmap...
Vous trouverez ici un exemple de workflow utilisé chez nous pour builder le SDK de CDS, enchainant le build / test / déploiement de l'engine (API), etc...
