Intégration continue en PHP
Les plateformes d’intégration continues sont de plus en plus courante dans le développement.
Alors à quoi ça sert et pourquoi mettre en oeuvre, voici un article pour tâcher de répondre à ces questions.
Introduction
La PIC (Plateforme d’Intégration Continue) est une clef de la vérification. L’objectif de cette plateforme est d’agréger les différents modules développés au sein d’une application homogène afin de l’analyse et de la tester.
C’est un élément fondamental dans la chaîne d’industrialisation, c’est ici que peuvent être détecté beaucoup d’anomalies avant la livraison au client.
Le coût de correction d’une anomalie étant exponentiel, plus elle est détectée tard plus sa correction coûte chère. La PIC permettant d’avoir un applicatif opérationnel en permanence il est ainsi plus facile de détecter les anomalies très tôt.
La PIC est donc la pour améliorer la qualité de votre application en anticipant les contrôles qualité (vérification) avant le déploiement mais elle permet également d’automatiser des process récurrents (packaging, tests, déploiement) afin de remplir des objectifs d’industrialisation des développements.
Mise en oeuvre
Plateforme
La mise en oeuvre d’une PIC passe par l’installation d’une application comme Jenkins ou l’utilisation d’une plateforme publique comme Travis. Il en existe d’autre bien sur. 
Scripting
Ensuite, on décrit les traitements grâce à des langages de scripting. Phing ou Ant par exemple. 
Jenkins permet d’exécuter des commandes « shell », des lignes de commandes windows, d’appeler des scripts Ant ou Phing. L’utilisation de script est préférable car utilisable sur toutes les plateformes. On peut ainsi utiliser ces scripts sur la plateforme du client (en cas de déploiement ou pour les tests unitaires automatisés par exemple). Les langages conseillés sont « Ant » et « Phing », ils sont très similaires, le premier nécessite un environnement Java (obligatoire avec Jenkins) l’autre un client PHP.
Ce langage de scripting permet d’écrire simplement du code pour automatiser l’intégration. Il ne réclame pas de grosses connaissances techniques, il est rapidement écrit, il est rapidement corrigé et il est réutilisable facilement
Dans le cas des scripts Ant, il existe 2 concepts très simples :
Les cibles :
et les tâches :
Dans le cas de Travis, c’est un fichier “travis.yml” qui permet de jouer ce rôle.
Les outils de qualimétrie
Une fois tout cela en place, il suffit de déployer les outils de qualimétrie.
Il en existe pour tous les langages, dans cet article nous nous intéresserons à ceux de PHP.
php-cs
PHPCS est aussi connu sous le nom de Checkstyle. Alias, la hantise des développeurs. Pourtant cet outil, servant à vérifier la normalisation de l’indentation du code, est très pratique.
Dans les projets, l’indentation du code est un point aidant à la de maintenabilité du code. Mais aussi, et surtout, c’est un indicateur sur la qualité du code important.
En effet, un code mal indenté est souvent une marque de manque de temps ou de rigueur. Et dans un cas comme dans l’autre, cela entraîne souvent des injections de bugs.
Et avec la PIC, on peux suivre l’évolution des erreurs (dans le cas ci-dessous, il est urgent de faire quelques chose) :
Surveiller l’indentation du code permet donc de se faire une bonne idée de la qualité du code.
php-md
PMD est une analyse permettant de mettre en évidence :
- Les bugs potentiels
- Le code à optimiser
- Les méthodes complexes
- Les paramètres, méthodes et propriétés Inutiles
PMD est vraiment un indicateur qui permet de mettre en évidence de potentielles problématiques importantes dans le code. Des instances inutiles qui ralentissent l’exécution aux paramètres que l’on oubli d’utiliser, chaque point peut avoir une importance insoupçonnée.
php-cpd
CPD permet de remonter la duplication de code.
L’un des enjeux de la POO est de rationaliser le code en factorisant. PMD permet d’identifier des brides de code qui pourrait être factorisées car similaire.
php-doc
PHPDoc n’est pas vraiment un indicateur orienté vers la qualité. PHPDoc génère une documentation du code en fonction des commentaires des classes, méthodes etc… Dans le cadre du développement d’un plugin/module qui va être distribué, cette documentation doit être au top.
Mais en fait, comme pour “checkstyle”, la phpDoc est un indicateur fort de la rigueur du développement.
Une phpDoc à jour et exhaustive démontre un réel suivi du code par l’équipe de développement.
php-unit
Et enfin, phpUnit.
Les TUA sont la raisons même de l’existence de la PIC. A chaque changement de code, les tests sont exécutés. Cela permet d’identifier les bugs et régressions immédiatement et ainsi de les corriger sans avoir des impacts négatifs. De plus, un indicateur sur le taux de couverture du code par les tests permet de savoir si rien n’a été oublié durant la rédaction de ces tests.
Résultat des cas de tests
Autre
On peux également ajouter bien des outils qui ne sont pas forcément dédiés à PHP ou à la qualimétrie : les test automatisés tel que Cucumber, CasperJS, Selenium par exemple. Mais aussi l’automatisation du déploiement, du packaging etc… La PIC est là pour vous aider, il faut lui faire faire un maximum de chose.
Si ça n’a pas de plus value et que c’est répétitive, alors la PIC peux le faire 🙂
Conclusion
Jenkins (et la PIC en générale) est un moyen simple et efficace pour fournir des indicateurs fiable et ainsi vérifier la qualité de sa production.
De plus la polyvalence d’un système comme Jenkins permet d’automatiser des tâches souvent source d’erreur.
Alors fiabiliser vos dév, et pensez aux PIC.
Exemple d’un tableau de bord pour un bundle Symfony2.