Comprendre l’intégration continue et le déploiement continu

Entendu CI / CD mais pas sûr de ce que c’est?


Idéalement, les ingénieurs logiciels sont embauchés pour écrire du code qui doit être expédié dans 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 logiciels consiste à travailler dans des succursales et à créer une demande d’extraction qui met à jour la branche principale avec la nouvelle mise à jour effectuée. Nous avons adopté la pratique d’écrire des tests comme moyen de s’assurer 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 demande d’extraction avant d’avoir complètement terminé avec la fonctionnalité. Ce qui se passe quand ils sont prêts, c’est que;

  • Ils passent beaucoup de temps à essayer de mettre à jour leur base de code avec les changements qui se sont produits 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 ensuite ceux qui se retirent de 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 volontiers passer sa journée de travail comme ça.

Quelle est la solution?

Intégration continue

https://www.youtube.com/watch?v=HnWuIjUw_Q8

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 apporté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 localement une branche dans laquelle ils écrivent du code pour l’implémentation de certaines fonctionnalités. Au lieu d’envoyer des demandes de tirage lorsqu’elles sont entièrement terminées avec la fonctionnalité, ils choisissent d’envoyer des demandes de tirage car ils apportent de petites modifications. 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 fonctionnalité 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 il travaille) et crée une demande d’extraction pour fusionner avec le code.

Avant que cette nouvelle modification soit intégrée, une série de tests doit être exécutée.

Les équipes de génie logiciel utilisent des outils comme Travis CI pour créer ces processus et tests d’intégration. Avec des outils comme ceux-ci, les tests sont automatisés, de sorte qu’il s’exécute dès qu’une demande de tirage 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 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’expédier un bug 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 à envoyer fréquemment du code à la branche principale. Cela sera inefficace si les autres membres de l’équipe ne se retirent 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 ceux qui peuvent être implémentés dans le processus:

  • Intégration – il combine des unités individuelles du logiciel et les teste en 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 la conformité du logiciel 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 faire tester votre code de manière transparente en quelques minutes.
  • Circle CI – vous offre puissance, flexibilité et contrôle pour automatiser votre pipeline du contrôle au déploiement.
  • Jenkins – fournit des centaines de plugins pour prendre en charge la construction, le déploiement et l’automatisation de tout projet.

Si vous êtes nouveau à Jenkins, je vous suggère de prendre ceci Cours Udemy apprendre CI avec Java et .NET.

Déploiement continu

À 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 que les équipes d’ingénierie peuvent travailler à intégrer 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 faire en sorte que les modifications soient 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 garantir que les modifications nouvellement intégrées sont vérifiées. Le déploiement ne se produit que 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 mise en place pour ce qu’elle entend transmettre aux utilisateurs finaux. Idéalement, si un nouveau changement est inférieur 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 un changement qui a été effectué – 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é poussés vers l’environnement de production. C’est ainsi que l’équipe peut suivre les bogues rencontrés par les utilisateurs lorsqu’ils utilisent les modifications déployées.

Les outils mentionnés pour l’intégration continue vous fournissent également la fonctionnalité pour configurer un système de déploiement continu. Il y en a beaucoup que vous pouvez également lire.

Conclusion

La productivité d’une équipe de développement est essentielle au succès de l’entreprise. Pour garantir leur productivité, des pratiques encourageant cela 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 cet objectif atteint, il devient facile de déployer les modifications récemment ajoutées pour l’utilisateur dès que possible. Le déploiement de ces modifications permet d’obtenir des retours des utilisateurs. En fin de compte, l’entreprise sera en mesure d’innover en fonction des commentaires reçus, ce qui est gagnant-gagnant pour tout le monde.

Si vous êtes un développeur et que vous souhaitez apprendre le CI / CD, consultez ce cours brillant.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map