CI / CD est une combinaison de pratiques de codage, de culture de travail et d’innovations technologiques qui nous permettent de créer des versions de logiciels plus fréquentes et plus fiables. Les entreprises utilisent CI / CD pour atteindre des jalons de manière prévisible, expédier de meilleurs produits et augmenter la productivité.
CI / CD signifie intégration continue et livraison continue. C’est une méthodologie qui englobe toutes les étapes de la vie du développement logiciel, de la création aux tests, en passant par le déploiement et la maintenance. L’intégration continue est le composant central des pratiques DevOps et Agile.
Le but ultime de CI / CD est de faire des sorties avec moins d’effort et sans stress. L’intégration continue met l’accent sur des tests approfondis pour éliminer l’incertitude liée à la modification du code, tandis que la livraison et le déploiement continus rationalisent le processus de publication et réduisent les risques d’erreur humaine. Intégration continue.
A propos de l’auteur
Marko Anastasov est co-fondateur de Semaphore
Dans le monde de la construction, les architectes s’appuient sur des modèles pour tester les bâtiments. Le moindre changement peut faire la différence entre un pont qui tolère des vents forts et un qui s’effondre. L’intégration continue est aux développeurs ce que les modèles et les simulations sont aux architectes, un moyen de s’assurer que notre travail fonctionne.
L’un des principes fondamentaux de CI est que la branche principale doit toujours être prête à être publiée. Pour y parvenir, nous utilisons des pipelines CI / CD. Les pipelines automatisent le processus de livraison de logiciels. Un pipeline crée du code, exécute des tests et déploie l’application en toute sécurité. Les pipelines se présentent sous toutes sortes de formes; certains nécessitent du matériel dédié et beaucoup de maintenance.
L’intégration continue est suivie de la livraison continue (CD), qui gère tous les nombreux détails nécessaires pour créer un package déployable. Selon la nature du projet, sa sortie peut aller d’un binaire compilé, d’un Java Jar, d’un module ou d’un package minifié à une image de conteneur.
La livraison continue nous permet d’avoir une version fonctionnelle et à jour du projet à tout moment, ce qui rend les équipes d’assurance qualité et les gestionnaires heureux. De plus, les clients peuvent découvrir les nouvelles fonctionnalités plus tôt – une situation gagnant-gagnant car ils ont un aperçu précoce du produit, et nous obtenons des commentaires inestimables. En bref, les pipelines de livraison nous permettent de synchroniser les exigences plus fréquemment.
Sommaire
Déploiement continu
Si nous allons au-delà du territoire de livraison, nous atteignons le déploiement continu. Le déploiement continu passe par la séquence d’étapes qui déploie le code dans l’environnement de production, et il le fait avec une intervention humaine minimale.
Comment savez-vous si vous pratiquez CI / CD? Nous pouvons discuter de méthodologies toute la journée, mais les chiffres ne mentent pas, alors posez-vous la question suivante: puis-je arrêter tout ce que je fais en ce moment et faire une sortie en moins de 20 minutes? Puis-je déployer mon application en appuyant sur un bouton? Si vous avez répondu «oui» aux deux questions, félicitations! Vous faites CI / CD. Sinon, lisez la suite!
Que peut nous apporter CI / CD?
CI / CD peut nous apporter d’énormes gains en agilité et en rapidité – nous pouvons passer d’une publication mensuelle à une sortie hebdomadaire, puis quotidienne et finalement plusieurs fois dans la journée.
Augmentation de la productivité
Il y a une raison pour laquelle tous les éditeurs de logiciels concurrents utilisent l’intégration continue, et c’est parce que cela les aide à atteindre leurs objectifs de manière prévisible. Un pipeline CI / CD supprime toutes les tâches manuelles, ce qui entraîne moins d’erreurs, moins de temps perdu à réparer les choses et plus de temps libre pour se concentrer sur les fonctionnalités.
De meilleurs produits
Le plus grand défi lors du démarrage d’un nouveau projet est de déterminer à quoi il ressemblera et comment il fonctionnera. Un bon design représente la moitié de la bataille gagnée. Une mauvaise conception ralentira le développement, causera de la frustration et aboutira à des résultats décevants pour toutes les personnes impliquées.
CI / CD raccourcit non seulement le cycle de développement, mais nous permet également de progresser par étapes plus petites, d’itérer et de réévaluer les progrès plus souvent. En conséquence, nous avons une meilleure chance de répondre aux besoins précis de nos utilisateurs.
Meilleure qualité, moins de pannes
Le pipeline sera toujours meilleur pour exécuter des tests que nous. Les pipelines sont implacables et sans compromis – les pipelines tiennent le mauvais code à distance. Nous pouvons les utiliser pour appliquer des contrôles de qualité dans les pull requests. Linters, vérificateurs de style, rapports de couverture, détecteurs copier-coller, ils vérifient tous les soumissions anti-modèles, alambiquées ou difficiles à lire. Les tests unitaires et d’intégration vérifient que le nouveau code est fiable et répond aux spécifications.
Plus d’innovation
Sur le compte final, le niveau d’innovation dépend fortement du nombre d’itérations que nous pouvons intégrer avant la sortie. Un cycle de développement plus court nous donne la possibilité de faire plus d’itérations, d’essayer de nouvelles choses, de prendre plus de risques. CI / CD nous donne la liberté d’expérimenter davantage et de réagir rapidement aux besoins changeants.
Une culture ouverte
Les pipelines CI / CD sont transparents – ils montrent à tout le monde l’état actuel du projet, son histoire et sa progression. Cette ouverture favorise une culture de communication, d’appropriation et de responsabilité. Tout le monde voit les contributions et les problèmes peuvent être attribués plus équitablement.
Moins de stress
Lorsque nous systématisons les versions, nous supprimons de nombreux risques inhérents aux correctifs ou aux mises à jour. Les jours de patch peuvent être comme n’importe quel autre jour où nous avons confiance dans le processus. Et si, malgré tout, quelque chose ne va pas, le recul est une retraite stratégique.
Comment commencer à pratiquer CI / CD
Vous n’êtes pas obligé de modifier tout votre flux de travail en même temps. En fait, il est préférable d’apporter des modifications ici et là par petits incréments, voir ce qui fonctionne, ce qui ne fonctionne pas et ajuster au fur et à mesure.
La seule règle est que vous devez avoir toute votre base de code dans un référentiel central comme GitHub, où tout le monde dans l’équipe peut la voir et la modifier. Vous utilisez probablement déjà quelque chose comme ça, donc vous êtes sur la bonne voie vers CI / CD.
Étape de construction
Faites-en votre premier défi pour déplacer le processus de construction vers l’environnement CI. Cela inclut des éléments tels que le téléchargement de dépendances, la compilation ou la création d’images Docker. Si c’est la première fois que vous faites cela en dehors de votre ordinateur portable, vous rencontrerez des problèmes inattendus qui empêchent la construction – c’est bien, vous systématisez le processus et rendez votre code plus résilient.
Une fois que vous avez lancé la construction, faites-en une priorité pour ne jamais la laisser échouer. Si à un moment donné c’est le cas, abandonnez tout ce que vous faites et corrigez-le. N’oubliez pas la directive principale: soyez toujours prêt à publier.
Lors du codage, préférez utiliser des branches de courte durée; ils seront plus faciles à fusionner plus tard. Alors, divisez les gros changements et fusionnez-les séparément. En utilisant des branches focalisées au laser, vous serez en mesure de développer plus rapidement et d’explorer plus d’idées. Et, en parlant de branches, ce n’est pas une bonne idée de les utiliser pour masquer des fonctionnalités. Au lieu de cela, utilisez des indicateurs de fonctionnalité pour désactiver les fonctionnalités qui ne sont pas encore prêtes pour les heures de grande écoute.
Étape de test
Votre deuxième défi est de faire des tests une partie intégrante de votre développement. Les tests sont la première ligne de défense. Les tests sont le principal outil dont vous disposez pour maintenir une qualité élevée et confirmer que le code est correct.
Deux techniques de développement logiciel vous aideront ici: Test-Driven Development (TDD) et Behavior-Driven Development (BDD). Le premier vous encourage à changer l’ordre habituel, à écrire d’abord les tests et à suivre avec le code. La deuxième technique amène cette stratégie d’écriture-test-first au niveau macro, nous donnant une vue du côté de l’utilisateur final.
Faites attention à la durée de fonctionnement du pipeline; si cela prend trop de temps, il est facile de se laisser distraire et de perdre le fil des pensées. Vous constaterez que la résolution de problèmes est beaucoup plus facile si vous pouvez maintenir votre flux. En règle générale, si vous devez attendre plus longtemps que le temps nécessaire pour prendre une tasse de café, vous devez optimiser votre pipeline. Alors, visez qu’il s’exécute en 10 minutes ou moins. De cette façon, vous garderez la boucle de rétroaction courte et le nombre d’itérations élevé.
Voici quelques conseils pour garder la phase de test rapide:
- Classer les tests par niveau: les tests unitaires, les contrôles de style et l’analyse de couverture sont de bas niveau. Les tests d’intégration sont au milieu et les tests d’interface utilisateur sont de haut niveau.
- Ordonner les tests par complexité: commencez par des tests de bas niveau. Souvent, ceux-ci prennent le moins de temps à fonctionner et leur échec marque des problèmes fondamentaux. Il ne sert à rien d’exécuter une suite de tests complexes lorsque nous avons du code qui ne passe même pas les contrôles de qualité de base.
- Intégrez: suivez les tests de niveau intermédiaire tels que l’intégration, les tests fonctionnels et de bout en bout, puis continuez avec des tests d’interface utilisateur de haut niveau, le cas échéant.
- Audit: complétez la phase de test avec des scans de sécurité et de vulnérabilité.
Aussi tentant que cela puisse être, ne commentez jamais les tests qui ont échoué. Il est préférable de résoudre les problèmes tant qu’ils sont encore frais à l’esprit. Dans le même ordre d’idées, rendez-vous service et ne rentrez jamais chez vous avec un engagement raté. Corrigez-le avant de partir ou annulez la modification et réessayez demain. Cela peut sembler dur, mais vous et vous seul êtes responsable des erreurs que vous introduisez.
Étape de livraison
La livraison continue nous permet d’exposer fréquemment les bêta-testeurs à des versions intermédiaires. De cette façon, nous pouvons confirmer et ajuster les spécifications en cours de route. Le produit final sera ainsi bien mieux aligné sur les attentes.
Les pipelines de livraison créent des artefacts déployables. En règle générale, l’étape de livraison déploie l’application dans un environnement de type production. Si tout se passe comme prévu, les modifications sont approuvées et la nouvelle succursale peut être fusionnée dans la ligne principale.
Phase de déploiement
Qui est responsable du déploiement de l’application? Autrefois, cela dépendait de l’équipe des opérations. Mais depuis que DevOps est devenu courant, c’est à vous de décider. Si vous le créez, vous devez également le déployer et le maintenir.
L’étape de déploiement publie l’application. Ce pipeline doit également configurer tous les services, comptes et autres infrastructures connexes dont dépend l’application.
Le déploiement peut être lancé manuellement, mais le processus lui-même doit être automatisé. Si vous devez parcourir une liste de contrôle ou effectuer des étapes manuelles, vous n’y êtes pas encore.
Nous avons à notre disposition de nombreux outils DevOps pour automatiser les déploiements:
- Sans serveur: également appelées Lambdas ou Functions-as-a-Service (Faas), ces plates-formes nous permettent d’exécuter des applications dans le cloud sans avoir à nous soucier de l’infrastructure.
- Gestion de la configuration: nous pouvons utiliser des logiciels comme Ansible, Puppet ou Chef pour configurer des serveurs, installer des services et déployer des applications.
- Infrastructure as code: des outils comme Terraform ou CloudFormation nous permettent de créer une infrastructure à la demande.
- Conteneurs: nous pouvons utiliser des plates-formes telles que Docker Swarm ou Kubernetes pour exécuter des applications conteneurisées à grande échelle
L’adoption de pratiques DevOps et CI / CD implique plus que l’utilisation de nouvelles technologies; il s’agit de promouvoir une culture basée sur la transparence, l’appropriation et la communication.
Cela signifie changer notre façon de penser le développement logiciel et la façon dont les membres de l’équipe interagissent. En fin de compte, c’est une transformation qui conduit à de meilleurs produits et à une meilleure expérience pour toutes les personnes impliquées.
