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:
small task = continuous integration
big task = frequent integration
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:
Notre priorité absolue est de satisfaire le client par la livraison précoce et continue de logiciels précieux.
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.