Il est facile d'expliquer le déploiement continu (CDP). Il est très difficile à mettre en œuvre, car les défis sont souvent cachés et imprévisibles. En fonction de la maturité de votre processus, de votre architecture et de votre code, vous constaterez peut-être que le vrai problème n'est pas le code du pipeline de déploiement continu, mais n'importe où ailleurs. En fait, le développement d'un pipeline de déploiement continu est la partie la plus simple.
Nous ne discuterons pas des changements dans vos autres processus. Nous ne discuterons pas de la manière dont vous pouvez fournir une bonne structure pour le pipeline CDP. Nous n'explorerons pas comment coder votre application pour qu'elle soit compatible avec le pipeline.
Je suppose que vous savez déjà tout cela. J'espère que vous comprenez les concepts de base du développement agile et des opérations d'exploitation et de maintenance, et que vous avez commencé à étudier le cadre technique de votre entreprise.
Je suppose que vous savez quelle architecture logicielle est native du cloud et que vous atteignez certains (sinon tous) des 12 facteurs. Je pense que vous êtes déjà engagé dans le développement piloté par les tests, le développement piloté par le comportement, le développement piloté par l'acceptation ou toute autre technologie qui peut vous aider à concevoir des applications.
J'ai peut être tort. Plus précisément, je suis sûr que je me suis trompé. La plupart des gens n'ont pas encore atteint ce niveau. Si vous en faites partie, veuillez lire attentivement ce qui suit. Vous devez lire plus de livres, suivre des cours et convaincre votre chef de projet de vous fournir le temps, l'espace et les ressources nécessaires pour moderniser votre application. Ce travail doit être achevé.
Tout cela et bien d'autres font la différence entre les grandes entreprises (telles que Google, Amazon, Netflix) et le reste d'entre nous. Néanmoins, ce ne sont pas les mêmes. Chaque entreprise performante est différente, cependant, elles ont toutes des points communs. Ils ont tous besoin de publier des fonctionnalités rapidement.
Ils doivent tous avoir un niveau de qualité élevé. Ils admettent tous que la haute disponibilité, la tolérance aux pannes et les systèmes distribués nécessitent une approche très différente de celle à laquelle la plupart d'entre nous sommes habitués.
Nous avons discuté de la structure des pipelines de déploiement continu dans ce blog et dans le livre que j'ai publié. Si vous êtes un peu oublié (je sais que je le suis), voici quelques versions courtes des règles.
Règle 1: si toutes les étapes du pipeline entièrement automatisé sont passées, chaque validation dans la branche principale sera déployée en production. Si vous devez impliquer des opérations humaines après la soumission, il ne s'agit pas d'un déploiement continu ou d'une livraison continue. Au mieux, vous effectuez une intégration continue.
Règle 2: vous souhaitez soumettre directement à la branche principale, ou vous utilisez des branches de fonctionnalités à court terme. La branche principale est la seule branche importante. La version de production est faite par lui. Si vous utilisez des branches, elles seront extraites de la branche master, car c'est la seule branche qui compte vraiment.
Lorsque vous créez une branche de fonctionnalité, vous la fusionnerez à nouveau dans la branche principale. Vous n’avez pas besoin d’attendre quelques semaines pour le faire. Si tel est le cas, vous ne vérifierez pas "en permanence" que votre code est intégré à un autre code.
Si tel est le cas, vous n'effectuez même pas une intégration continue. À moins que vous n'ayez une stratégie de branchement bien conçue, auquel cas vous ne ferez que rendre la vie de tout le monde plus compliquée qu'elle ne l'était auparavant.
Règle 3: Vous devez croire à l'automatisation. Lorsque le test échoue, une erreur se produit et vous devez la corriger avant que tout autre problème ne se produise.
J'espère que vous ne faites pas partie de ces grandes entreprises, les tests sporadiques de ces entreprises fonctionnent parfois, et parfois ils échouent pour des raisons aléatoires.
Si c'est le cas, corrigez d'abord vos tests ou supprimez les tests sporadiques. Il ne sert à rien d'exécuter un test auquel vous ne faites pas confiance. La même chose peut être dite pour la construction, le déploiement et toutes les autres étapes du processus.
Si vous pensez appartenir à quelqu'un qui ne fait pas confiance à son code, vous devez d'abord le corriger. Le test est du code, tout comme la construction, le déploiement et tout le reste.
Lorsque le code produit des résultats incohérents, nous le corrigeons au lieu de le redémarrer.
Malheureusement, je vois que de nombreuses entreprises préfèrent réexécuter une version qui a échoué au test, plutôt que de réparer le défaut qui a échoué au test.
En redémarrant l'application, un nombre stupéfiant de la moitié des problèmes de production ont été résolus. Dans tous les cas, si vous ne faites pas confiance à votre automatisation, vous ne pouvez pas déployer automatiquement dans un environnement de production. Vous ne pouvez même pas dire qu'il est prêt.
Maintenant que nous avons établi un ensemble simple de règles de base, nous pouvons aller de l'avant et décrire le pipeline que nous devrions développer. Nous devons construire quelque chose.
Puisqu'il n'y a pas de construction d'unités en marche et d'autres types de tests statiques, il devrait être déclaré officiellement illégal et "puni par l'humiliation publique", ce que nous avons inclus dans notre phase de construction.
Ensuite, nous effectuerons les étapes de la phase de test fonctionnel, qui exécutera divers tests nécessitant des applications en temps réel. Par conséquent, nous devons déployer la version de test à ce stade.
Une fois que nous sommes certains que notre application fonctionne comme prévu, nous passerons à la version de production, puis à la phase de déploiement. Cela permettra non seulement de mettre à niveau la version de production, mais également d'exécuter une autre série de tests pour vérifier que tout fonctionne comme prévu.
Vous pouvez être en désaccord avec le nom de la scène. C'est bon. Peu importe comment vous le nommez et comment vous regroupez les étapes. Il est important que le pipeline dispose de tout ce dont nous avons besoin pour garantir que la version est déployée en toute sécurité en production. Les étapes sont importantes, les étapes ne sont que des étiquettes.
Boîte à outils DevOps 2.4: déploiement continu sur Kubernetes
L'article que vous venez de lire est tiré du DevOps 2.4 Toolkit: Continuous Deployment to Kubernetes.
Ce livre traite du déploiement continu des clusters Kubernetes. Il utilise diverses plates-formes Kubernetes et fournit des instructions sur la façon de développer des pipelines sur les quelques outils CI / CD les plus couramment utilisés.
Ce livre n'est pas votre premier contact avec Kubernetes. Je suppose que vous êtes déjà familiarisé avec les déploiements, les ReplicaSets, les pods, les entrées, les services, les volumes persistants, les demandes de volumes persistants, les espaces de noms et certains autres outils. Ce livre suppose que nous n'avons pas besoin d'apprendre les choses les plus élémentaires. Du moins, pas encore une fois.
Ce livre suppose que le lecteur possède un certain degré de connaissances Kubernetes et une expérience pratique. Si ce n'est pas le cas, le contenu suivant peut être déroutant et progressif.
Veuillez d'abord lire DevOps 2.3 Toolkit: Kubernetes, ou reportez-vous à la documentation Kubernetes. Revenez une fois que vous avez terminé, une fois que vous pensez pouvoir affirmer que vous comprenez au moins les concepts et les types de ressources de base de Kubernetes.
Essayez-le et dites-moi ce que vous en pensez.
Traduction: To Great
Lien d'origine: https://technologyconversations.com/2018/07/24/exploring-the-continuous-deployment-process/
Modèle de maturité des capacités de développement et d'intégration des opérations (DevOps) Partie 3: L'évaluation de la livraison continue est maintenant disponible pour enregistrement!
Bienvenue à toutes les grandes entreprises pour se renseigner et évaluer l'inscription
Pour l'évaluation, veuillez consulter: Niu Xiaoling
Contact: 010-62300559
Courriel: [email protected]
Pour la formation, veuillez consulter:
Yang Wenhui Contact: 13021086339
Email: [email protected]
Vidéo de présentation du modèle de maturité de la capacité d'intégration de la R&D et des opérations ▽
Cliquez sur moi pour regarder la vidéo