Comprendre l’intégration et le déploiement continus

Vous avez entendu parler de CI/CD, mais vous ne savez pas de quoi il s’agit ?

Dans l’idéal, les ingénieurs logiciels sont embauchés pour écrire du code qui doit être livré dans un environnement de production afin que l’entreprise qui a besoin du produit puisse l’utiliser. Pour satisfaire les entreprises (souvent appelées utilisateurs/clients), il est essentiel que les produits soient exempts de bogues.

L’approche typique suivie par les ingénieurs logiciels est de travailler dans des branches et de créer une demande d’extraction qui met à jour la branche principale avec la nouvelle mise à jour qui a été faite. Nous avons adopté la pratique consistant à écrire des tests afin de nous assurer que les nouvelles modifications n’introduisent pas de bogues. Dans la plupart des cas, lorsque les développeurs travaillent sur une fonctionnalité, ils ne créent pas de demande d’extraction tant qu’ils n’ont pas complètement terminé la fonctionnalité. Ce qui se passe lorsqu’ils sont prêts, c’est que

• Ils passent beaucoup de temps à essayer de mettre à jour leur base de code avec les changements qui ont eu lieu dans la branche de production pendant qu’ils travaillaient.
• Ce faisant, ils doivent résoudre une série de conflits de fusion.
• Il est également possible qu’ils cassent la branche de production, ce qui affecte ceux qui tirent sur la branche avant que le problème ne soit vu et corrigé.

Si vous avez déjà été confronté à cette situation, vous conviendrez qu’elle peut être pénible – personne n’aime passer sa journée de travail ainsi.

Quelle est la solution ?

L’intégration continue

Pour éviter les scénarios décrits ci-dessus, les équipes d’ingénieurs peuvent adopter une pratique appelée intégration continue. Comme son nom l’indique, cette pratique implique l’intégration continue des modifications apportées au code par les développeurs dans la branche/le référentiel partagé(e). Le code à intégrer doit subir un test vérifié pour s’assurer qu’il ne casse pas l’application. Ce n’est que lorsque le test est réussi qu’il est intégré

Pour comprendre cela, imaginons un scénario réel dans lequel il y a une équipe de 10 développeurs. Ces développeurs créent localement une branche dans laquelle ils écrivent du code pour la mise en œuvre de certaines fonctionnalités. Au lieu d’envoyer des demandes d’extraction lorsqu’ils ont entièrement terminé la fonctionnalité, ils choisissent d’envoyer des demandes d’extraction au fur et à mesure qu’ils apportent de petites modifications. Un exemple de ce type de changement sera la création d’une nouvelle fenêtre modale, en supposant que le développeur travaille sur une fonctionnalité qui permet aux utilisateurs de gérer des tâches individuelles dans l’application. Au lieu d’attendre que la fonctionnalité de gestion des tâches soit terminée, pour respecter un modèle d’intégration continue, le développeur apporte cette petite modification (par rapport à ce sur quoi il travaille) et crée une demande d’extraction pour la fusionner avec le code.

Avant que ce nouveau changement ne soit intégré, une série de tests doit être exécutée.

Les équipes de génie logiciel utilisent des outils tels que Travis CI pour créer ces processus d’intégration et ces tests. Avec de tels outils, les tests sont automatisés, de sorte qu’ils s’exécutent dès qu’une demande d’intégration est soumise à la branche cible sélectionnée lors de la configuration.

Les résultats des tests sont générés et le développeur qui a créé les demandes d’extraction peut voir les résultats et apporter les modifications nécessaires. Les avantages d’une intégration minimale du code et d’un test vérifié sont les suivants ;

• Il devient possible pour l’équipe impliquée de savoir ce qui a causé l’échec du processus de construction ou du test. Cela réduit la possibilité d’envoyer un bogue en production.
• Si l’équipe automatise le processus, elle aura le luxe de pouvoir se concentrer sur sa productivité.

La chose importante à noter dans cette pratique est qu’elle encourage l’équipe à pousser le code vers la branche principale fréquemment. Cette pratique sera inefficace si les autres membres de l’équipe ne puisent pas dans la branche principale pour mettre à jour leur dépôt local.

Types de tests

Lors de l’écriture des tests qui feront partie du processus d’intégration, voici les types de tests qui peuvent être mis en œuvre dans le processus :

