Entendu CI / CD mais vous ne savez pas ce que c'est?
Idéalement, les ingénieurs en logiciel sont embauchés pour écrire du code qui doit être expédié vers un environnement de production afin que l'entreprise qui a besoin du produit puisse l'utiliser. Pour satisfaire l'entreprise (souvent appelée utilisateurs / clients), il est essentiel que les produits soient exempts de bogues.
L'approche typique suivie par les ingénieurs en logiciel est de travailler dans les branches et de créer une pull request qui met à jour la branche principale avec la nouvelle mise à jour qui a été effectuée. Nous avons adopté la pratique d'écrire des tests comme un moyen de garantir que les nouveaux changements n'introduisent pas de bogues. Lorsque les développeurs travaillent sur une fonctionnalité dans la plupart des cas, ils ne créent souvent pas de pull request tant qu'ils n'ont pas complètement terminé avec la fonctionnalité. Ce qui se passe quand ils sont prêts, c'est cela;
- Ils passent beaucoup de temps à essayer de mettre à jour leur base de code avec les changements survenus 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 rompent la branche de production, ce qui affecte ceux qui quittent la branche avant que le problème ne soit vu et résolu.
Si vous avez déjà été dans cette situation, vous conviendrez que cela peut être pénible - personne n'aime volontairement passer sa journée de travail comme ça.
Quelle est la solution?
Continuous Integration
Pour éviter les scénarios que j'ai énoncés ci-dessus; les équipes d'ingénieurs peuvent adopter la pratique appelée intégration continue - comme son nom l'indique, cela implique l'intégration continue des modifications de code effectuées par les développeurs dans la branche / le référentiel partagé. 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 réussit qu'il est intégré
Pour comprendre cela, imaginons un scénario réel où il y a une équipe de 10 développeurs. Ces développeurs créent une branche localement dans laquelle ils écrivent du code pour l'implémentation de certaines fonctionnalités. Au lieu d'envoyer des pull requests lorsqu'ils ont entièrement terminé avec la fonctionnalité, ils choisissent d'envoyer des pull requests car ils apportent de petits changements. Un exemple d'un tel changement sera la création d'un nouveau modal, 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 fonction de tâche soit terminée, pour adhérer à un modèle d'intégration continue, le développeur pousse ce petit changement (par rapport à ce sur quoi elle travaille) et crée une pull request pour fusionner avec le code.
Avant d'intégrer ce nouveau changement, une série de tests doivent être exécutés.
Les équipes d'ingénierie logicielle utilisent des outils tels que Travis CI pour créer ces processus et tests d'intégration. Avec de tels outils, les tests sont automatisés, de sorte qu'il s'exécute dès qu'une pull request 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 pull requests peut voir les résultats et apporter les modifications nécessaires. Les avantages de s'en tenir à ce modèle d'intégration de code aussi peu que possible et d'avoir un test vérifié à exécuter sont;
- Il devient possible pour l'équipe impliquée de savoir ce qui a provoqué 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 se concentrer sur sa productivité.
La chose importante à noter dans cette pratique est qu'elle encourage l'équipe à pousser fréquemment le code vers la branche principale. Cela sera inefficace si d'autres membres de l'équipe ne sortent pas de la branche principale pour mettre à jour leur référentiel local.
Types de tests
En écrivant des tests qui feront partie du processus d'intégration, voici quelques-uns qui peuvent être implémentés dans le processus:
- Intégration - il combine des unités individuelles du logiciel et les teste en tant que groupe.
- Unité - il teste des unités individuelles ou des composants du logiciel comme des méthodes ou des fonctions.
- UI - 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 une poignée d'entre eux peuvent déjà être couverts dans 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 open-source et vous promet de tester votre code de manière transparente en quelques minutes.
- Cercle 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 prendre en charge la création, le déploiement et l'automatisation de tout projet.
Si vous êtes nouveau sur Jenkins, je vous suggère de prendre ceci Cours Udemy pour apprendre CI avec Java et .NET.
Continuous Deployment
À quoi cela servira-t-il si la fonctionnalité que vous créez se trouve dans le référentiel pendant des semaines ou des mois avant d'être déployée dans l'environnement de production. Autant les équipes d'ingénierie peuvent travailler à l'intégration de petits changements dans la branche principale au fur et à mesure, elles peuvent également pousser ces changements dans l'environnement de production dès que possible.
L'objectif lors de la pratique du déploiement continu est de transmettre les modifications apportées aux utilisateurs dès que les développeurs intègrent ces modifications dans la branche principale.
Comme dans le cas de l'intégration continue, lors de l'utilisation du déploiement continu, des tests et des contrôles automatisés sont mis en place pour s'assurer que les modifications nouvellement intégrées sont vérifiées. Le déploiement se produit uniquement lorsque ces tests réussissent.
Pour qu'une équipe puisse bénéficier de la pratique du déploiement continu, elle doit disposer des éléments suivants:
- Les tests automatisés sont l'épine dorsale essentielle de toutes les pratiques d'ingénierie continue. Dans le cas d'un déploiement continu, le code à déployer doit répondre à la norme que l'équipe a mis en place pour ce qu'elle a l'intention de proposer aux utilisateurs finaux. Idéalement, si une nouvelle modification est inférieure au seuil, le test doit échouer et ne pas être intégré. Sinon, il devient intégré.
- Malgré des tests automatisés consécutifs, il est possible que certains bogues se glissent dans l'environnement de production. Pour cela, il est nécessaire que l'équipe soit en mesure d'annuler une modification qui a été effectuée - annuler un déploiement. Cela devrait ramener le code de production à ce qu'il était avant la nouvelle modification.
- Des systèmes de surveillance sont nécessaires pour suivre les changements qui ont été appliqués à l'environnement de production. C'est ainsi que l'équipe peut être en mesure de suivre les bogues que les utilisateurs rencontrent lors de l'utilisation des modifications déployées.
Les outils mentionnés pour l'intégration continue vous offrent également la fonctionnalité de mise en place d'un système de déploiement continu. Il y en a beaucoup que vous pouvez aussi lire sur.
Conclusion
La productivité d'une équipe de développement est essentielle au succès de l'entreprise. Pour garantir leur productivité, des pratiques qui les encouragent doivent être adoptées. L'intégration et le déploiement continus sont des exemples de telles pratiques.
Avec une intégration continue, les équipes peuvent pousser autant de code que possible quotidiennement. Une fois cela réalisé, il devient facile de déployer les modifications nouvellement ajoutées à l'utilisateur dès que possible. Le déploiement de ces changements permet d'obtenir des retours des utilisateurs. Au final, l'entreprise pourra innover en fonction des retours reçus, ce qui est gagnant-gagnant pour tout le monde.
Vous pouvez également apprendre à faire évoluer et optimiser CI/CD.
Si vous êtes un développeur et que vous souhaitez apprendre CI / CD, jetez un œil à ceci parcours brillant.
