La réponse acceptée à ma question sur « Quel est le lien entre l'intégration continue et la livraison / le déploiement continu? » Explique également la petite différence entre la livraison continue et le déploiement continu . Il semble être lié à la réponse à une question comme "Comment voulez-vous déployer en production, alors que ce sont les options (exclusives) à choisir:
- Automatique).
- Manuel.
Je ne peux pas imaginer qu'il y aura un pauvre "opérateur" de l'autre côté du mur DevOps, qui va devoir faire quelque chose qui correspond à ce que veut dire "manuel" ... Mes questions:
- Est-ce que ma référence (dans ma question) à "distribuer" versus "installer" est proche d'une possible implémentation de ce genre de "manuel"? Voici une citation pertinente de ma question connexe:
- distribuer à un environnement cible, en utilisant quelque chose comme FTP (si les copies standard ne peuvent pas combler l'écart), mais ne pas encore l'activer dans la cible. C'est ce qui devrait être similaire / proche de la livraison continue , ou non?
- installer (ou activer ) dans un environnement cible, combiné à des choses comme des liaisons, des opérations d'arrêt / de démarrage, etc. Qu'est-ce qui devrait être similaire / proche du déploiement continu , ou non?
- Quelles sont les autres implémentations possibles de celui-ci?
continuous-delivery
continuous-deployment
Pierre.Vriens
la source
la source
Réponses:
Personnellement, je considère le
distributionlogiciel comme une cible comme une étape intermédiaire d'un déploiement - l'installation / l'activation de ce logiciel étant nécessaire pour terminer ce déploiement.Pour moi, le
delivery(comme danscontinuos delivery) s'arrête lorsque le logiciel à déployer est créé et rendu disponible pour le déploiement (c'est-à-dire pour la distribution, l'installation et l'activation)Donc, pour répondre à votre 1ère question, non, je ne considérerais pas la distribution et l'installation comme reflétant l'étape manuelle différenciant la livraison continue du déploiement continu.
Oui, dans certains cas (espérons-le rares), cette étape manuelle n'est que la décision humaine finale pour le déploiement en production, reflétant la méfiance culturelle dans l'automatisation des processus et le confort mental d'avoir une double vérification humaine et d'approuver la décision de déploiement (supposant ainsi responsabilité), même si cette décision est purement prise sur la base d'un algorithme qui peut être automatisé (comme le comptage des résultats des tests de réussite / d'échec).
Mais en général, cela reflète simplement le fait que la décision d'effectuer le déploiement en production n'est pas simplement le résultat d'un algorithme automatisé. Voici quelques exemples de tels cas:
Je ne considérerais donc pas l'étape manuelle simplement comme un problème d'implémentation.
la source
Une considération supplémentaire si vous publiez quelque chose que vous attendez que d'autres projets consomment, deploy prend également le sens de «publier pour que d'autres puissent l'utiliser»
Envisagez un flux de travail dans lequel vous déployez une bibliothèque dans un référentiel d'artefacts commun. Cette partie du processus peut faire partie du déploiement d'un autre composant qui nécessite cet artefact au moment de la construction ou il peut simplement s'agir d'une mise à jour d'une bibliothèque commune. Mais peu importe, pour cet artefact, son cycle de vie ne se termine pas nécessairement par sa mise à disposition pour consommation par d'autres, mais le déploiement de cet artefact dans le référentiel d'artefacts peut être la dernière étape du travail des développeurs après qu'ils ont décidé de couper un nouvelle version et avant que les autres puissent consommer la nouvelle version en toute sécurité.
la source