L'intégration continue est devenu un passage quasi obligé dans la plupart des projets. Lancer automatiquement une série de tests, générer des rapports, avoir une vision quasi instantanée sur la qualité du code et les mesures correctives à y apporter, générer la documentation de l'application puis, si tout va bien, lancer un déploiement automatisé sur un serveur de dev, staging ou en prod, il faut avouer que c'est terriblement sexy pour un développeur.
Jenkins, TeamCity, Travis CI, Circle CI, Strider CD, PHP CI, il existe un nombre important de solutions qui permettent toutes ou partie de ces features.
Comme souvent avant de faire un choix, je me documente à fond sur le sujet, je teste, je bidouille, je note mes conclusions, les pours, les contres, je cherche à savoir si toute la team TPZ pourra utiliser le produit, si je vais devoir y passer des heures dès qu'un soucis se présentera à cause d'une communauté ou d'une documentation inexistante ou insuffisante...
Aujourd'hui je vous propose un petit état des lieux sur les services proposés, on reviendra par la suite sur chacune des solutions avec un cas pratique, peut être la v2 de notre application qui tue la mort :
snap0r 2, le retour de l'application qui découpe des mémés en morceau de 50. Mais ce n'est pas le sujet du jour.
Deux univers, plein de contraintes
A ma droite, les produits standalone, que l'on peut installer sous Windows et *nix, souvent au prix d'un peu d'huile de coude et de configuration.
Jenkins et TeamCity en font partie. Les avantages de ces solutions sont multiples, notamment en ce qui concerne la protection de votre code (après tout, on ne sait jamais), mais aussi pour leur potentiel en terme d'évolutivité, qui dépend de leur communauté et des plugins qu'ils proposent.
A ma gauche, les services paas, hébergés par l'éditeur, soumis aux évolutions qu'ils veulent bien leur donner et dont le coût mensuel peut être important, mais qui en contrepartie retirent une grosse partie de complexité liée à l'installation, à la maintenance, et aux besoins d'infrastructure qui peuvent devenir importants, un TeamCity et un Jenkins pouvant devenir très gourmands en ressources.
Travis CI (sans doute le plus connu) et Circle CI sont dans cette catégorie
Lourds....
On vient de l'évoquer, on a donc deux catégories, poids lourd versus poids léger. Pour vous donner un exemple, voici les préconisations de JetBrains en ce qui concerne les besoins en ressources systèmes de TeamCity, ça pique un peu :
Based on our experience, a modest hardware like 3.2 dual core CPU, 3.2Gb memory under Windows, 1Gb network adapter can provide acceptable performance
Jenkins est un peu moins gourmand mais nécessite lui aussi un serveur qui tabasse.
L'autre soucis, c'est l'infogérance qui doit être mise en place sur ces serveurs. Si vous avez les compétences pour gérer votre serveur vous même, très bien, si vous avez le temps, c'est encore mieux, mais si vous n'avez ni le temps ni les compétences en internet pour gérer tout ça, vous aurez sans doute besoin de quelqu'un pour gérer votre installation et le serveur.
En contrepartie, une installation que vous maitrisez vous offre multitude de possibilités et d'évolutivité. Vous pouvez travailler sur la génération de rapports après un build et vous les envoyer par mail ou par sms si ça vous chante, lancer plusieurs déploiements en SSH sur 15 000 serveurs, lancer vos tests BDD (behavior-driven development) avec Selenium... bref, vous pouvez automatiser à fond toute ou partie de vos process, et en mettre de nouveaux en place dans un délai relativement court.
Je vous recommande chaudement deux tutoriels sur l'installation de Jenkins et sa configuration pour un projet PHP, par Pascal Martin. Une mine d'or qui devrait vous permettre de vous en sortir avec les honneurs même sur les articles datent un peu :
... versus trop léger
Les plate-forme en tant que service (Paas) offrent quant à elles pas mal d'avantage sur l'infrastructure, puisque vous n'hébergez rien, vous n'avez pas besoin de gérer le serveur ou ce qui est installé dessus, ce n'est pas votre problème.
Travis CI, par exemple, offre un excellent compromis à un Jenkins, puisque vous pouvez quasiment tout faire via un fichier YML à la racine de votre repo.
Un exemple simple :
- Cloner Laravel et ses dépendances
- Lire votre fichier phpunit.xml et lancer vos tests unitaires, générer un rapport
- Deployer le projet en cas de succès sur votre serveur de développement
Un excellent tutoriel vidéo est d'ailleurs disponible chez Grafikart à ce sujet :
Le gros inconvénient en général, c'est le prix. Voilà la grille tarifaire de Travis CI :
Pas vraiment donné, mais à mettre en correspondance face au coût d'une infogérance avec garantie de temps de rétablissement de 4 heures.
Travis CI est toutefois un cas un peu particulier, la plupart des services (Circle CI, PHP CI...) manquent de features. PHP CI ne permet pas, par exemple, de déployer après un build, Circle CI ne propose pas
Php CodeSniffer, bref, il faudra faire avec (ou sans), et vous n'aurez en général pas autant de liberté qu'avec une installation qui vous appartient à tous les niveaux.
Du temps à perdre pour en gagner ensuite
C'est certain, si vous décidez d'installer votre premier serveur Jenkins, vous allez y passer quelques heures (en fait, un ou deux jours pour l'installation de base et quelques plugins, et plusieurs heures ensuite pour bien configurer les rapports et affiner l'installation).
Cela dit, le gain de temps se fait sentir quasiment immédiatement après : vos tests unitaires sont lancés automatiquement, vous obtenez une vision claire de l'évolution du code, identifiez par exemple le code de mauvaise qualité (souvent lié à un copier coller de code trouvé sur le web), et évitez les effets de bord sur vos développements.
Lorsque l'on travaille seul sur le code d'un projet, on peut s'en passer et lancer ses tests unitaires localement, mais dès que l'on travaille à plusieurs sur un projet, c'est vraiment un fonctionnement idéal pour éviter de tuer votre collègue qui vous regarde avec ses yeux de merlan fris à l'autre bout de l'open space.
Je parle de configurer Jenkins, mais c'est au final valable aussi pour Travis CI et compagnie, dans la mesure où vous allez devoir écrire votre fichier de configuration du build, peu importe la plate-forme que vous utilisez.
A quel prix ?
TeamCity est gratuit dans une version limité en terme de nombre de builds (3), Jenkins est open source, mais pour l'un comme pour l'autre, vous aurez des coûts en infrastructure, en temps et / ou en infogérance.
Pour les plate-forme en tant que service, les coûts sont affichés, il suffit de consulter le pricing pour savoir à peu près à quoi vous attendre.
Mais en dehors du coût d'installation / abonnement de ses solutions, ce qui nous intéresse ici est plutôt lié à la prise en main, la mise en place des process et - le plus important, la formation / transmission de compétences à toutes les équipes d'une agence.
Pour que la mise en place d'une intégration continue soit intéressante, il faut que chacun s'intéresse aux rapports produits pendant un build. Ce n'est pas uniquement aux développeurs de s'intéresser aux logs, mais également aux chefs de projet fonctionnel et technique, aux testeurs et parfois même au client pour un peu qu'il soit techniquement intégré au projet.
Dans l'idéal, il faut un référent, quelqu'un sur qui s'appuyer en cas de besoin et qui répondra aux questions, ajoutera des fonctionnalités, ajoutera des étapes au build et documentera le tout.
Tout ça, ça a un coût, difficile à estimer d'autant qu'il dépend des projets et des technos utilisées, et qu'il s'agit plus d'un coût relatif au temps qu'un développeur ne passera pas à développer réellement sur un projet client.
Quels gains ?
Ils sont potentiellement énormes !
Si on se place d'un autre point de vue, mettre en place des process pour garantir la qualité du code livré, et le mettre en avant auprès des clients, peut contre balancer l'investissement temps en démontrant qu'une agence ne se contente pas de livrer un code un peu obscur, mais qu'il y a une réelle démarche qualité derrière son organisation.
On peut même imaginer que l'intégration continue entre dans la démarche de
norme qualité ISO 9126. Un argument de poids lorsque vous négociez avec un client grand compte par exemple.
Quelques liens
Pas vraiment donné, mais à mettre en correspondance face au coût d'une infogérance avec garantie de temps de rétablissement de 4 heures.
Travis CI est toutefois un cas un peu particulier, la plupart des services (Circle CI, PHP CI...) manquent de features. PHP CI ne permet pas, par exemple, de déployer après un build, Circle CI ne propose pas Php CodeSniffer, bref, il faudra faire avec (ou sans), et vous n'aurez en général pas autant de liberté qu'avec une installation qui vous appartient à tous les niveaux.
Du temps à perdre pour en gagner ensuite
C'est certain, si vous décidez d'installer votre premier serveur Jenkins, vous allez y passer quelques heures (en fait, un ou deux jours pour l'installation de base et quelques plugins, et plusieurs heures ensuite pour bien configurer les rapports et affiner l'installation).
Cela dit, le gain de temps se fait sentir quasiment immédiatement après : vos tests unitaires sont lancés automatiquement, vous obtenez une vision claire de l'évolution du code, identifiez par exemple le code de mauvaise qualité (souvent lié à un copier coller de code trouvé sur le web), et évitez les effets de bord sur vos développements.
Lorsque l'on travaille seul sur le code d'un projet, on peut s'en passer et lancer ses tests unitaires localement, mais dès que l'on travaille à plusieurs sur un projet, c'est vraiment un fonctionnement idéal pour éviter de tuer votre collègue qui vous regarde avec ses yeux de merlan fris à l'autre bout de l'open space.
Je parle de configurer Jenkins, mais c'est au final valable aussi pour Travis CI et compagnie, dans la mesure où vous allez devoir écrire votre fichier de configuration du build, peu importe la plate-forme que vous utilisez.
A quel prix ?
TeamCity est gratuit dans une version limité en terme de nombre de builds (3), Jenkins est open source, mais pour l'un comme pour l'autre, vous aurez des coûts en infrastructure, en temps et / ou en infogérance.
Pour les plate-forme en tant que service, les coûts sont affichés, il suffit de consulter le pricing pour savoir à peu près à quoi vous attendre.
Mais en dehors du coût d'installation / abonnement de ses solutions, ce qui nous intéresse ici est plutôt lié à la prise en main, la mise en place des process et - le plus important, la formation / transmission de compétences à toutes les équipes d'une agence.
Pour que la mise en place d'une intégration continue soit intéressante, il faut que chacun s'intéresse aux rapports produits pendant un build. Ce n'est pas uniquement aux développeurs de s'intéresser aux logs, mais également aux chefs de projet fonctionnel et technique, aux testeurs et parfois même au client pour un peu qu'il soit techniquement intégré au projet.
Dans l'idéal, il faut un référent, quelqu'un sur qui s'appuyer en cas de besoin et qui répondra aux questions, ajoutera des fonctionnalités, ajoutera des étapes au build et documentera le tout.
Tout ça, ça a un coût, difficile à estimer d'autant qu'il dépend des projets et des technos utilisées, et qu'il s'agit plus d'un coût relatif au temps qu'un développeur ne passera pas à développer réellement sur un projet client.
Quels gains ?
Ils sont potentiellement énormes !
Si on se place d'un autre point de vue, mettre en place des process pour garantir la qualité du code livré, et le mettre en avant auprès des clients, peut contre balancer l'investissement temps en démontrant qu'une agence ne se contente pas de livrer un code un peu obscur, mais qu'il y a une réelle démarche qualité derrière son organisation.
On peut même imaginer que l'intégration continue entre dans la démarche de norme qualité ISO 9126. Un argument de poids lorsque vous négociez avec un client grand compte par exemple.
Quelques liens
