Clause de non-responsabilité . Kostis Kapelonis - Promoteur des développeurs Codefresh, la première plate-forme CI / CD pour Kubernetes et conteneurs, pour défendre et faire respecter les principes du développement logiciel. La mission de Codefresh "Automatiser et simplifier tout, du code au cloud." En tant qu'ingénieur logiciel, Kostis possède de nombreuses années d'expérience dans la conteneurisation d'applications, la construction de pipelines CI / CD et le développement d'applications Java. Il vit en Grèce et aime le patin à roulettes.
Comme dit le proverbe, "si quelque chose cause de la douleur, faites-le plus souvent". L'intégration continue est, par essence, une répétition de l'étape d'intégration avec une fréquence élevée afin d'atténuer la «douleur» qu'elle provoque. Cet article est à ce sujet - sur la «douleur» du développement et comment le réduire.
Il y a beaucoup d'informations sur l'intégration continue (CI) et la livraison continue (CD). Les articles de blog utilisent des termes techniques pour expliquer ce que les méthodologies CI / CD signifient, ce qu'elles font et comment elles peuvent aider votre entreprise. Malheureusement, ces deux méthodologies sont souvent associées à des outils spécifiques ou même à des fournisseurs de logiciels. Une conversation typique sur ce sujet dans une entreprise est:
- Utilisez-vous l'intégration continue dans votre équipe?
- Oui, bien sûr, nous utilisons l'outil X!
Permettez-moi de vous dire un petit secret. L'intégration et la livraison continues sont deux approches du développement de code qui n'ont aucun lien avec un outil ou un fournisseur particulier. Bien qu'il existe des outils et des solutions qui peuvent vous aider dans les deux cas (par exemple, Codefresh), en réalité, une entreprise peut pratiquer CI / CD en utilisant uniquement des scripts bash et des scripts Perl sur une seule ligne. Ce n'est pas très pratique, mais certainement tout à fait possible.
Par conséquent, au lieu de tomber dans le piège général d'expliquer l'essence du CI / CD à l'aide d'outils et de termes techniques, nous expliquerons sur quoi ces méthodologies sont basées sur le facteur le plus important du processus de développement - les gens!
L'histoire des gens: l'intégration logicielle des temps difficiles
Rencontrez Alice, Bob, Charlie, David et Elizabeth - tous travaillent pour SoftwareCo Inc. sur la création de l'application SuperBigProject. Alice, Bob et Charlie sont des développeurs. David est ingénieur d'essais et Elizabeth est chef de projet d'équipe.
La manière traditionnelle de développer une application est la suivante: Alice, Bob et Charlie travaillent sur trois fonctions différentes sur leur poste de travail. Chaque développeur écrit et teste le code individuellement. Ils utilisent de longues branches de fonctions qui existent pendant plusieurs semaines voire plusieurs mois avant d'être combinées en un produit final.
À un moment donné, la gestionnaire de projet Elizabeth rassemble toute l'équipe et dit: "Les gens, nous devons déjà publier une version, alors essayez!"
Après cela, Alice, Bob et Charlie essaient d'intégrer leurs trois fonctions dans une seule branche. C'est une période très stressante car ces fonctionnalités n'ont jamais été testées ensemble. De nombreuses erreurs et problèmes apparaissent de nulle part, en raison d'hypothèses incorrectes ou de problèmes avec l'environnement, car, si vous vous en souvenez, jusqu'à présent, toutes les fonctions ont été simplement testées sur différents postes de travail, isolés les uns des autres.
Dès que la «fièvre de l'intégration» est terminée, le résultat combiné est transmis à David, qui effectuera des tests manuels et automatiques supplémentaires. Cette période prend également beaucoup de temps, car c'est David qui peut approuver ou bloquer la publication, selon le nombre d'erreurs critiques détectées. Tout le monde surveille attentivement David pendant qu'il fait sa part, car le tester peut révéler de graves problèmes qui pourraient retarder la sortie du produit.
Enfin, les tests sont terminés et Elizabeth annonce avec joie que le produit logiciel est prêt pour l'emballage et l'expédition.
Alors, comment les gens se sentent-ils dans cette histoire imaginaire, mais très réaliste?
- Les développeurs Alice, Bob et Charlie sont mécontents car ils découvrent toujours les problèmes d'intégration juste avant la sortie. La période d'intégration est similaire à une fusillade dans laquelle les balles arrivent simultanément de tous les côtés.
- Le testeur David est constamment nerveux à cause de la nature de «contraction» de son travail - il y a des périodes calmes où il attend juste que les développeurs finissent de travailler sur les fonctions, et il y a une phase de test quand il est juste submergé de travail et doit faire face à des scripts de test inattendus, pour de plus, à cette époque, l'équipe de développement se tient littéralement derrière lui.
- Elizabeth, en tant que chef de projet, est également mécontente. La phase d'intégration est un maillon essentiel du projet. Il s'agit d'une période chargée, car tout problème inattendu pousse à la libération du produit. Elizabeth rêve d'une version logicielle sans surprise, mais en pratique cela n'arrive jamais. Le «succès» de la phase d'intégration dans le calendrier prévu du projet est toujours un jeu de devinettes.
En général, tous les membres de l'équipe sont mécontents. Soit dit en passant, si votre entreprise développe encore de tels logiciels, essayez de comprendre que ce processus de développement est préjudiciable au moral de votre équipe.
Donc, ici, le seul et principal problème est la phase d'intégration, qui se produit avec chaque version du produit logiciel. Il s'agit d'un point douloureux dans le flux de travail qui ne permet pas à une équipe de programmeurs de se libérer de la situation stressante associée à la sortie du programme.
Ajout de continuité à l'intégration
Maintenant que nous avons vu ce que signifie «intégration», il est très facile de comprendre ce que signifie «intégration continue». Comme dit le proverbe, "si quelque chose cause de la douleur, faites-le plus souvent". L'intégration continue est, par essence, une répétition de l'étape d'intégration à haute fréquence afin d'atténuer la «douleur» qu'elle provoque.
Le moyen le plus évident de rendre le processus moins pénible est de s'intégrer plus souvent après chaque fusion, plutôt que d'attendre la sortie officielle.
Lorsqu'une équipe pratique l'intégration continue, alors:
- Tous les objets sont fusionnés directement dans la branche principale.
- Les développeurs travaillent ensemble, pas isolément. Toutes les fonctions sont développées à partir de la ligne principale.
- Une fonction est considérée comme développée si la ligne principale est pleinement opérationnelle et fonctionne sur n'importe quelle machine, et pas seulement sur un poste de travail séparé.
- Les tests ont lieu automatiquement à la fois au niveau des éléments individuels ou des objets de code et au niveau de la ligne principale.
C'est l'essence même de l'intégration continue. Bien sûr, il existe d'autres nuances de cette méthodologie, il y a tout un livre sur ce sujet, mais l'essentiel est qu'au lieu d'une seule période d'intégration stressante, lorsque tout est fusionné et testé en même temps, l'intégration se produit tout le temps de manière continue.
L'intégration continue dans le processus de développement logiciel est supérieure à l'intégration conventionnelle car:
- Réduit le nombre de surprises qui apparaissent lors de la fusion d'objets de code.
- Il résout le problème «le programme ne fonctionne que sur ma machine».
- Il divise la période de test en plusieurs périodes, où chaque objet de code fusionne progressivement avec la ligne principale, au lieu de fusionner tous les objets à la fois.
Par conséquent, l'équipe utilisant CI ne se sent pas comme une montagne russe lorsque les périodes de développement calmes sont entrecoupées de rejets stressants. De plus, elle a l'opportunité d'évaluer sobrement la fin du projet, au lieu de deviner les dates de sortie. L'utilisation de CI est l'un des piliers du développement logiciel moderne. Aujourd'hui, cette méthode est très bien documentée et bien connue. Par conséquent, rien ne peut justifier que votre entreprise ne pratique toujours pas l'IC dans le développement de projets logiciels.
Difficulté de livraison des logiciels
Maintenant que nous avons examiné l'historique de l'intégration régulière et le fonctionnement de l'intégration continue, nous pouvons passer à l'étape suivante du processus de développement: la livraison continue. Si nous revenons à notre histoire d'origine, nous verrons une image similaire au processus d'intégration normale:
Le lancement du produit était essentiellement un événement semblable au Big Bang. Une fois le logiciel considéré comme testé, quelqu'un a dû terminer le processus de réduction et de déploiement du logiciel à partir des conteneurs. Le déploiement de logiciels en production a également été une période très chargée et comprenait traditionnellement de nombreuses étapes manuelles et procédures de suivi. Les déploiements étaient très rares, et même aujourd'hui, certaines entreprises n'effectuent cette procédure qu'une fois tous les six mois. Ce n'est que dans des cas extrêmes que le déploiement a eu lieu à un moment - lors de l'utilisation du modèle en cascade de développement logiciel (cascade).
La livraison de logiciels uniquement après avoir atteint la date limite crée les mêmes problèmes que les intégrations régulières et peu fréquentes:
- L'environnement de production est généralement différent de l'environnement de test, qui nécessite une configuration supplémentaire à la dernière minute.
- Les fonctions qui fonctionnaient normalement dans un environnement de test se brisent dans l'environnement de travail.
- Les fonctions qui n'étaient pas prêtes au moment de la publication ne sont jamais fournies aux clients ou leur perfectionnement pousse la publication encore plus loin.
- À cet égard, les versions créent une tension entre les développeurs qui souhaitent ajouter de nouvelles fonctionnalités pour étendre les fonctionnalités du logiciel, et les opérateurs qui veulent de la stabilité et ne veulent pas déployer trop de nouvelles fonctions à la fois.
La solution à ce problème est le même modèle que dans le cas de l'intégration. Si nous pouvons alléger la douleur du processus d'intégration en le rendant plus fréquent, nous pouvons faire de même dans le processus de livraison de logiciels.
Ajoutez de la continuité à la livraison
La livraison continue consiste à emballer dans des conteneurs et à préparer le logiciel comme s'il était envoyé à la production, aussi souvent que possible. Et la méthode de livraison la plus extrême est après chaque fusion.
De cette façon, le CD pousse CI un peu plus loin. Après avoir fusionné chaque fonction avec la branche principale, l'application est non seulement vérifiée pour son exactitude, mais elle est également empaquetée et déployée dans un environnement de test qui correspond parfaitement à l'environnement de travail. Tout cela se passe dans un mode entièrement automatique - faites attention à l'absence dans la figure des petits hommes qui indiquent des procédures manuelles.
Gardez également à l'esprit que chaque nouvelle fonctionnalité est un candidat potentiel pour le lancement en production. En pratique, tous les candidats ne sont pas envoyés en production. Selon l'organisation du processus, la décision de déploiement en production nécessite parfois l'intervention d'une personne responsable qui décide de mettre ou non la release en production, mais ne participe pas personnellement à la préparation de la release. À ce stade, la version est déjà packagée, testée et déployée dans un environnement de test.
La livraison continue (CD) est un peu plus compliquée que l'intégration continue (CI). La raison en est que, puisque chaque version candidate peut potentiellement atteindre la production, le cycle de vie complet doit être automatisé:
- Les assemblages doivent être reproductibles et déterministes.
- Toutes les étapes doivent être automatisées, ce qui est assez difficile à mettre en pratique.
- Tous les fichiers de configuration et connexes doivent exister dans le système de contrôle de version, et pas seulement dans le code source.
- Chaque fonctionnalité / version doit être testée dans son propre environnement de test créé et détruit dynamiquement.
- Toutes les suites de tests doivent être automatisées et relativement rapides, ce qui n'est pas non plus une tâche facile.
Bien qu'un «cloud» puisse certainement aider à répondre à toutes ces exigences, une équipe de programmeurs, développeurs et opérateurs, a besoin d'un certain niveau de discipline qui assure vraiment le processus de livraison continue de logiciels.
Après l'introduction des versions de CD deviennent une routine, comme si elles étaient effectuées avec un simple clic sur un bouton. Chaque membre de l'équipe, et pas seulement le chef de projet, peut voir le candidat de la version actuelle. Ce candidat peut ne pas avoir certaines fonctions requises ou il peut ne pas satisfaire pleinement toutes les exigences, mais ce n'est absolument pas important jusqu'à ce qu'il affecte le processus de publication lui-même.
Le fait important est que la version est entièrement testée, conditionnée et prête à être envoyée en production si nécessaire. Dans le même temps, tout participant au projet devrait être en mesure de donner son feu vert et de publier immédiatement un logiciel pour la production.
Si vous utilisez un CD, le cycle de vie du logiciel peut être représenté comme suit:
Chaque candidat à la version est toujours préparé à l'avance. La personne décide si le candidat à la libération sera également nommé pour la production. Les candidats à la libération qui n'atteignent pas la production continuent d'être stockés en tant qu'artéfacts au cas où ils devraient être utilisés à l'avenir.
Pour votre information, sur la livraison continue, ainsi que sur l'intégration continue, un livre entier a également été écrit à partir duquel vous pouvez découvrir les détails de cette méthodologie.
Bonus: déploiement continu
La lettre «D» sur le CD peut signifier le déploiement de déploiement, pas la livraison de livraison. Cette approche du processus de développement est basée sur une livraison continue et élimine essentiellement l'intervention humaine. Tout candidat à la sortie, qui passera tous les tests et contrôles de qualité et sera reconnu comme prêt, est immédiatement envoyé en production.
Certes, seul un très petit nombre d'entreprises sont en mesure de fonctionner de cette manière. La promotion à la production sans intervention humaine ne doit pas être prise à la légère, car au moment d'écrire ces lignes, de nombreuses entreprises ne pratiquent même pas la livraison continue, sans parler du déploiement continu.
Vous devez comprendre que chaque approche ultérieure du processus de développement est basée sur la mise en œuvre de l'approche précédente.
Avant de progresser sur la voie de l'amélioration, votre entreprise doit s'assurer que chacun des fondements du processus est vraiment solide. Chez Codefresh, nous avons vu de nombreuses entreprises qui avaient l'intention de passer aux technologies cloud, essayant de convertir leurs technologies optimisées pour une utilisation dans les centres de données sur les pipelines CI / CD, sans se rendre compte que certaines de ces technologies sont obsolètes aujourd'hui. Tenter de déployer un déploiement continu sans adopter pleinement la livraison continue est voué à l'échec.
La figure suivante montre quelles étapes du processus de développement et d'implémentation de logiciels par Alice, Bob, Charlie, David et Elizabeth couvrent les CD et CI.
Assurez-vous d'approcher chaque paradigme de développement logiciel dans le bon ordre. Croyez que l'introduction de la livraison continue est un objectif très réaliste, pour la mise en œuvre de laquelle il y a tous les outils nécessaires.
Un peu de publicité :)
Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le
cloud VPS pour les développeurs à partir de 4,99 $ , une
réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: toute la vérité sur VPS (KVM) E5-2650 v4 (6 Cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment partager un serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher? Nous avons seulement
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?