Intégration continue, livraison continue ou déploiement continu
Quelle est la différence entre ces trois termes? Mon université fournit les définitions suivantes:
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.
Livraison continue est décrit comme l'évolution logique de l'intégration continue: toujours être capable de mettre un produit en production!
Déploiement contin est décrit comme l'étape logique suivante après la livraison continue: déployez automatiquement le produit en production dès qu'il passe le contrôle qualité!
Ils fournissent également un avertissement: Parfois, le terme "Déploiement continu" est également utilisé si vous êtes en mesure de déployer en continu sur le système de test.
Tout cela me laisse confus. Toute explication un peu plus détaillée (ou fournie avec un exemple) est appréciée!
Intégration continue
Je suis d'accord avec la définition de votre université. Intégration continue est une stratégie permettant aux développeurs d'intégrer du code à la ligne principale de manière continue, et non fréquemment.
Vous pouvez prétendre qu'il ne s'agit que d'une stratégie de branchement dans votre système de contrôle de version.
Cela dépend de la taille des tâches que vous attribuez à un développeur. Si une tâche est estimée à 4-5 jours-homme, le développeur n'aura aucune incitation à livrer quoi que ce soit pendant les 4-5 prochains jours, car il n'en a rien fait pour le moment.
Donc, la taille compte:
small task = continuous integration
big task = frequent integration
La taille idéale de la tâche n’est pas supérieure à une journée de travail. De cette façon, un développeur aura naturellement au moins une intégration par jour.
Livraison continue
Il y a fondamentalement trois écoles dans la livraison continue:
La livraison continue est une extension naturelle de l'intégration continue
Cette école se penche sur la série de signatures d'Addison-Wesley "Martin Fowler" et suppose que, depuis la publication de 2007 s'appelait "Intégration continue" et celle qui a suivi 2011 s'appelait "Continuous Delivery" il s’agit probablement du volume 1 + 2 de la même idée conceptuelle qui concerne le continu quelque chose.
La livraison continue concerne le développement logiciel agile
Dans cette école, l'idée que la livraison continue consiste à soutenir les principes du mouvement agile, et pas seulement en tant que idée conceptuelle ou lettre d'intention = mais pour de vrai - dans la vraie vie.
Prise en compte du premier principe dans le Manifeste Agile où le terme "livraison continue" est réellement utilisé pour la première fois:
Notre priorité absolue est de satisfaire le client par la livraison rapide et continue de logiciels de valeur.
Cette école affirme que la "livraison continue" est un paradigme qui englobe tout le nécessaire pour mettre en œuvre une vérification automatisée de votre "définition de fait" .
Cette école accepte que "livraison continue" et le mot à la mode ou mégatendance "DevOps" sont les deux faces d'une même pièce de monnaie, dans le sens où ils essaient tous les deux d'adopter ou d'encapsuler ce nouveau paradigme ou approche et non juste une technique.
La livraison continue est synonyme de déploiement continu
La troisième école préconise que Déploiement contin et Diffusion continue puissent être utilisés indifféremment pour désigner la même chose.
Lorsque quelque chose est prêt entre les mains des développeurs, il est immédiatement livré 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" ont le même sens.
A quelle école rejoindre
Votre université a clairement rejoint la première école et affirme que nous nous référons aux volumes 1 + 2 de la même série de publications. Mon opinion est qu’il s’agit d’une utilisation abusive du terme livraison continue.
Je préconise personnellement la compréhension du fait que Continuous Delivery est lié à la mise en œuvre d'un soutien concret des idées et des 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 livraison comme synonyme de deploy est principalement recommandée par les fournisseurs d'outils qui créent des consoles de déploiement, en essayant d'obtenir un 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 des utilisateurs finaux aux mises à jour logicielles repose sur la mise à jour de certaines sources centralisées pour cette information et où cette source centralisée n'est pas toujours facile à mettre à jour car elle est monolithique ou présente une cohérence (trop) élevée par nature (Web, SOA, bases de données, etc.).
Pour un grand nombre de domaines, des logiciels sont conçus pour lesquels il n’existe pas de source d’information centralisée (appareils, produits grand public, installations client, etc.) ou pour lesquels la source d’information centralisée est facile à mettre à jour (systèmes de gestion des artefacts app store, référentiels Open Source, etc.). ), il n’ya pratiquement pas de battage publicitaire dans l’expression "déploiement continu". Ils viennent de se déployer; ce n'est pas une grosse chose - ce n'est pas une douleur qui nécessite une attention particulière.
Le fait que le déploiement continu ne soit pas quelque chose d'intéressant en général pour tout le monde est également un argument selon lequel l'école qui prétend que "livraison" et "déployer" sont des synonymes a tout faux. Parce que la livraison continue est tout à fait logique pour tout le monde - même si vous créez des logiciels intégrés dans des appareils ou libérez des plug-ins Open Source pour un framework.
La définition de votre université selon laquelle le déploiement continu est une étape naturelle de la livraison continue suppose implicitement que chaque livraison contrôlée doit être immédiatement disponible pour les utilisateurs finaux. "Libération", qui est à son tour un autre concept qui n’a pas de sens générique pour tout le monde non plus.
Une sortie peut être très stratégique ou politique et il n’ya aucune raison de penser que tout le monde voudrait le faire tout le temps (à moins qu’il ne s’agisse d’une librairie en ligne, d’une entreprise du type service de diffusion en continu). Néanmoins, les entreprises qui ne publient pas tout aveuglément tout le temps peuvent avoir de nombreuses raisons pour lesquelles elles souhaitent tout de même être maîtres du déploiement. Elles le font aussi Déploiement contin. Pas de mise en production, mais de release-candidats à production-like.
Encore une fois, je crois que votre université s'est trompée. Ils confondent "déploiement continu" pour "libération continue".
Le déploiement continu est simplement la discipline permettant de déplacer en permanence le résultat d'un processus de développement vers un environnement de type production, où les tests fonctionnels peuvent être exécutés à grande échelle.
Le récit de la livraison continue
Dans l'image tout s'anime:
Le processus d'intégration continue est les deux premières actions du diagramme état-transition. qui - en cas de succès - lance le pipeline de livraison continue qui implémente le définition de done. Le déploiement n'est que l'une des nombreuses actions à mener de manière continue dans ce pipeline. Idéalement, le processus est automatisé à partir du moment où le développeur s’engage auprès du VCS jusqu’à ce que le pipeline confirme que nous disposons d’une version candidate valide.
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 responsables de DevOps, mais je suis curieux de savoir comment cela correspond à l'ensemble du secteur:
Fondamentalement, je considère la pratique agile de la distribution continue comme un continuum:
Pas continu (tout manuel) 0% ----> 100% de livraison continue de la valeur (tout automatisé)
Étapes vers la livraison continue:
Zéro. Rien n'est automatisé lorsque les développeurs enregistrent le code ... Vous avez de la chance s'ils ont compilé, exécuté ou effectué des tests avant l'enregistrement.
Construction continue: construit automatiquement à chaque enregistrement, ce qui constitue la première étape, mais ne prouve en rien l'intégration fonctionnelle du nouveau code.
Intégration continue (CI): génération et exécution automatisées d'au moins des tests unitaires afin de prouver l'intégration du nouveau code avec le code existant, mais de préférence avec des tests d'intégration finir).
Déploiement continu (CD): déploiement automatisé lorsque le code passe au moins de l'environnement de test à un environnement de test, de préférence dans des environnements plus élevés lorsque la qualité est prouvée par CI ou par marquer un environnement inférieur comme validé après un test manuel. Les tests peuvent être manuels dans certains cas, mais la promotion dans l'environnement suivant est automatique.
Livraison continue: publication automatisée et mise en production du système. Il s’agit d’un CD en production, ainsi que de tout autre changement de configuration, tel que la configuration des tests A/B, la notification aux utilisateurs des nouvelles fonctionnalités, la notification de la prise en charge de la nouvelle version et les notes de modification, etc.
EDIT: Je voudrais souligner qu’il existe une différence entre le concept de "livraison continue", tel que mentionné dans le premier principe du Manifeste Agile ( http://agilemanifesto.org/principles.html ) et la pratique de la livraison continue, qui semble être référencée par le contexte de la question. Le principe de la distribution continue consiste à s'efforcer de réduire les déchets de l'inventaire, comme décrit dans Pensée Lean ( http://www.miconleansixsigma.com/8-wastes.html ). La pratique de la livraison continue (CD) par les équipes agiles est apparue au cours des nombreuses années écoulées depuis la rédaction du Manifeste Agile en 2001. Cette pratique agile aborde directement le principe, même s’il s’agit de choses différentes et apparemment faciles à confondre.
Je pense que la définition d'Amazon est simple et facile à 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 générée, testée et déployée en production. Le passage à la production, une personne, un test automatisé ou une règle de gestion décident du moment où le transfert doit avoir lieu.Bien que toute modification de logiciel réussie puisse être immédiatement mise en production avec une diffusion continue, il n'est pas nécessaire que toutes les modifications le soient 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 endroit, comme une branche principale. . Chaque modification est construite et vérifiée par des tests et d’autres vérifications afin de détecter les erreurs d’intégration le plus rapidement possible. 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 . "
S'il vous plaît vérifier http://docs.aws.Amazon.com/codepipeline/latest/userguide/concepts.html
Atlassian a publié une bonne explication à propos de Intégration continue vs livraison continue vs déploiement contin .
En un mot:
Intégration continue - est une automatisation permettant de créer et de tester des applications chaque fois que de nouveaux commits sont envoyés dans la branche.
Livraison continue - est Intégration continue + Déployez l’application en production en "cliquant sur un bouton" (la diffusion aux clients est souvent, mais à la demande).
Déploiement continu - correspond à livraison continue mais sans intervention humaine (la diffusion aux clients est en cours).
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.
Ou plus de plusieurs fois par jour. Aussi souvent que toute tâche discrète est terminée, fondamentalement. Prenons l'exemple d'une équipe de développeurs travaillant sur une seule application métier. Dans de nombreux environnements, les événements suivants peuvent se produire:
- Un ou deux développeurs conservent les modifications locales pendant quelques jours car "ce n'est pas encore prêt".
- Un ou deux développeurs créent des branches dans le contrôle de code source afin de pouvoir utiliser leurs fonctionnalités "sans être gêné par les modifications apportées par d'autres".
Ceux-ci peuvent conduire à des problèmes. Une mauvaise organisation du code/des tâches entraîne la création de branches, une fusion conduit à la fusion, une fusion… conduit à la souffrance. L’intégration continue en tant que pratique répond à ce besoin 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 pouvoir être terminés en peu de temps (heures au maximum).
En gros, l’idée générale est d’intégrer un petit changement dans une petite quantité de travail. Intégrer un changement important représente une charge de travail disproportionnée. L'ensemble des travaux d'intégration est plus petit s'il est effectué par petites étapes constantes. Cela permet aux développeurs de passer plus de temps à travailler sur des fonctionnalités visibles par l'entreprise plutôt que sur les coûts de processus de développement.
La livraison continue est décrite comme l'évolution logique de l'intégration continue: toujours être capable de mettre un produit en production!
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 jamais ajustée que par petites étapes par des fonctions complètes, testées et connues, cette base de code est toujours stable. Les tests automatisés sont ici essentiels pour pouvoir prouver cette stabilité en appuyant simplement sur un bouton.
Moins il y a de travail de stabilisation à faire (ce qui, encore une fois, est une surcharge du processus de développement et devrait être éliminé), plus souvent la base de code peut être poussée dans un environnement donné. Dans de nombreuses entreprises, un déploiement peut être un processus assez éprouvant. Même une semaine d'opération tout le monde sur le pont. Cela coûte cher et ne produit aucune valeur commerciale. En utilisant de bonnes définitions d'élément 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 dans n'importe quel environnement donné.
Le déploiement continu est décrit comme l'étape logique suivante après la livraison continue: déployez automatiquement le produit en production dès qu'il passe le contrôle qualité!
Vous verrez rarement que cela se produit dans un environnement professionnel, et c'est un vrai bonheur quand on le rencontre. Si la base de code peut être automatiquement testée et déployée automatiquement dans un environnement donné, la production est un environnement comme un autre. Par conséquent, si l'équipe est à la pointe de la technologie, il est possible que le déploiement de mises à jour en production permette de générer une valeur significative pour l'entreprise.
Les corrections de défauts sont envoyées aux clients plus rapidement, les nouvelles fonctionnalités arrivent plus rapidement sur le marché, les nouvelles idées sont testées par rapport au marché par incréments plus petits pour permettre la redirection des priorités, etc.
Par exemple, supposons qu'une entreprise ait une grande idée pour une nouvelle fonctionnalité de son produit ou service basé sur un logiciel. Ils ont fait des recherches, ils connaissent le marché et ils croient que cette idée générera de nouveaux revenus solides. Considérons maintenant deux options pour offrir cette fonctionnalité:
- Passez des mois à développer le tout dans une branche unique. Passez des semaines à l’intégrer dans la base de code principale. Passez des jours à le tester. Passez une journée à le déployer. Et seulement , puis commence à suivre le revenu réel dans le système de production.
- Implémentez de petites parties de la fonctionnalité, une à la fois. Chaque semaine, publiez un nouveau morceau de celui-ci. Chaque semaine, obtenez plus de données sur les revenus réels.
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 souhaitent pas réellement. Dans le second scénario, le fait que les clients ne le souhaitent pas est déterminé beaucoup, beaucoup plus tôt et le reste du travail est dé-hiérarchisé.
En fin de compte, ces "éléments continus" consistent à supprimer les frais généraux de processus de développement. Si la ligne de revenu d'une entreprise est une offre de service particulière, alors, idéalement, tous ses coûts devraient être inclus dans cette offre. La surcharge du processus de développement (fusion de code, re-test des mêmes fonctionnalités après une fusion, tâches de déploiement manuel, etc.) ne contribue pas réellement à la valeur du service. Ces concepts cherchent donc à supprimer ces coûts du processus.
Un graphe peut remplacer plusieurs mots:
Prendre plaisir! :-)
# J'ai mis à jour la bonne image ...
Différence entre intégration continue, livraison continue et déploiement continu
Je pense que nous analysons et compliquons peut-être un peu la suite de mots "continue". Dans ce contexte, continu signifie automatisation. Pour les autres mots associés à "continu", utilisez l'anglais comme guide de traduction et n'essayez pas de compliquer les choses! Dans "construction continue", nous construisons automatiquement (écriture/compilation/lien/etc) notre application dans quelque chose qui est exécutable pour une plate-forme/conteneur/exécution/etc. "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 l’intégration, la construction doit avoir lieu et des tests approfondis seraient également utilisés pour valider l’intégration. Ainsi, dans "l'intégration continue", on utilise l'automatisation pour ajouter de la valeur à un ensemble de fonctionnalités existantes de manière à ne pas perturber négativement la fonctionnalité existante, mais à bien s'y intégrer, ajoutant une valeur perçue à l'ensemble. L’intégration implique, par sa simple définition anglaise, que les choses se marient harmonieusement et que, par conséquent, mon add compile, relie, teste et fonctionne parfaitement dans l’ensemble. Vous n'appelleriez pas quelque chose d'intégré s'il échouait le produit final, n'est-ce pas?! Dans notre contexte, "déploiement continu" est synonyme de "livraison continue" puisqu’au bout du compte, nous avons fourni des fonctionnalités à nos clients. Cependant, en analysant davantage cette situation, 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 livrons. Nous avons déployé le code, mais comme nous n’avons pas communiqué efficacement à nos parties prenantes, nous n’avons pas réussi à livrer du point de vue commercial! Nous avons déployé les troupes mais nous n'avons pas livré l'eau et la nourriture promise à la ville voisine. Et si je devais ajouter le terme "transition continue", aurait-il son mérite? Après tout, il est peut-être préférable de décrire le mouvement du code dans les environnements, car il a la connotation de "de/à" 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'appliquions pas le bon sens.
En conclusion, c’est simple à décrire (le faire est un peu plus… compliqué!), Utilisez simplement le bon sens, la langue anglaise et tout ira bien.
Intégration continue: La pratique consistant à fusionner en permanence le travail de développement avec la branche principale de manière à ce que le code soit testé le plus souvent possible pour résoudre les problèmes à temps.
Livraison continue: Livraison continue du code dans un environnement une fois que le code est prêt à être envoyé. 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 peut être un contrôle qualité ou un client à examiner et à inspecter.
Le test unitaire au cours de la phase d'intégration continue ne permet pas de détecter tous les bogues et la logique métier, en particulier les problèmes de conception. C'est pourquoi nous avons besoin d'un contrôle qualité ou d'un environnement intermédiaire 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 et une livraison continues, sans quoi la qualité du code ne sera pas garantie dans une version.
Déploiement continu ~ ~ Intégration continue + Livraison continue
Intégration continue
- Automatisé (construction de check in + test unitaire)
Livraison continue
- Intégration continue
- Automatisé (déploiement dans l'environnement de test + test de charge + test d'intégration)
- Manuel (déploiement en production)
Déploiement continu
- Livraison continue mais automatisée (déploiement en production)
CI/CD est un voyage. Pas une destination.
Ces étapes sont des suggestions. Vous pouvez adapter les étapes en fonction des besoins de votre entreprise. Certaines étapes peuvent être répétées pour plusieurs types de test, de sécurité et de performance. Selon la complexité de votre projet et la structure de vos équipes, certaines étapes peuvent être répétées plusieurs fois à différents niveaux. Par exemple, le produit final d'une équipe peut devenir une dépendance dans le projet de l'équipe suivante. Cela signifie que le produit final de la première équipe est ensuite mis en scène comme un artefact dans le projet de la prochaine équipe.
Note de bas de page :
pratique de l'intégration continue et de la livraison continue sur AWS
DevOps est une combinaison de 3C - communication continue , , collaboration et cela conduit à se concentrer sur divers secteurs.
Dans un monde d'appareils connectés à l'IoT, de nombreuses fonctionnalités de mêlée telles que le produit propriétaire, le Web, les mobiles et le contrôle qualité fonctionnent de manière agile dans un cycle de mêlée pour fournir un produit au client final.
Intégration continue: La fonction Scrum multiple fonctionne simultanément dans plusieurs terminaux
Livraison continue: Avec intégration et déploiement, la livraison du produit à plusieurs clients doit être traitée en même temps.
Déploiement continu: plusieurs produits déployés sur plusieurs clients sur plusieurs plates-formes.
Regardez cela pour savoir comment DevOps permet au monde connecté à l'IoT: https://youtu.be/nAfZt2t4HqA