• Intégration – il combine les unités individuelles du logiciel et les teste en tant que groupe.
• Unité – il s’agit de tester des unités ou des composants individuels du logiciel, tels que des méthodes ou des fonctions.
• Interface utilisateur – affirme que le logiciel fonctionne bien du point de vue de l’utilisateur.
• Acceptation – teste que le logiciel répond aux exigences de l’entreprise.

Il est important de noter que vous n’avez pas besoin de tester tous ces éléments, car certains d’entre eux peuvent déjà être couverts par le code écrit par le développeur.

Outils d’intégration continue

Sans entrer dans les détails, voici des outils que vous pouvez commencer à utiliser dans vos projets actuels ou nouveaux ;

• Travis CI – connu dans le monde de l’open-source, il vous promet de tester votre code de manière transparente en quelques minutes.
• Circle CI – vous offre la puissance, la flexibilité et le contrôle pour automatiser votre pipeline du contrôle au déploiement.
• Jenkins – fournit des centaines de plugins pour soutenir la construction, le déploiement et l’automatisation de n’importe quel projet.

Si vous ne connaissez pas Jenkins, je vous suggère de suivre ce cours Udemy pour apprendre l’IC avec Java et .NET.

Déploiement continu

À quoi cela sert-il si la fonctionnalité que vous créez reste dans le référentiel pendant des semaines ou des mois avant d’être déployée dans l’environnement de production ? Si les équipes d’ingénieurs peuvent s’efforcer d’intégrer les petites modifications dans la branche principale au fur et à mesure, elles peuvent également pousser ces modifications vers l’environnement de production dès que possible.

L’objectif du déploiement continu est de transmettre les modifications aux utilisateurs dès que les développeurs les intègrent dans la branche principale.

Comme dans le cas de l’intégration continue, lorsque vous utilisez le déploiement continu, des tests et des contrôles automatisés sont mis en place pour s’assurer que les changements nouvellement intégrés sont vérifiés. Le déploiement n’a lieu que lorsque ces tests sont réussis.

Pour qu’une équipe puisse bénéficier de la pratique du déploiement continu, elle doit mettre en place les éléments suivants ;

• Les tests automatisés sont l’épine dorsale essentielle de toutes les pratiques d’ingénierie continue. Dans le cas du déploiement continu, le code à déployer doit répondre à la norme que l’équipe a mise en place pour ce qu’elle a l’intention de diffuser aux utilisateurs finaux. Idéalement, si une nouvelle modification est inférieure au seuil, le test doit échouer et ne pas être intégré. Dans le cas contraire, il est intégré.
• Malgré l’existence de tests automatisés, il est possible que des bogues se glissent dans l’environnement de production. Pour cela, il est nécessaire que l’équipe soit en mesure d’annuler un changement qui a été effectué – annuler un déploiement. Cela devrait permettre de rétablir le code de production tel qu’il était avant la nouvelle modification.
• Des systèmes de surveillance sont nécessaires pour suivre les modifications qui ont été apportées à l’environnement de production. C’est ainsi que l’équipe peut être en mesure de suivre les bogues que les utilisateurs rencontrent lorsqu’ils utilisent les changements déployés.

Les outils mentionnés pour l’intégration continue vous offrent également la possibilité de mettre en place un système de déploiement continu. Il en existe de nombreux autres sur lesquels vous pouvez également vous renseigner.

Conclusion

La productivité d’une équipe de développement est essentielle au succès de l’entreprise. Pour garantir cette productivité, il convient d’adopter des pratiques qui l’encouragent. L’intégration et le déploiement continus sont des exemples de ces pratiques.

Grâce à l’intégration continue, les équipes peuvent pousser autant de code que possible chaque jour. Il devient alors facile de déployer les nouveaux changements auprès des utilisateurs dès que possible. Le déploiement de ces changements permet d’obtenir un retour d’information de la part des utilisateurs. En fin de compte, l’entreprise sera en mesure d’innover sur la base des commentaires reçus, ce qui est bénéfique pour tout le monde.

Vous pourrez également apprendre comment augmenter et optimiser le processus CI/CD.

Si vous êtes un développeur et que vous souhaitez apprendre le CI/CD, consultez cette excellente formation.