cds
0.54.1
CDS est une plate-forme d'automatisation de livraison continue et DevOps de qualité d'entreprise écrite dans Go (Lang).
Ce projet est en cours de développement actif
Documentation
CDS fournit une interface utilisateur intuitive qui vous permet de créer des flux de travail complexes, de les exécuter et de creuser dans les journaux en cas de besoin.
Créer et exécuter un workflow avec l'interface utilisateur CDS.
CDSCTL est la ligne de commande CDS - vous pouvez tout scripter avec elle, CDSCTL fournit également des commandes sympas telles que cdsctl shell pour parcourir vos projets et flux de travail sans avoir besoin d'ouvrir un navigateur.
Voir toutes les commandes CDSCTL
Créez un workflow comme code avec la ligne de commande CDS.
Docker-Compose est votre ami, voir des tutoriels prêts à exécuter
La plupart des outils CI / CD jouent avec des travaux dans un pipeline. CDS présente un nouveau concept nommé CDS Workflows . Un flux de travail CDS vous permet de chaîner des pipelines avec des déclencheurs. Un pipeline est structuré en stades séquentiels contenant un ou plusieurs travaux simultanés.
Oui! CDS est utilisé en production depuis 2015 @OVH et il lance plus de 7 millions de travailleurs CDS par an. Vous pouvez installer la version officielle disponible sur https://github.com/ovh/cds/releases
CDS fournit tout le nécessaire pour surveiller et mesurer l'activité de production (journaux, métriques, surveillance)
Toutes les données sont stockées dans la base de données - rien sur le système de fichiers. Sauvegardez simplement votre base de données régulièrement et vous serez en sécurité.
L'équipe de base est disponible sur github
Capacité à exécuter plusieurs travaux simultanément tout en gardant un isolement entre eux. Voir Doc sur les étapes et les travaux dans un pipeline. Un pipeline est démarré avec un contexte: 0 ou 1 application, 0 ou 1 environnement.
Un flux de travail permet de chaîner les pipelines. Il s'agit d'une caractéristique clé des CD. Vous pouvez créer des workflows à l'aide d'un ou plusieurs pipelines, pipelines qui peuvent être liés avec les jointures ou les fourchettes.
Vous pouvez imaginer avoir un seul constructeur de workflow et déployer l'intégralité de votre pile de microservices. Le même pipeline peut être utilisé plusieurs fois dans un flux de travail, vous pouvez associer une application ou un environnement. Vous n'aurez qu'un seul pipeline de déploiement et un pipeline de construction à maintenir, même si vous avez des centaines d'applications.
Un modèle de workflow vous permet de partager et de réutiliser les workflows entre plusieurs équipes. Tout utilisateur peut créer un modèle de workflow, le maintenir en code ou à partir de l'interface utilisateur, et mettre à jour en vrac un ensemble de workflows avec une seule action.
En tant qu'entreprise, vous pouvez offrir un catalogue prédéfini de workflows vous permettant de standardiser les pratiques de test et de déploiement de toutes vos équipes.
Cela réduit également les efforts de maintenance car les modèles permettent une gestion centralisée évolutive.
Vous pouvez tout configurer avec l'interface utilisateur Web. Même si vous avez des cas d'utilisation complexes, il est généralement plus facile de créer graphiquement vos flux de travail.
Pipeline As Code est un concept bien connu d'outils CI / CD. CDS va plus loin et propose un flux de travail sous forme de code. Cela se fait par Git-Pushing à l'aide des fichiers de configuration YAML de votre workflow (+ pipeline, + applications, + Environnement). Ceci est particulièrement utile car vous pouvez tester votre nouveau flux de travail sur une branche de développement, avant de fusionner les modifications de la branche maître.
Vous pouvez modifier votre flux de travail avec l'interface utilisateur, vous pouvez également modifier la configuration en modifiant le fichier YAML directement dans l'interface utilisateur si vous le souhaitez. C'est un excellent moyen d'apprendre à utiliser la fonction de workflow en tant que code.
Capacité à lancer des constructions en fonction d'un modèle de branche. Cela permet, par exemple, de déployer les branches Dev / * pour "stadifier" et déployer la branche maître pour "prod".
Notez que le comportement par défaut de CDS consiste à lancer l'ensemble du flux de travail sur chaque engagement GIT. Ce comportement peut être modifié à l'aide de "conditions d'exécution".
Intégration bidirectionnelle avec les produits à base de GIT les plus populaires.
CDS prend en charge GitHub, GitLab, Bitbucket Server et Gerrit. Le lien entre votre dépôt GIT et CDS est via une application CDS: 1 référentiel GIT == une application CDS. Grâce à cette intégration, les CD pousseront le statut de construction de vos engagements: construire, succès ou échoué.
CDS vous donne la possibilité de vous cloner à partir de différents référentiels GIT dans un seul flux de travail. Un flux de travail CDS peut impliquer plusieurs applications différentes - ou aucune si vous ne voulez pas avoir de connexion avec un repo GIT.
Possibilité de démarrer les services éphémères (une base de données, un serveur Web, etc.) pour prendre en charge votre travail. Ceci est particulièrement pratique lors du test de votre code.
En CDS, ces services sont appelés prérequis de services. Il vous suffit de spécifier l'image Docker correspondante et d'exécuter des paramètres.
Prenez un exemple simple: vous avez un pipeline qui construit une image Docker contenant votre application. Votre application a besoin d'un Redis et d'un PostgreSQL pour fonctionner. Vous pouvez, dans un travail CDS, mettre trois services préalables: un redis, un postgresql et votre application. Les CD s'occuperont de faire un réseau privé entre ses services afin qu'ils puissent communiquer entre eux. Votre travail CDS peut ainsi effectuer des tests d'intégration sur votre application en commençant par une vraie base de données et un cache réel.
Veuillez lire: https://ovh.github.io/cds/docs/concepts/requiment/requiment_service/
Un cache distant est utilisé par une équipe de développeurs et / ou un système d'intégration continue (CI) pour partager des sorties de construction. Si votre construction est reproductible, les sorties d'une machine peuvent être réutilisées en toute sécurité sur une autre machine, ce qui peut rendre les constructions beaucoup plus rapidement
Doc: https://ovh.github.io/cds/docs/components/worker/cache/
En tant que plate-forme de qualité d'entreprise, CDS peut envoyer une large gamme de ses événements internes (par exemple, Build Terminé) dans un bus d'événements. Ce flux d'événements peut ensuite alimenter d'autres services (rapports, notifications, etc.).
Capacité à lancer un flux de travail manuellement ou avec des poussées Git ou via un planificateur ou via un webhook. En plus de ce qui précède, les CD peuvent également être déclenchés à l'aide d'un bus d'événements (Kafka ou RabbitMQ).
Capacité à gérer plusieurs environnements (par exemple Dev / Prod / Staging) de manière sécurisée avec les droits d'accès séparés. En pratique, un environnement est un ensemble de variables que vous pouvez utiliser dans vos workflows.
Avec CDS, vous pouvez utiliser un pipeline de déploiement sur votre environnement de préproduction et utiliser ce même pipeline de déploiement sur votre environnement de production. La possibilité de se déployer en production peut être limitée à un groupe préétabli d'utilisateurs.
Les utilisateurs sont libres de créer des groupes et de gérer les utilisateurs de leurs groupes. Un groupe peut avoir le droit de lire, d'écrire et d'exécuter ses projets et leurs workflows. Vous pouvez également restreindre l'exécution de certains pipelines à certains groupes si vous le souhaitez.
Si vous utilisez des CD comme un outil CI / CD, vous aurez probablement des artefacts construits. Les travaux CDS sont isolés les uns des autres, mais vous pouvez passer des artefacts d'un travail à un autre en utilisant le téléchargement d'artefact et les actions de téléchargement des artefacts. À la fin d'un travail CDS, tous les fichiers sont supprimés des travailleurs. Pour persister des artefacts, les CD peuvent utiliser un stockage rapide ou un système de fichiers donné (non recommandé cependant).
CDS affiche clairement les résultats des tests unitaires et des vulnérabilités détectés lors des constructions.
Un projet CDS est comme un locataire. Tous les utilisateurs peuvent créer un projet CDS, ce projet réunira des applications, des environnements, des pipelines et bien sûr des workflows.
Les projets CDS sont isolés les uns des autres, mais le même groupe peut avoir des droits d'accès à plusieurs projets si vous le souhaitez.
Un modèle de travailleur est un contexte d'exécution des travailleurs. Disons que vous devez exécuter un travail qui nécessite Golang V1.11.5. Dans CDS, il vous suffit de créer un modèle Go Worker, contenant un GO dans la version 1.11.5. Un modèle de travailleur peut être une image Docker, une image OpenStack ou une image vSphere. Bien que les administrateurs CDS puissent offrir des modèles de travailleurs partagés, les utilisateurs peuvent créer leurs propres travailleurs de modèle s'ils le souhaitent.
Sur un projet CDS, vous pouvez ajouter des intégrations comme OpenStack, Kubernetes, etc ... Cela vous offrira des fonctionnalités dans vos workflows. Par exemple, avec l'intégration de Kubernetes, vous pouvez ajouter votre propre cluster à votre projet CDS et donc être en mesure d'utiliser l'action d'application de déploiement pour déployer votre application nouvellement construite sur votre cluster, au format Helm si vous le souhaitez. Vous pouvez bien sûr développer vos propres intégrations.
Après avoir lu les points précédents, vous avez compris: le libre-service est partout. Tous les utilisateurs peuvent créer leurs modèles de projet / flux de travail / travailleurs / modèles de workflow / actions ... et exécuter des travaux dans un environnement totalement isolé. Les projets CDS sont des constructeurs, sur lesquels vous pouvez ajouter des intégrations. Tout cela vous permet d'avoir une seule instance de CD pour toute votre entreprise.
Tout ce que vous pouvez faire avec l'interface utilisateur est disponible via l'interface de ligne de commande (CLI), nommée "CDSCTL". CDSCTL est disponible sur tous les OS: Darwin, FreeBSD, Linux, OpenBSD ... CDSCTL vous permettra de créer, de lancer, d'exporter, d'importer vos workflows, de surveiller vos CD et de naviguer dans vos projets et flux de travail. Pas besoin d'aller à l'interface utilisateur de CDS ou de votre gestionnaire de référentiel pour vérifier l'état de votre engagement, git push && cdsctl workflow --track affichera votre flux de travail dans votre ligne de commande.
Avez-vous des besoins d'automatisation encore plus avancés ou le désir de développer une application qui interroge les CD? L'API REST et le SDK vous permettra de développer facilement votre logiciel.
CDS est open-source depuis octobre 2016. Vous pouvez l'installer librement dans votre entreprise ou à la maison. Certains didacticiels sont disponibles pour vous aider à démarrer un CDS, un docker-compose, l'installation avec des binaires.
La haute disponibilité est un point très important pour un outil CI / CD. CDS est sans état, rien n'est stocké sur le système de fichiers. Cela permet de lancer plusieurs API CDS derrière un équilibreur de charge. Ainsi, vous pouvez mettre à l'échelle l'API de CD à vos besoins. Il permet également des mises à niveau de CD en pleine journée sans impact sur les utilisateurs. Dans la production @OVH, les CD peuvent être mis à jour plusieurs fois par jour, sans avoir un impact sur les utilisateurs ni à arrêter les travailleurs du CDS. Demander à vos utilisateurs de cesser de travailler tout en mettant à jour l'outil de livraison en continu serait ironique, n'est-ce pas? ;-)
CDS expose nativement les données de surveillance. Vous pourrez nourrir votre instance prometheus ou warp10 en utilisant du marium.
Un travail CDS se compose d'étapes. Chaque étape est une action de type intégrée (script, checkoutApplication, artefact upload / download ...). Vous pouvez créer vos actions, en utilisant des actions existantes - ou développer votre action en tant que plugin. Toutes les langues sont prises en charge, tant que la langue prend en charge GRPC.
Le CDS est agnostique aux langues et aux plateformes. Les utilisateurs peuvent lancer des travaux sur Linux, Windows, FreeBSD, OS X, Raspberry ... dans une machine virtuelle apparaître à la demande, dans un conteneur Docker, sur un hôte dédié.
Donc, si votre entreprise utilise plusieurs technologies, les CD ne seront pas un bloqueur pour construire et déployer votre logiciel interne.
L'un des objectifs initiaux de CDS à OVH: construire et déployer 150 applications en tant que conteneur en moins de 7 minutes. C'est devenu une réalité depuis 2015. Quelle est la clé secrète? Échelle automatique à la demande!
Ainsi, vous pouvez avoir des centaines de modèles de travailleurs et, si nécessaire, les CD commencent les travailleurs à l'aide des écloseries.
Un couvoir est comme un incubateur, il donne naissance aux travailleurs du CDS et au droit à la vie et à la mort sur eux.
Plusieurs types d'écloserie sont disponibles:
Alors oui, les mots à la mode ou non, un ondemand à échelle automatique multi-cloud est une réalité avec des CD :-)
BSD 3-CLAUSE
