Automatiser sa production avec GitLab – partie 3

Contrôle Qualité GitLab

Automatiser sa production

Découvrez dans cet article comment automatiser tout le processus de déploiement et de contrôle qualité d'un projet, permettant ainsi à la fois d'améliorer la qualité du code et de gagner du temps.

Préambule

Avant de commencer cet article, je tiens d’abord à nuancer mes propos. En effet, bien que le titre soit « L’architecture parfaite », je ne vais pas vous présenter la solution parfaite, capable de résoudre tous vos problèmes ni même de faire votre café.
Je vais plutôt vous présenter l’architecture que nous utilisons en interne pour notre système d’intégration continue, permettant de transformer chaque « commit » en une nouvelle installation propre et visible pour le client.
Cela permet ainsi de surveiller l’évolution des projets en temps réel, et d’échanger avec les clients sur telle ou telle fonctionnalité dès qu’elle est visible plutôt que d’attendre la prochaine release qui ne viendra que dans 3 mois. Ce n’est peut-être pas si loin de la perfection, non ?

Comme il y a beaucoup à dire sur ce sujet, il a été divisé en 3 parties.

  1. Tout d’abord la première que vous pouvez retrouver ici, décrit tout ce qui se passe à partir du moment où nous écrivons notre code jusqu’au moment où il est réceptionné et stocké sur notre système.
  2. La seconde partie, que vous pouvez consulter sur ce lien, se concentre presque exclusivement sur la puissance de GitLab-CI et des fichiers « .gitlab-ci.yml ». C’est là que l’on orchestre le tour de magie.
  3. Enfin la dernière partie, actuellement sous vos yeux, concerne le déploiement, les tests et la mise en ligne.

Enfin, cet article a été rédigé pour être compréhensible par tous et non uniquement par des développeurs. C’est pour cela que j’ai volontairement pris des raccourcis ou passé certaines informations sous silence.
Enfin, pour les développeurs qui souhaiteraient comprendre mieux le sujet, vous pouvez retrouver un diagramme de ce workflow, réalisé pour l’occasion.

Maintenant que les présentations sont faites, terminons ce sujet !


Chapitre 3 : Tests & Déploiement

Comme vous l’avez normalement vu dans le précédent chapitre, notre architecture repose entièrement sur le fichier « .gitlab-ci.yml ». A l’inverse, nous allons voir plus en profondeur les tests, aussi bien pour les fonctionnalités que pour la qualité.

Tout d’abord les tests pour les fonctionnalités.

Tests unitaires & fonctionnels

Pour cela, nous allons utiliser PHPUnit qui se chargera de rechercher tous les tests présents dans un dossier et de les jouer un à un. Nous allons donc rédiger un fichier XML qui indique à PHPUnit le dossier où se trouvent les tests, les fonctionnalités à tester, et petite particularité, lui demande aussi de noter à quel niveau nos tests couvrent le projet.

<?xml version="1.0" encoding="UTF-8"?>
<phpunit>
  <testsuites>
    <testsuite name="Project Test Suite">
      <directory>tests</directory>
    </testsuite>
  </testsuites>
 
  <filter>
    <whitelist>
      <directory>src</directory>
    </whitelist>
  </filter>
 
  <logging>
    <log type="coverage-clover" target="test-result/coverage.xml"/>
    <log type="coverage-html" target="test-result/coverage-html"/>
    <log type="junit" target="test-result/junit.xml" logIncompleteSkipped="false"/>
  </logging>
</phpunit>

Nous avons 3 niveaux où nous notons le résultat des tests. D’abord dans un fichier « test-result/coverage.xml » qui contiendra un fichier que SonarQube lira de son côté. Ensuite un dossier « test-result/coverage-html » qui présente la couverture des tests de manière visuelle et facile à comprendre pour un néophyte. Et enfin un fichier « test-result/junit.xml » qui contient le résultat des tests, aussi pour SonarQube. Il s’agit simplement de lister ceux qui ont réussi, et ceux qui ont échoué.

