• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 12/05/2022

Comprenez la démarche d'intégration continue

Avec un test, vous cherchez à faire en sorte de valider automatiquement le fonctionnement de votre code et le fonctionnement de votre application en général.

Jusqu'ici, je vous ai montré comment lancer une série de tests à la main. Cela reste nécessaire quoiqu'il arrive ; cependant il existe aussi des solutions pour faire en sorte que les tests soient lancés de façon systématique avant un événement important. Cet événement peut être la fusion d'une branche Git sur laquelle vous avez travaillé dans la branche master (qui doit toujours être stable), ou encore avant un déploiement en (pré)production.

Suivez le cycle d'intégration continue

L'intégration continue passe par un outil (un logiciel). Cet outil est chargé de lancer un ou plusieurs logiciels qui sont eux-mêmes en charge de valider un aspect de l'application (tests unitaires, tests fonctionnels, tests d'intégration, tests de performances… et bien d'autres).

Vous pouvez voir l'intégration continue comme une tour de contrôle, avec plusieurs opérateurs chargés de lancer successivement les différents outils permettant de valider le fonctionnement global de l'application.

L'outil d'intégration continue permet de lancer l'ensemble des autres outils le plus rapidement possible, afin de valider un build avant d'entamer un déploiement ou une fusion de branche, par exemple.

Qu'est-ce qu'un build ?

C'est tout simplement le fait de lancer l'ensemble des logiciels permettant de valider un changement dans l'application, pour en avoir une version exécutable. Voici comment un build intervient :

Exemple de cycle de développement avec un outil d'intégration continue : Le développeur effectue des changements dans l’application et GitHub en notifie le serveur d’intégration continue. Puis un build est lancé.
Cycle de prise en compte des modifications apportées dans le code

Le cycle tel qu'il est montré ci-dessus peut intervenir à chaque modification de code :

  1. Le développeur commit et push des changements dans l’application pour une nouvelle fonctionnalité.

  2. GitHub notifie le serveur d’intégration continue que de nouvelles modifications ont été apportées au code.

  3. Un build est lancé en faisant appel aux différents logiciels permettant la validation.

  4. Le serveur d’intégration continue notifie GitHub si le build s’est bien passé.

  5. Le développeur est en mesure de voir si les changements apportent une régression, ou si tout fonctionne normalement.

Le tout est de faire en sorte que le code soit le plus souvent possible conforme aux exigences des logiciels utilisés pour valider votre application.

Utilisez des outils d'intégration continue

Sur le schéma précédent, on peut voir des logiciels PHPUnit que vous connaissez déjà, Behat et JMeter.

  • Behat est un logiciel permettant de tester le comportement de son application.

  • JMeter est un outil permettant de simuler une montée en charge.

En fonction de ce qui est nécessaire de valider, et des intégrations possibles avec l'outil d'intégration continue, il est possible d'ajouter de nombreux autres outils de validation.

Pour ce cours, nous nous contenterons de valider notre application grâce au lancement de nos tests PHPUnit.

Il existe bon nombre d'outils d'intégration continue. En voici une liste (non exhaustive) :

Comment choisir le bon outil d'intégration continue ?

En général, les entreprises basent leur choix sur le prix que coûtent les outils, ainsi que sur leur popularité. Il est inutile de chercher à vous former sur tous les outils ! Le tout est d'en comprendre le fonctionnement général, vous serez ensuite en mesure de vous baser sur la documentation de chacun des outils pour les mettre en place.

En résumé

  • Il existe de nombreux logiciels d’intégration continue (CI en anglais, “Continuous Integration”). 

  • L’intégration continue sert à automatiser la validation du code en vue d’une opération qui nécessite un code sans erreurs. 

  • Le build est créé avec le nouveau commit qui a passé les tests (build : une version exécutable de l’application).

Afin de vous en montrer au moins un, je vous propose de voir comment utiliser TravisCI. Rendez-vous au prochain chapitre pour le mettre en place ensemble !

Exemple de certificat de réussite
Exemple de certificat de réussite