Quelle est la différence entre ces trois termes? Mon université fournit les définitions suivantes:
L'intégration continue signifie simplement que les copies de travail du développeur sont synchronisées avec une ligne principale partagée plusieurs fois par jour.
La livraison continue est décrite comme l'évolution logique de l'intégration continue: être toujours en mesure de mettre un produit en production!
Le déploiement continu est décrit comme la prochaine étape logique après la livraison continue: déployez automatiquement le produit en production chaque fois qu'il passe le contrôle qualité!
Ils fournissent également un avertissement: Parfois, le terme «déploiement continu» est également utilisé si vous pouvez déployer en continu sur le système de test.
Tout cela me laisse perplexe. Toute explication un peu plus détaillée (ou accompagnée d'un exemple) est appréciée!
Réponses:
Intégration continue
Je suis d'accord avec la définition de votre université. L'intégration continue est une stratégie permettant à un développeur d'intégrer du code à la ligne principale en continu, par opposition à fréquemment.
Vous pourriez prétendre qu'il s'agit simplement d'une stratégie de branchement dans votre système de contrôle de version.
Cela a à voir avec la taille des tâches que vous attribuez à un développeur; Si une tâche devrait prendre entre 4 et 5 jours-homme, le développeur n'aura aucune incitation à livrer quoi que ce soit au cours des 4 à 5 prochains jours, car il n'a encore rien fait.
La taille compte donc:
La taille idéale d'une tâche n'est pas supérieure à la journée de travail. De cette façon, un développeur aura naturellement au moins une intégration par jour.
Livraison continue
La livraison continue comprend essentiellement trois écoles :
La livraison continue est une extension naturelle de l'intégration continue
Cette école se penche sur la série de signatures Addison-Wesley "Martin Fowler" et fait l'hypothèse que depuis la version 2007 a été appelée "Intégration Continue" et celle qui a suivi en 2011 a été appelée "Livraison Continue" ils sont probablement le volume 1 + 2 de la même idée conceptuelle qui a à voir avec quelque chose de continu .
La livraison continue a à voir avec le développement logiciel Agile
Cette école prend son envol dans l'idée que la livraison continue consiste à être en mesure de soutenir les principes du mouvement agile, non seulement comme une idée conceptuelle ou une lettre d'intention, mais pour la réalité - dans la vraie vie.
Prise de décalage dans le premier principe du Manifeste Agile où le terme "livraison continue" est effectivement utilisé pour la première fois:
Cette école prétend que la «livraison continue» est un paradigme qui englobe tout ce qui est nécessaire pour mettre en œuvre une vérification automatisée de votre «définition du fait» .
Cette école accepte que la «livraison continue» et le mot à la mode ou la mégatendance «DevOps» sont les revers de la même médaille, dans le sens où ils essaient tous les deux d'embrasser ou d'encapsuler ce nouveau paradigme ou approche et pas seulement une technique.
La livraison continue est synonyme de déploiement continu
La troisième école préconise que le déploiement continu et la livraison continue puissent être utilisés de manière interchangeable pour signifier la même chose.
Lorsque quelque chose est prêt entre les mains des développeurs, il est immédiatement remis aux utilisateurs finaux, ce qui signifie dans la plupart des cas qu'il doit être déployé dans l'environnement de production. Par conséquent, «déployer» et «livrer» signifie la même chose.
Quelle école rejoindre
Votre université a clairement rejoint la première école et prétend que nous faisons référence au volume 1 + 2 de la même série de publications. À mon avis, il s'agit d'une mauvaise utilisation du terme livraison continue.
Je plaide personnellement pour la compréhension que la livraison continue est liée à la mise en œuvre d'un support réel pour les idées et les concepts énoncés par le mouvement agile. J'ai donc rejoint l'école qui dit que le terme englobe tout un paradigme - comme "DevOps".
L'école qui utilise la livraison comme synonyme de déploiement est principalement préconisée par les vendeurs d'outils qui créent des consoles de déploiement, essayant d'obtenir un peu de battage médiatique de l'utilisation plus répandue du terme livraison continue .
Déploiement continu
L'accent mis sur le déploiement continu est principalement pertinent dans les domaines où l'accès de l'utilisateur final aux mises à jour logicielles repose sur la mise à jour d'une source centralisée pour ces informations et où cette source centralisée n'est pas toujours facile à mettre à jour car elle est monolithique ou a une cohérence (trop) élevée. par nature (web, SOA, bases de données, etc.).
Pour de nombreux domaines qui produisent des logiciels où il n'y a pas de source d'information centralisée (appareils, produits grand public, installations client, etc.) ou où la source d'information centralisée est facile à mettre à jour (systèmes de gestion d'artefacts des magasins d'applications, référentiels Open Source, etc. ), il n'y a pratiquement aucun battage médiatique concernant le terme Déploiement continu. Ils se déploient simplement; ce n'est pas une grande chose - ce n'est pas une douleur qui nécessite une attention particulière.
Le fait que le déploiement continu n'est pas quelque chose qui est génériquement intéressant pour tout le monde est également un argument selon lequel l'école qui prétend que «livraison» et «déploiement» sont synonymes s'est trompée. Parce que la livraison continue est parfaitement logique pour tout le monde - même si vous utilisez des logiciels intégrés dans des appareils ou publiez des plugins Open Source pour un framework.
La définition de votre université selon laquelle le déploiement continu est une prochaine étape naturelle de la livraison continue suppose implicitement que chaque livraison qui fait l'objet d'un contrôle qualité devrait être disponible immédiatement pour les utilisateurs finaux, est plus proche de la définition que ma tribu utilise pour décrire le terme «continu». Release ", qui, à son tour, est un autre concept qui n'a pas non plus de sens générique pour tout le monde.
Une sortie peut être une chose très stratégique ou politique et il n'y a aucune raison de supposer que tout le monde voudrait le faire tout le temps (à moins qu'il ne s'agisse d'une librairie en ligne, d'un type de société de service de streaming). Néanmoins, les entreprises qui ne publient pas tout à l'aveugle tout le temps peuvent avoir un certain nombre de raisons pour lesquelles elles voudraient être des maîtres du déploiement de toute façon, elles font donc elles aussi le déploiement continu . Pas de version en production, mais de versions candidates à des environnements de production .
Encore une fois, je crois que votre université s'est trompée. Ils confondent «déploiement continu» et «libération continue».
Le déploiement continu est tout simplement la discipline de pouvoir déplacer en continu le résultat d'un processus de développement vers un environnement de production où les tests fonctionnels peuvent être exécutés à grande échelle.
L'histoire de la livraison continue
Dans l'image, tout prend vie:
Le processus d'intégration continue est les deux premières actions du diagramme de transition d'état. qui - en cas de succès - lance le pipeline de livraison continue qui met en œuvre la définition de fait . Le déploiement n'est qu'une des nombreuses actions qui devront être effectuées en continu dans ce pipeline. Idéalement, le processus est automatisé à partir du moment où le développeur s'engage sur le VCS jusqu'au point où le pipeline a confirmé que nous avons une version valide candidate.
la source
Ni la question ni les réponses ne correspondent vraiment à ma façon simple de penser à ce sujet. Je suis consultant et j'ai synchronisé ces définitions avec un certain nombre d'équipes de développement et de personnes DevOps, mais je suis curieux de savoir comment cela correspond à l'industrie dans son ensemble:
Fondamentalement, je pense à la pratique agile de la livraison continue comme un continuum:
Pas continu (tout manuel) 0% ----> 100% Livraison continue de valeur (tout automatisé)
Étapes vers une livraison continue:
Zéro. Rien n'est automatisé lorsque les développeurs archivent le code ... Vous avez de la chance s'ils ont compilé, exécuté ou effectué des tests avant l'enregistrement.
Build continu: build automatisé à chaque enregistrement, ce qui est la première étape, mais ne fait rien pour prouver l'intégration fonctionnelle du nouveau code.
Intégration continue (CI): construction et exécution automatisées d'au moins des tests unitaires pour prouver l'intégration du nouveau code avec le code existant, mais de préférence des tests d'intégration (de bout en bout).
Déploiement continu (CD): déploiement automatisé lorsque le code passe CI au moins dans un environnement de test, de préférence dans des environnements supérieurs lorsque la qualité est prouvée via CI ou en marquant un environnement inférieur comme PASSÉ après un test manuel. IE, les tests peuvent être manuels dans certains cas, mais la promotion vers l'environnement suivant est automatique.
Livraison continue: publication et mise en production automatisées du système en production. Il s'agit d'un CD en production ainsi que d'autres modifications de configuration telles que la configuration pour les tests A / B, la notification aux utilisateurs de nouvelles fonctionnalités, la prise en charge de la nouvelle version et des notes de changement, etc.
EDIT: Je voudrais souligner qu'il y a une différence entre le concept de «livraison continue» tel que référencé dans le premier principe du Manifeste Agile ( http://agilemanifesto.org/principles.html ) et la pratique de la livraison continue, comme semble être référencé par le contexte de la question. Le principe de la livraison continue est celui de s'efforcer de réduire les déchets de l'inventaire comme décrit dans la pensée Lean ( http://www.miconleansixsigma.com/8-wastes.html ). La pratique de la livraison continue (CD) par des équipes agiles est apparue depuis de nombreuses années depuis la rédaction du Manifeste Agile en 2001. Cette pratique agile aborde directement le principe, bien qu'il s'agisse de choses différentes et apparemment facilement confuses.
la source
Je pense que la définition d'Amazon est directe et simple à comprendre.
" La livraison continue est une méthodologie de développement logiciel dans laquelle le processus de publication est automatisé. Chaque modification logicielle est automatiquement créée, testée et déployée en production. Avant la dernière poussée vers la production, une personne, un test automatisé ou une règle métier décide quand le Bien que chaque modification logicielle réussie puisse être immédiatement mise en production avec une livraison continue, toutes les modifications ne doivent pas être publiées immédiatement.
L'intégration continue est une pratique de développement logiciel dans laquelle les membres d'une équipe utilisent un système de contrôle de version et intègrent fréquemment leur travail au même emplacement, comme une branche principale. Chaque modification est construite et vérifiée par des tests et autres vérifications afin de détecter le plus rapidement possible toute erreur d'intégration. L'intégration continue est axée sur la création et le test automatiques du code, par rapport à la livraison continue, qui automatise l'intégralité du processus de publication du logiciel jusqu'à la production . "
Veuillez consulter http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
la source
Atlassian a publié une bonne explication sur l' intégration continue, la livraison continue et le déploiement continu .
En un mot:
Intégration continue - est une automatisation permettant de créer et de tester l'application chaque fois que de nouveaux commits sont insérés dans la branche.
Livraison continue - est une application d' intégration continue + déploiement en production en "cliquant sur un bouton" (la mise à disposition des clients est souvent, mais sur demande).
Déploiement continu - est une livraison continue mais sans intervention humaine (la publication aux clients est en cours).
la source
Ou plus de plusieurs fois par jour. Aussi souvent qu'une tâche discrète donnée est terminée, en gros. Prenons par exemple une équipe de développeurs travaillant sur une seule application métier. Dans de nombreux environnements, les événements suivants peuvent se produire:
Cela peut entraîner des problèmes. Une mauvaise organisation du code / des tâches mène à la ramification, la ramification mène à la fusion, la fusion ... conduit à la souffrance. L'intégration continue en tant que pratique résout ce problème en encourageant tout le monde à travailler à partir de la même source partagée. Les éléments de travail individuels doivent être suffisamment discrets pour être achevés en peu de temps (heures au maximum).
Fondamentalement, l'idée générale est que l'intégration d'un petit changement dans une petite quantité de travail. L'intégration d'un changement important représente une quantité de travail disproportionnée. L'agrégat du travail d'intégration est plus petit s'il est effectué en petites étapes constantes. Cela permet aux développeurs de passer plus de temps à travailler sur des fonctionnalités visibles par l'entreprise au lieu de surcharger le processus de développement.
Cela suit la même idée d'éléments de travail discrets et bien définis. S'il existe une seule base de code maître qui n'est ajustée que par petits incréments par des fonctionnalités de travail complètes, testées et connues, cette base de code est toujours stable. Les tests automatisés sont essentiels ici pour pouvoir prouver cette stabilité en appuyant simplement sur un bouton.
Moins il y a de travail de stabilisation à effectuer (ce qui, encore une fois, est une surcharge de processus de développement et doit être éliminé), plus la base de code peut être poussée dans un environnement donné. Dans de nombreuses entreprises, un déploiement peut être un processus assez exténuant. Même une opération tout-terrain sur une semaine. C'est cher et ne produit aucune valeur commerciale. En utilisant de bonnes définitions d'éléments de travail, des tests automatisés efficaces et une intégration continue, une équipe peut être en mesure d'automatiser la livraison de la base de code à n'importe quel environnement donné.
Vous verrez rarement cela se produire dans un environnement professionnel, et c'est tout à fait une joie quand cela se produit. Si la base de code peut être testée automatiquement et déployée automatiquement dans un environnement donné, alors, la production est un environnement comme les autres. Donc, si l'équipe s'est développée jusqu'à ce point, il existe un potentiel de valeur significative pour l'entreprise en étant toujours en mesure de déployer des mises à jour en production.
Les corrections de défauts sont envoyées plus rapidement aux clients, les nouvelles fonctionnalités arrivent plus rapidement sur le marché, les nouvelles idées sont testées par rapport au marché par petits incréments pour permettre la redirection des priorités, etc.
Par exemple, supposons qu'une entreprise ait une grande idée d'une nouvelle fonctionnalité dans son produit ou service logiciel. Ils ont fait des recherches, ils connaissent le marché et ils croient que cette idée se traduira par une nouvelle ligne de revenus solide. Considérez maintenant deux options pour offrir cette fonctionnalité:
Dans le premier scénario, si la fonctionnalité n'a pas l'effet de marché souhaité, alors beaucoup d'argent est gaspillé pour quelque chose que les clients ne veulent pas réellement. Dans le deuxième scénario, le fait que les clients ne le veuillent pas est déterminé beaucoup, beaucoup plus tôt et le reste du travail est sans priorité.
En fin de compte, ces «choses continues» consistent à supprimer les frais généraux du processus de développement. Si la ligne de revenus d'une entreprise est une offre de service particulière, l'idéal serait que tous ses coûts soient affectés à cette offre. Les frais généraux du processus de développement (fusion de code, nouveau test des mêmes fonctionnalités après une fusion, tâches de déploiement manuel, etc.) ne contribuent pas réellement à la valeur du service, de sorte que ces concepts cherchent à supprimer ces coûts du processus.
la source
Un graphique peut remplacer plusieurs mots:
Prendre plaisir! :-)
# J'ai mis à jour l'image correcte ...
la source
Différence entre intégration continue, livraison continue et déploiement continu
la source
Je pense que nous sommes en train d'analyser et de compliquer peut-être un peu la suite de mots "continue". Dans ce contexte, continu signifie automatisation. Pour les autres mots attachés à "continu", utilisez la langue anglaise comme guide de traduction et n'essayez pas de compliquer les choses! Dans la "construction continue", nous construisons automatiquement (écrire / compiler / lier / etc) notre application en quelque chose qui est exécutable pour une plateforme / conteneur / runtime / etc. Spécifique. «Intégration continue» signifie que votre nouvelle fonctionnalité teste et fonctionne comme prévu lors de l'interaction avec une autre entité. De toute évidence, avant que l'intégration n'ait lieu, la construction doit avoir lieu et des tests approfondis seront également utilisés pour valider l'intégration. Donc, en "intégration continue" on utilise l'automatisation pour ajouter de la valeur à un ensemble de fonctionnalités existant d'une manière qui ne perturbe pas négativement la fonctionnalité existante mais s'intègre plutôt bien avec elle, ajoutant une valeur perçue à l'ensemble. L'intégration implique, par sa simple définition anglaise, que les choses cohabitent harmonieusement donc en langage-code mon add compile, lie, teste et fonctionne parfaitement dans l'ensemble. Vous n'appeleriez pas quelque chose d'intégration s'il échouait le produit final, n'est-ce pas?! Dans notre contexte, «déploiement continu» est synonyme de «livraison continue» car, en fin de compte, nous avons fourni des fonctionnalités à nos clients. Cependant, en analysant cela plus à fond, je pourrais affirmer que le déploiement est un sous-ensemble de la livraison, car déployer quelque chose ne signifie pas nécessairement que nous avons livré. Nous avons déployé le code mais parce que nous n'avons pas t efficacement communiqué à nos parties prenantes, nous n'avons pas réussi à livrer d'un point de vue commercial! Nous avons déployé les troupes mais nous n'avons pas livré l'eau et la nourriture promises à la ville voisine. Et si je devais ajouter le terme de «transition continue», aurait-il son propre mérite? Après tout, c'est peut-être mieux adapté pour décrire le mouvement du code à travers les environnements car il a la connotation de "de / vers" plus que le déploiement ou la livraison qui pourrait impliquer un seul emplacement, à perpétuité! C'est ce que nous obtenons si nous n'appliquons pas le bon sens. aurait-elle son propre mérite? Après tout, c'est peut-être mieux adapté pour décrire le mouvement du code à travers les environnements car il a la connotation de "de / vers" plus que le déploiement ou la livraison qui pourrait impliquer un seul emplacement, à perpétuité! C'est ce que nous obtenons si nous n'appliquons pas le bon sens. aurait-elle son propre mérite? Après tout, c'est peut-être mieux adapté pour décrire le mouvement du code à travers les environnements car il a la connotation de "de / vers" plus que le déploiement ou la livraison qui pourrait impliquer un seul emplacement, à perpétuité! C'est ce que nous obtenons si nous n'appliquons pas le bon sens.
En conclusion, ce sont des choses simples à décrire (le faire est un peu plus ... compliqué!), Utilisez simplement le bon sens, la langue anglaise et tout ira bien.
la source
Intégration continue: La pratique de fusionner le travail de développement avec la branche principale en permanence afin que le code ait été testé aussi souvent que possible pour détecter les problèmes tôt.
Livraison continue: livraison continue de code dans un environnement une fois que le code est prêt à être expédié. Cela pourrait être une mise en scène ou une production. L'idée est que le produit est livré à une base d'utilisateurs, qui peuvent être des AQ ou des clients pour examen et inspection.
Le test unitaire pendant la phase d'intégration continue ne peut pas détecter tous les bogues et la logique métier, en particulier les problèmes de conception, c'est pourquoi nous avons besoin d'AQ ou d'un environnement de test pour les tests.
Déploiement continu: le déploiement ou la publication du code dès qu'il est prêt. Le déploiement continu nécessite une intégration continue et une livraison continue, sinon la qualité du code ne sera pas garantie dans une version.
Déploiement continu ~~ Intégration continue + livraison continue
la source
Intégration continue
Livraison continue
Déploiement continu
CI / CD est un voyage. Pas une destination.
Note de bas de page :
Pratiquer l'intégration continue et la livraison continue sur AWS
la source
Source: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/
Qu'est-ce que l'intégration continue L'intégration continue est un processus ou une pratique de développement de génération automatisée et de test automatisé, c'est-à-dire qu'un développeur est tenu de valider son code plusieurs fois dans un référentiel partagé où chaque intégration est vérifiée par génération et test automatisés.
Si la construction échoue / réussit, elle est notifiée à un développeur et il peut alors prendre les mesures appropriées.
Qu'est-ce que la livraison continue La livraison continue est la pratique où nous gardons notre code déployable à tout moment qui a passé tout le test et a toute la configuration requise pour pousser le code en production mais n'a pas encore été déployé.
Qu'est-ce que le déploiement continu Avec l'aide de CI, nous avons créé la construction de notre application et sommes prêts à passer à la production. Dans cette étape, notre build est prêt et avec CD, nous pouvons déployer notre application directement dans l'environnement QA et si tout se passe bien, nous pouvons déployer la même build en production.
Donc, fondamentalement, le déploiement continu est un pas de plus que la livraison continue. Avec cette pratique, chaque changement qui passe toutes les étapes de votre pipeline de production est communiqué à vos clients.
Le déploiement continu est une combinaison de gestion de configuration et de conteneurisation.
Gestion de la configuration: CM consiste à maintenir la configuration du serveur qui sera compatible avec les exigences de l'application.
Conteneurisation : La conteneurisation est un ensemble de péages qui maintiendront la cohérence à travers l'environnement.
Source Img: https://www.atlassian.com/
la source
DevOps est une combinaison de 3C - continue , communication , collaboration et cela conduit à se concentrer principalement dans diverses industries.
Dans un monde d'appareils connectés à l'IoT, plusieurs fonctionnalités Scrum comme le propriétaire du produit, le Web, le mobile et l'AQ fonctionnent de manière agile dans un cycle Scrum de Scrum pour livrer un produit au client final.
Regardez ceci pour savoir comment DevOps permet le monde connecté à l'IoT: https://youtu.be/nAfZt2t4HqA
la source
D'après ce que j'ai appris avec Alex Cowan dans le cours Continuous Delivery & DevOps , CI et CD font partie d'un pipeline de produits qui consiste en le temps qui passe d'une observation à un produit publié.
Des observations aux conceptions, l'objectif est d'obtenir des idées testables de haute qualité. Cette partie du processus est considérée comme une conception continue .
Ce qui se passe après, lorsque nous passons du Code, il est considéré comme une capacité de livraison continue dont le but est d'exécuter les idées et de les communiquer très rapidement au client (vous pouvez lire le livre de Jez Humble intitulé Continuous Delivery: Reliable Software Releases through Build, Test, et Deployment Automation pour plus de détails). Le pipeline suivant explique les étapes de l'intégration continue (CI) et de la livraison continue (CD).
L'intégration continue , comme l' explique Mattias Petter Johansson ,
(vous pouvez regarder les deux vidéos suivantes pour un aperçu plus pratique en utilisant CircleCI - Prise en main de CircleCI - Intégration continue P2 et Exécution de CircleCI sur Pull Request ).
On peut spécifier le pipeline CI / CD comme suit, qui va de New Code à un produit publié.
Les trois premières étapes concernent les tests, repoussant les limites de ce qui est testé.
Le déploiement continu , d'autre part, consiste à gérer automatiquement le déploiement. Ainsi, tout commit de code qui passe la phase de test automatisé est automatiquement publié dans la production.
Remarque : Ce n'est pas nécessairement à quoi vos pipelines devraient ressembler, mais ils peuvent servir de référence.
la source
permet d'être bref:
CI: Une pratique de développement logiciel où les membres d'une équipe intègrent leur travail au moins quotidiennement. Chaque intégration est vérifiée par une construction automatisée (incluant des tests) pour détecter les erreurs le plus rapidement possible. CD: CD s'appuie sur CI, où vous créez un logiciel de telle sorte que le logiciel puisse être mis en production à tout moment.
la source