Enfin, il ne reste plus qu’à lancer les tests, ce que l’on devrait normalement faire avant chaque commit et chose que notre serveur worker effectue systématiquement et, sans exception.

A la fin, nous avons un résultat comme celui-ci :

PHPUnit 6.2.2 by Sebastian Bergmann and contributors.

................................................................. 65 / 98 ( 66%)
................................. 98 / 98 (100%)

Time: 12.41 seconds, Memory: 28.00MB

OK (98 tests, 113 assertions)

Generating code coverage report in Clover XML format ... done

Generating code coverage report in HTML format ... done

Tant que nous avons des petits points, c’est que tout fonctionne. En revanche, si notre dernier développement a cassé quelque chose, alors nous aurons soit un « F », soit un « E » à la place d’un des points, selon si un test est faux ou si ce dernier a « crashé ».

Tests de qualité

Ensuite, si tous les tous les tests ont réussi (les 98 tests dans notre cas), alors nous envoyons le code à notre serveur SonarQube. Ce dernier va vérifier que le contenu des fichiers de code de notre projet est correct ou pourrait être amélioré.

Une fois que ce dernier a reçu tous nos fichiers, ceux-ci sont analysés en détail, passant à travers plusieurs centaines/milliers de règles selon le langage du fichier, avant de générer un rapport sur l’état du projet.

Le rapport final ressemble à ceci :

Analyse GitLab

 

On peut y voir le nombre de bugs ou de vulnérabilités détectées, à quel point le code semble compliqué à maintenir, quel pourcentage du projet est couvert par les tests, ou s’il y a du code qui a été dupliqué et qui mériterait d’être regroupé à un seul endroit.

D’ailleurs, on peut voir que le projet que j’ai choisi pour cette capture d’écran est un tout petit projet étant donné qu’il est classé « S » (small) avec seulement 2’300 lignes de code PHP.

Ensuite, lorsqu’il y a quelque chose à signaler, SonarQube nous l’informe dans l’onglet « Issues » et les présente dans une liste de blocs tel que celui-ci :

Bug Git Lab

 

De plus, chaque « bug » listé contient des explications génériques sur la cause du problème ainsi que comment le résoudre :

Explications GitLab

 

Après il ne faut pas non plus suivre aveuglement chaque indication que remonte SonarQube car il y aura certains éléments qui seront volontairement de telle ou telle manière et SonarQube parcourant simplement le code tel un robot, il n’aura pas l’historique du projet, mais au final, cela fait un bon compagnon de développement qui vous rappellera toujours à l’ordre si besoin.

Conclusion

Si vous êtes arrivés jusqu’ici sans décrocher, toutes mes félicitations, vous avez toutes les clés en main pour automatiser vous aussi votre workflow. Nous avons vu comment se déroulaient les développements, puis nous avons parcouru le fichier de configuration de GitLab permettant de définir toutes les tâches à effectuer en fonction de la branche sur laquelle est commité le code, et enfin nous avons découvert comment nous utilisons les tests unitaires ainsi que SonarQube pour assurer la qualité du code que l’on produit, le tout de manière automatisé et à chaque commit.

Ainsi les clients disposent automatiquement de la dernière version stable et à jour de leur site lors de la phase de développement.

Il ne tient qu’à vous d’adapter ces articles à votre manière de faire et profiter vous aussi des joies du déploiement continue.

Enfin, c’est avec une petite anecdote que conclurais ces 3 articles : Depuis que nous sommes passés à cette architecture, j’ai personnellement augmenté le nombre de nos tests unitaires d’au moins 30% je dirais, diminués le nombre de régressions constatées par le client de 20% à 25%, amélioré la qualité de mon code en remplaçant mes vieilles habitudes par d’autres et amélioré la performance des sites sur lesquels je travaille d’environ 10% grâce à certaines optimisations proposées par SonarQube.

La mise en place de ce workflow fut longue et laborieuse, mais au final, ce temps perdu est déjà remboursé par le nombre de correctifs à développer qui ont diminué de manière drastique.

Michael Barbey
Publié le par
Michael Barbey
0 Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *