Pascal MARTIN (n+1).zéro

Statistiques de versions de PHP - avril 2012

Pascal MARTIN — mer., 02 mai 2012 07:30:00 +0200

En septembre 2011, et en janvier cette année, j’ai eu l’occasion de publier deux articles présentant quelques statistiques d’utilisation des différentes versions de PHP.

Depuis, le dernier article de cette série, environ trois mois se sont écoulés, PHP 5.4 est sorti en sa première version stable (le 1er mars), et la version 5.4.1 est actuellement en RC¹. Le moment semble donc venu de publier une mise à jour de ces statistiques.

Les données présentées dans cet article ont été collectées le week-end du 21 avril 2012.

Sommaire :

Quelques mots sur la méthode

Pour faire simple, j’ai récupéré une liste de plus de 8.3 millions de noms de domaines, issus principalement :

Du top 1 million d’Alexa (chargé plusieurs fois à quelques semaines/mois d’écart, ce qui donne plus de 1 million de noms de domaines),
Des liens externes de wikipedia de plusieurs langues (environ 3 millions de noms de domaines),
De l’export mis à disposition par l’Export Open Directory (environ 2 millions de noms de domaines),
Et de quelques résultats de recherche google (quelques milliers de noms de domaines).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis généralement² basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom du logiciel ayant servir à générer la page, ainsi que sa version.
Et dans le cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Pour rappel, et en ne prenant que quelques exemples relativement typiques, les en-têtes HTTP renvoyées par le serveur, dans le cas de pages générées par PHP et sur un serveur exposant la version de PHP utilisée, ressemblent souvent à quelque chose de ce type (pour www.php.net) :

Server: Apache/1.3.41 (Unix) PHP/5.2.17
X-Powered-By: PHP/5.2.17

ou (pour www.afup.org) :

Server: Apache
X-Powered-By: PHP/5.2.14-0.dotdeb.0

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…

Quelques chiffres

Réponses PHP

Sur les 7.9 millions de requêtes HTTP effectuées sur les noms de domaines que j’ai testé, environ 26% des réponses ont été identifiées comme générées par du PHP.
Plus précisément, j’ai identifié 2,063,505 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus bas devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Serveurs Web

Cela dit, avant d’entrer dans les détais des versions de PHP, voici la liste des Serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

Apache : 4,496,236 — 67.16%
IIS : 1,227,240 — 18.33%
nginx : 414,578 — 6.19%
Autres : 268,720 — 4.01%
GSE : 161,937 — 2.42%
YTS : 49,382 — 0.74%
LiteSpeed : 48,719 — 0.73%
Oversee Turing v1.0.0 : 28,359 — 0.42%

Ou, sous forme d’un graphe :

On continuera de noter l’importance d’Apache, qui, toutes versions confondues, est toujours en tête, loin devant les autres.
nginx, quant à lui, confirme sa troisième place, en progressant même d’un demi-point en trois mois.

Versions majeures de PHP

Commençons par les versions majeures de PHP, en prenant en compte les résultats qui ont été identifiés comme correspondant à une version supérieure ou égale à 3, et inférieure ou égale à 6³.

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

PHP 3 : 784 — 0.04%
PHP 4 : 248,241 — 12.03%
PHP 5 : 1,814,376 — 87.93%
PHP 6 : 31 — 0.00%

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’oeil quelle est la version majeure de PHP la plus répandue, cela donne :

On notera :

Que, fort heureusement, PHP 5 est la version majeure la plus répandue,
Mais que, en 2012, on a encore quelques centaines de sites, sur 7.9 millions, qui tournent encore sur du PHP 3,
Mais aussi que PHP 4 (avec ses 12%) est encore beaucoup trop répandue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
Et enfin que, plus d’un an après la mise à mort de la branche PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée), on rencontre (encore) des sites qui utilisent PHP 6 en production⁴ ???

Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

PHP 3.0 : 782 — 0.04%
PHP 4.0 : 1,808 — 0.09%
PHP 4.1 : 4,292 — 0.21%
PHP 4.2 : 3,842 — 0.19%
PHP 4.3 : 55,257 — 2.68%
PHP 4.4 : 183,039 — 8.87%
PHP 5.0 : 7,286 — 0.35%
PHP 5.1 : 84,938 — 4.12%
PHP 5.2 : 1,189,049 — 57.63%
PHP 5.3 : 530,983 — 25.73%
PHP 5.4 : 2,111 — 0.10%
PHP 6.0 : 29 — 0.00%

Et sous forme graphique :

Pour résumer :

PHP 5.2, qui a atteint sa fin de vie en décembre 2010, il y a déjà plus d’un an, est toujours la version de PHP qui semble aujourd’hui la plus utilisée / répandue,
PHP 5.3, stable depuis juin 2009, soit bientôt trois ans, n’arrive qu’en seconde place — et loin derrière PHP 5.2,
- Mais notons tout de même que PHP 5.3 a gagné plus de 7 points depuis janvier, ce qui lui permet, pour la première fois, d’atteindre les 25% !
PHP 5.4, sortie en sa première version stable il y a moins de deux mois, atteint timidement les 0.10%.

Considérant que PHP 5.2 est encore la version de PHP utilisée sur plus de la moitié des serveurs pour lesquels j’ai obtenu des données, et que PHP 5.3, au bout de presque 3 ans, atteint tout juste les 25%, je suis curieux de voir quelle sera l’évolution de PHP 5.4 sur les prochains mois !

Versions releases de PHP

Et enfin, si on descend au niveau des versions release de PHP 5.x⁵, en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes :

Pour PHP 5.0 :
- 5.0.1 : 118 — 0.01%
- 5.0.2 : 270 — 0.01%
- 5.0.3 : 691 — 0.04%
- 5.0.4 : 5,203 — 0.29%
- 5.0.5 : 950 — 0.05%
Pour PHP 5.1 :
- 5.1.1 : 335 — 0.02%
- 5.1.2 : 6,292 — 0.35%
- 5.1.3 : 1,539 — 0.08%
- 5.1.4 : 2,337 — 0.13%
- 5.1.5 : 255 — 0.01%
- 5.1.6 : 74,160 — 4.09%
Pour PHP 5.2 :
- 5.2.0 : 23,240 — 1.28%
- 5.2.1 : 5,765 — 0.32%
- 5.2.2 : 1,872 — 0.10%
- 5.2.3 : 8,502 — 0.47%
- 5.2.4 : 42,825 — 2.36%
- 5.2.5 : 31,155 — 1.72%
- 5.2.6 : 162,833 — 8.98%
- 5.2.7 : 159 — 0.01%
- 5.2.8 : 23,952 — 1.32%
- 5.2.9 : 78,047 — 4.30%
- 5.2.10 : 42,968 — 2.37%
- 5.2.11 : 29,425 — 1.62%
- 5.2.12 : 37,048 — 2.04%
- 5.2.13 : 57,964 — 3.20%
- 5.2.14 : 57,252 — 3.16%
- 5.2.15 : 4,674 — 0.26%
- 5.2.16 : 24,621 — 1.36%
- 5.2.17 : 556,636 — 30.68%
Pour PHP 5.3 :
- 5.3.0 : 3,022 — 0.17%
- 5.3.1 : 4,288 — 0.24%
- 5.3.2 : 54,067 — 2.98%
- 5.3.3 : 116,147 — 6.40%
- 5.3.4 : 5,552 — 0.31%
- 5.3.5 : 49,736 — 2.74%
- 5.3.6 : 44,931 — 2.48%
- 5.3.7 : 871 — 0.05%
- 5.3.8 : 74,447 — 4.10%
- 5.3.9 : 14,311 — 0.79%
- 5.3.10 : 163,515 — 9.01%
Pour PHP 5.4 :
- 5.4.0 : 1,991 — 0.11%
- 5.4.1 : 119 — 0.01%

Et sous forme graphique :

Pour résumer :

Une quantité non-négligeable de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise.
Beaucoup de PHP 5.2.6 (publiée en Mai 2008) ; la version fournie par défaut sous Debian Lenny, par exemple.
La version de PHP la plus répandue est PHP 5.2.17 (publiée en Janvier 2011) ; ça reste du 5.2, qui a atteint sa fin de vie, mais positivons, en se disant que c’est la dernière version, la plus à jour…
Et enfin, plusieurs sous-versions de PHP 5.3.x, dont en particulier :
- PHP 5.3.3 — version par défaut sous Debian Squeeze, notamment,
- Et PHP 5.3.10 — dernière version stable de PHP 5.3.x ; étant la plus répandue des versions release de PHP 5.3.x.
Par pure curiosité, notons que PHP 5.4.1 est la version utilisée sur une centaine de serveurs, parmis les quelques millions de serveurs interrogés, alors qu’au moment où ces données ont été collectées, cette version n’avait été publiée qu’en RC (PHP 5.4.1 est sortie en version stable avant la publication de cet article, mais après la collecte des données qu’il présente).

Evolution

Je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présentés ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 2011⁶ :

J’ai essayé de mettre en évidence les versions les plus à même de nous concerner en ce moment (à savoir, PHP 5.2, 5.3, et 5.4), ainsi que, dans une moindre mesure les deux autres versions les plus utilisées (autrement dit, PHP 4.4 et 5.1).

Le point clairement mis en évidence ici est que PHP 5.2 laisse petit à petit sa place à PHP 5.3 — ce qui est une très bonne chose, même s’il serait appréciable que la migration se fasse un peu plus rapidement, considérant les "nouveautés" qu’apporte PHP 5.3, le fait que PHP 5.2 ait atteint sa fin de vie, ou même la sortie récente de PHP 5.4.

PHP 5.4.1 a été publiée le 26 avril 2012, soit avant cet article, mais quelques jours après la collecte des données présentées ici. ↩
Pour certains types de serveurs ou de logiciels, j’ai mis en place un bout de code qui va chercher les informations de version dans d’autres en-têtes que X-Powered-By. Par exemple, pour les sites développés en ASP.NET, les informations de version figurent généralement dans une en-tête nommée X-AspNet-Version. ↩
Pour ne pas prendre en compte les quelques résultats abherrant qu’on aurait pu relever — du genre overworld.su qui renvoi X-Powered-By: PHP/10.0.0 ??? ↩
Même si on ne rencontre que très peu de serveurs sous PHP 6, cette version de PHP, qui n’a jamais été publiée et dont le développement a même été abandonné, est tout de même déployée sur suffisament de machines pour attirer l’attention : cela signifie que, un jour, quelqu’un a installé sur un serveur « public » une version de développement de PHP, et n’a ensuite pas pris la peine de le mettre à jour… ↩
PHP 4 correspondant à des versions tellement dépassées que je préfére ne pas prendre la peine de rentrer au niveau des versions release. ↩
Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. ↩

Statistiques de versions de PHP - janvier 2012

Pascal MARTIN — mar., 24 janv. 2012 08:00:00 +0100

Il y a quelques mois, j’avais publié un article présentant des statistiques de déploiement des différentes versions de PHP : Statistiques de versions de PHP - septembre 2011.

Aujourd’hui, alors qu’environ quatre mois se sont écoulés et que la sortie de PHP 5.4 est imminente (les données présentées dans cet articles ont été collectées entre vendredi 20 et dimanche 22 janvier 2011 — après la sortie de la Release Candidate 6, qui est censée être la dernière pour PHP 5.4), voici une mise à jour de ces statistiques.

Sommaire :

Quelques mots sur la méthode

Pour faire simple, j’ai récupéré une liste de plus de 7.7 millions de noms de domaines, issus principalement :

Du top 1 million d’Alexa (chargé plusieurs fois à quelques semaines d’écart, ce qui donne plus de 1 million de noms de domaines),
Du top 1 million de Quantcast,
Des liens externes de wikipedia de plusieurs langues (environ 3 millions de noms de domaines),
De l’export mis à disposition par l’Export Open Directory (environ 2 millions de noms de domaines — dont beaucoup de vieux sites, pour autant que je puisse en juger),
Et de quelques résultats de recherche google (quelques milliers de noms de domaines).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis généralement¹ basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom de logiciel ayant servir à générer la page, ainsi que sa version.
Et dans le cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Server: Apache/1.3.41 (Unix) PHP/5.2.17
X-Powered-By: PHP/5.2.17

ou (pour www.mozilla.org) :

Server: Apache
X-Powered-By: PHP/5.2.9

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…

Quelques chiffres

Réponses PHP

Sur les 7.4 millions de requêtes HTTP effectuées sur les noms de domaines que j’ai testé, environ 26% des réponses ont été identifiées comme générées par du PHP.

Plus précisément, j’ai identifié 1,947,849 réponses comme correspondant à du PHP.

Serveurs Web

Cela dit, avant d’entrer dans le détail des versions de PHP, et même si ce n’est pas vraiment le but premier de cet article ou de la collecte de données effectuée, voici la liste des Serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

Apache : 4,491,135 — 67.80%
IIS : 1,233,729 — 18.63%
nginx : 366,639 — 5.54%
Autres : 261,484 — 3.95%
GSE : 155,842 — 2.35%
YTS : 47,748 — 0.72%
LiteSpeed : 39,865 — 0.60%
lighttpd : 27,163 — 0.41%

Ou, sous forme d’un graphe :

On notera :

Apache, toutes versions confondues, est toujours premier, loin devant les autres,
nginx est dans le top 3, pour les données collectées ici — depuis le début de l’année, il est annoncé comme ayant dépassé IIS et atteint la seconde place pour les sites « actifs », notion qui ne se retrouve pas dans les données utilisées pour rédiger cet article.

Versions majeures de PHP

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

PHP 3 : 851 — 0.04%
PHP 4 : 274,442 — 14.09%
PHP 5 : 1,672,456 — 85.86%
PHP 6 : 38 — 0.00%

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’oeil quelle est la version majeure de PHP la plus répandue, cela donne :

On notera :

Que, fort heureusement, PHP 5 est la version majeure la plus répandue,
Mais que, seconde moitié 2011, on a encore quelques centaines de sites, sur 7.4 millions, qui tournent encore sur du PHP 3,
Et aussi que PHP 4 est encore trop répandue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
Et enfin que, plus d’un an après la mise à mort de la branche PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée), on rencontre (encore) des sites qui utilisent PHP 6 en production ??? Très peu, certes, mais suffisamment pour attirer l’attention : cela signifie que, un jour, quelqu’un a installé sur un serveur « public » une version de développement de PHP, et n’a ensuite pas pris la peine de le mettre à jour…

Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

PHP 3.0 : 849 — 0.04%
PHP 4.0 : 1,945 — 0.10%
PHP 4.1 : 4,638 — 0.24%
PHP 4.2 : 4,262 — 0.22%
PHP 4.3 : 62,552 — 3.21%
PHP 4.4 : 201,042 — 10.32%
PHP 5.0 : 8,212 — 0.42%
PHP 5.1 : 95,439 — 4.90%
PHP 5.2 : 1,214,416 — 62.35%
PHP 5.3 : 354,182 — 18.18%
PHP 5.4 : 198 — 0.01%
PHP 6.0 : 38 — 0.00%

Et sous forme graphique :

Pour résumer :

PHP 5.2, qui a atteint sa fin de vie en décembre 2010, il y a déjà plus d’un an, est toujours, et de loin, la version de PHP qui semble aujourd’hui la plus utilisée / répandue,
PHP 5.3, stable depuis juin 2009, soit plus de deux ans et demi, n’arrive qu’en seconde place — et loin derrière PHP 5.2,
Et PHP 5.1 et 4.3/4.4 sont relativement proches l’un de l’autre.
Enfin, PHP 5.4, qui n’est pas encore sortie en version stable (les données utilisées utilisées ici ont été collectées après la sortie de la RC6, et avant la sortie de la première version stable), est déjà utilisée sur un nombre non-négligeale de serveurs publics ; et on trouve un peu de tout : beta1, RC2, RC3, RC4, RC5, RC6, … Donc il ne semble pas s’agir d’une volonté de tester/valider la toute dernière version³.

Versions releases de PHP

Et enfin, si on descend au niveau des versions release de PHP 5.x⁴, en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes :

Pour PHP 5.0 :
- 5.0.1 : 143 — 0.01%
- 5.0.2 : 305 — 0.02%
- 5.0.3 : 851 — 0.05%
- 5.0.4 : 5,723 — 0.34%
- 5.0.5 : 1,135 — 0.07%
Pour PHP 5.1 :
- 5.1.1 : 415 — 0.02%
- 5.1.2 : 7,163 — 0.43%
- 5.1.3 : 1,540 — 0.09%
- 5.1.4 : 2,588 — 0.15%
- 5.1.5 : 289 — 0.02%
- 5.1.6 : 83,424 — 4.99%
Pour PHP 5.2 :
- 5.2.0 : 27,968 — 1.67%
- 5.2.1 : 5,823 — 0.35%
- 5.2.2 : 2,026 — 0.12%
- 5.2.3 : 9,349 — 0.56%
- 5.2.4 : 45,958 — 2.75%
- 5.2.5 : 34,122 — 2.04%
- 5.2.6 : 192,326 — 11.50%
- 5.2.7 : 159 — 0.01%
- 5.2.8 : 22,939 — 1.37%
- 5.2.9 : 84,735 — 5.07%
- 5.2.10 : 43,988 — 2.63%
- 5.2.11 : 32,939 — 1.97%
- 5.2.12 : 42,008 — 2.51%
- 5.2.13 : 64,110 — 3.83%
- 5.2.14 : 64,124 — 3.83%
- 5.2.15 : 5,507 — 0.33%
- 5.2.16 : 28,964 — 1.73%
- 5.2.17 : 507,259 — 30.33%
Pour PHP 5.3 :
- 5.3.0 : 3,076 — 0.18%
- 5.3.1 : 4,575 — 0.27%
- 5.3.2 : 47,836 — 2.86%
- 5.3.3 : 79,910 — 4.78%
- 5.3.4 : 6,723 — 0.40%
- 5.3.5 : 37,700 — 2.25%
- 5.3.6 : 60,296 — 3.61%
- 5.3.7 : 861 — 0.05%
- 5.3.8 : 90,884 — 5.43%
- 5.3.9 : 22,282 — 1.33%
Pour PHP 5.4 :
- 5.4.0 : 197 — 0.01%

Et sous forme graphique :

Pour résumer :

Une quantité non-négligeable de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise.
Beaucoup de PHP 5.2.6 (publiée en Mai 2008) ; la version fournie par défaut sous Debian Lenny, par exemple.
La version de PHP la plus répandue est PHP 5.2.17 (publiée en Janvier 2011) ; ça reste du 5.2, qui a atteint sa fin de vie, mais positivons, en se disant que c’est la dernière version, la plus à jour…
Et enfin, plusieurs sous versions de PHP 5.3.x, sans qu’aucune ne s’impose réellement ; notons que la version 5.3.7, avec son bug de sécurité, et qui n’a été disponible que quelques jours, n’est heureusement pas la plus répandue⁵.

Evolution

Je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présenté ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 2011⁶, date à laquelle j’ai effectué ce type d’analyse pour la première fois (avec un point en décembre 2011, où j’avais effectué une collecte partielle de données, pour tester les améliorations que j’étais en train d’effectuer sur mes scripts) :

Notes importantes : la liste des sites analysés a énormément évolué entre septembre 2011 et janvier 2012 !

Entre septembre et décembre 2011, plus de 3 million de noms de domaines ont été ajoutés à ma liste ; dont une portion non-négligeable correspondant à de vieux sites (liste provenant principalement de l’export ODP). Ceci explique l’augmentation du pourcentage de sites utilisant PHP 4 et la diminution du pourcentage de sites utilisant PHP 5.2, entre septembre et décembre 2011 : selon toute logique, plus d’anciens sites signifie plus d’anciens serveurs, pour certains non mis à jour.
Les noms de domaines ajoutés ensuite, entre décembre 2011 et janvier 2012, correspondent principalement à des sites actifs, selon toute logique plus récents et/ou plus récemment mis à jour, et on retrouve la progression à laquelle on s’attendrait : augmentation du nombre de serveurs en PHP 5.3, au détriment de PHP 5.2 et 4.x.

Autrement dit : ce graphique n’est pas à considérer comme réfletant la réalité des évolutions des versions de PHP entre septembre et décembre 2011 !
Il deviendra probablement plus utile si je continue à publier ce type d’analyse dans le futur — c’est pourquoi je l’affiche tout de même ici.

Pour certains types de serveurs ou de logiciels, j’ai mis en place un bout de code qui va chercher les informations de version dans d’autres en-têtes que X-Powered-By. Par exemple, pour les sites développés en ASP.NET, les informations de version figurent généralement dans une en-tête nommée X-AspNet-Version. ↩
Pour ne pas prendre en compte les quelques résultats abherrant qu’on aurait pu relever — du genre overworld.su qui renvoi X-Powered-By: PHP/10.0.0 ??? ↩
Et ce type de validation, de toute manière, n’est normalement pas le genre de chose qui se fait sur un serveur de production, public… ↩
PHP 4 correspondant à des versions tellement dépassées que je préfére ne pas prendre la peine de rentrer au niveau des versions release. ↩
On pourrait souhaiter qu’une version connue pour un problème de sécurité comme ne soit celui qui avait fait tant de bruit au moment de PHP 5.3.7 ne soit absolument pas utilisée… Mais, malheureusement… ↩
Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. ↩

Traduction française de « Zend Framework: Survive The Deep End! »

Pascal MARTIN — lun., 07 nov. 2011 07:00:00 +0100

Courant juin 2009, Pádraic Brady, auteur du livre électronique Zend Framework, Surviving The Deep End, a lancé un projet de traduction de celui-ci en plusieurs langues.

Sur les mois qui ont suivis, deux traductions ont été réalisées :

Une traduction en allemand, par Matthias Zeis,
Et une traduction en français, par moi-même.

Malheureusement, pour diverses raisons, les deux traductions réalisées n’ont jamais été publiées^[1].
En y repensant il y a quelques semaines de ça, Matthias et moi nous sommes dit que, même si Zend Framework 1.x date un peu et que ZF 2.x approche, ces deux traductions pourraient peut-être tout de même être utiles à quelqu’un, et qu’il était de toute manière dommage de ne pas les mettre en ligne.

Nous les avons donc uploadées les versions HTML « brutes »^[2] ce week-end :

En espérant que ceci pourra encore s’avérer utile, même après tout ce temps, je vous souhaite une bonne lecture !

Notes

[1] ni sur le site officiel de ZFSDTE, ni ailleurs

[2] sans trop d’effort sur la CSS, autrement dit ; mais le contenu est là

Statistiques de versions de PHP - septembre 2011

Pascal MARTIN — lun., 03 oct. 2011 07:45:00 +0200

Avec la sortie de PHP 5.4 qui approche petit à petit^[1], et PHP 5.3 rendue publique il y a plus de deux ans, je me demandais quelles sont les versions de PHP qui sont, aujourd’hui, les plus utilisées — et, donc, quelles sont les versions de PHP sur lesquelles nous pouvons nous attendre à voir nos applications déployées.

Sommaire :

Quelques mots sur la méthode

Pour faire simple, j’ai récupéré une liste de plus de 3 millions de noms de domaines, issus :

Du top 1 million d’Alexa,
Des liens externes de wikipedia en anglais (plus de 2 million de noms de domaines non compris dans le top Alexa),
Et de quelques résultats de recherche google (quelques milliers de noms de domaines).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom de logiciel ayant servir à générer la page, ainsi que sa version.
Et dans le cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Server: Apache/1.3.41 (Unix) PHP/5.2.17
X-Powered-By: PHP/5.2.17

ou (pour www.mozilla.org) :

Server: Apache
X-Powered-By: PHP/5.2.9

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…

PHP ?

Sur les 3.1 million de requêtes HTTP effectuées sur les noms de domaines que j’ai testé, environ 25% des réponses ont été identifiées comme générées par du PHP.

Plus précisément, j’ai identifié 828,564 réponses comme correspondant à du PHP.

Avec plus de 800k réponses, les statistiques présentées plus bas devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Versions majeures de PHP

Commençons par les versions majeures de PHP, en prenant en compte les résultats qui ont été identifiés comme correspondant à une version supérieure ou égale à 3, et inférieure ou égale à 6^[2].

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

PHP 3 : 257
PHP 4 : 86,594
PHP 5 : 741,638
PHP 6 : 18

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’oeil quelle est la version majeure de PHP la plus répandue, cela donne :

On notera :

Que, fort heureusement, PHP 5 est la version majeure la plus répandue,
Mais que, seconde moitié 2011, on a encore quelques centaines de sites, sur 3 millions, qui tournent encore sur du PHP 3,
Et aussi que PHP 4 est encore trop répandue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
Et enfin que, plus d’un an après la mise à mort de la branche PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée), on rencontre (encore) des sites qui utilisent PHP 6 en production ???

Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

PHP 3.0 : 257
PHP 4.0 : 595
PHP 4.1 : 1,385
PHP 4.2 : 1,446
PHP 4.3 : 22,095
PHP 4.4 : 61,072
PHP 5.0 : 3,422
PHP 5.1 : 47,695
PHP 5.2 : 566,243
PHP 5.3 : 124,240
PHP 5.4 : 30
PHP 6.0 : 17

Et sous forme graphique :

Pour résumer :

PHP 5.2, qui a atteint sa fin de vie en décembre 2010, il y a déjà bientôt un an, est la version de PHP qui semble aujourd’hui la plus utilisée / répandue,
PHP 5.3, stable depuis juin 2009, soit plus de deux ans, n’arrive qu’en seconde place — et loin derrière PHP 5.2,
Et PHP 5.1 et 4.4 sont relativement proches l’un de l’autre.

Versions release de PHP 5.x

Et enfin, si on descend au niveau des versions release de PHP 5.x^[3], en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes :

Pour PHP 5.x :
- 5.0.2 : 116
- 5.0.3 : 326
- 5.0.4 : 2,401
- 5.0.5 : 502
Pour PHP 5.1 :
- 5.1.1 : 196
- 5.1.2 : 3,012
- 5.1.3 : 184
- 5.1.4 : 1,227
- 5.1.5 : 127
- 5.1.6 : 42,940
Pour PHP 5.2 :
- 5.2.0 : 10,493
- 5.2.1 : 3,089
- 5.2.2 : 960
- 5.2.3 : 4,145
- 5.2.4 : 21,111
- 5.2.5 : 15,631
- 5.2.6 : 94,194
- 5.2.8 : 11,280
- 5.2.9 : 43,752
- 5.2.10 : 22,478
- 5.2.11 : 15,610
- 5.2.12 : 17,588
- 5.2.13 : 28,808
- 5.2.14 : 36,532
- 5.2.15 : 3,594
- 5.2.16 : 18,877
- 5.2.17 : 217,942
Et pour PHP 5.3 :
- 5.3.0 : 1,810
- 5.3.1 : 2,715
- 5.3.2 : 21,890
- 5.3.3 : 28,359
- 5.3.4 : 5,261
- 5.3.5 : 16,680
- 5.3.6 : 31,549
- 5.3.7 : 643
- 5.3.8 : 15,310

Et sous forme graphique :

Pour résumer :

Une quantité non-négligeable de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise ?
Beaucoup de PHP 5.2.6 (publiée en Mai 2008) ; probablement la version fournie par défaut sous une autre distribution ?
La version de PHP la plus répandue est PHP 5.2.17 (publiée en Janvier 2011) ; ça reste du 5.2, qui a atteint sa fin de vie, mais positivons, en se disant que c’est la dernière version, la plus à jour…
Et enfin, plusieurs sous versions de PHP 5.3.x, sans qu’aucune ne s’impose vraiment ; notons que la version 5.3.7, avec son bug de sécurité, et qui n’a été disponible que quelques jours, n’est heureusement pas la plus répandue (même si on pourrait souhaiter qu’une version connue pour un problème de ce type ne soit absolument pas utilisée).

Le mot de la fin ?

Cela dit, une question pour vous, lecteurs : connaissez-vous des sites qui publient ce genre de statistiques de manière régulière — idéalement, gratuitement ?
Il fût un temps, nexen en publiait, mais j’ai l’impression qu’ils ont arrêté depuis 2008…

Notes

[1] la première version bêta de PHP 5.4 est sortie quelques jours après que j’aie réalisé les tests publiés ici

[2] Pour ne pas prendre en compte les quelques résultats abherrant qu’on aurait pu relever — du genre l2.ws qui renvoi X-Powered-By: PHP/10.0.0 ???

[3] PHP 4 correspondant à des versions tellement dépassées que je préfére ne pas prendre la peine de rentrer au niveau des versions release

Intégration continue d'un projet PHP avec Jenkins

Pascal MARTIN — mar., 27 sept. 2011 08:00:00 +0200

Cet article fait suite à Intégration continue avec Jenkins : installation et configuration de base — et pré-suppose que vous avez installé une plate-forme d’Intégration Continue Jenkins, avec les plugins qui seront nécessaires à la mise en intégration continue d’un projet PHP.

Nous allons maintenant passer à l’utilisation de la plate-forme que nous avons installé il y a quelques jours, en la configurant pour qu’elle effectue l’intégration continue d’un projet PHP.

Sommaire :

Oh, et, avant de commencer : si vous cherchez juste des fichiers de configuration « quasi tout-fait » pour Jenkins + PHP et n’êtes pas intéressés par un guide « étape par étape », vous devriez faire un tour là : Template for Jenkins Jobs for PHP Projects

Sommaire :

(Ne prenez pas peur en regardant la taille de l’ascenceur affiché par votre navigateur : sans les nombreuses captures d’écrans, cet article n’est finalement pas si long)

Intégration Continue d’un projet PHP ?

Je disais dans l’article précédant celui-ci qu’un des principes de l’Intégration Continue est de vérifier, à chaque modification du code-source d’une application, que le résultat de cette modification ne produit pas de régression sur l’application en question.

Outils d’analyse PHP

Cela implique donc la mise en place d’outils capables d’analyser une application et son code-source, afin de produire différents rappors de qualité — que ce soit au niveau de la qualité du code-source, ou au niveau de la qualité / stabilité de l’application.

Dans le monde PHP, les outils les plus fréquemment utilisés pour chaque type d’analyse sont les suivants :

Test Unitaires : PHPUnit
- On pourrait aussi entendre parler de SimpleTest, mais, depuis des années, n’est plus vraiment un projet vivant
- Ou de Atoum qui, bien que prometteur, n’est pas encore très répandu.
Vérification du respect des normes de codage : PHP_CodeSniffer
Dépendances entre composants : PHP Depend
PHP Mess Detector pour la remontée de statistiques susceptibles de mettre en évidence des portions de code-source de qualité médiocre
phpcpd pour la détection de portions de code copié-collé (portions qui devraient souvent être factorisées)
phploc pour la collecte de statistiques du type nombres de méthodes, nombres de classes, nombres de lignes de code, …
Génération de documentation d’API :
- Historiquement parlant, on pensera tout de suite à phpDocumentor (qui n’est plus tellement vivant, et a quelques difficultés avec PHP >= 5.3)
- Ou on se penchera plutôt vers phpdox, pour PHP >= 5.3, qui semble prometteur.
Et enfin, pour intégrer un navigateur de code à Jenkins, qui prenne en compte une partie des résultats issus d’outils cités ci-dessus, nous penserons à PHP_CodeBrowser.

Sans entrer dans les détails, la série de commandes suivantes devrait permettre d’installer le plus gros de ces outils — notez que cette liste est extraite d’un script d’installation que je joue sur à peu près toutes mes machines de développement PHP, et contient donc quelques outils / bibliothèques que nous n’utiliserons pas par la suite :

# Mise à jour des extensions PEAR déjà installées
sudo pear upgrade-all
sudo pear config-set auto_discover 1
 
# Installation de quelques extensions supplémentaires (pas forcément toujours utilisées, mais suffisament "souvent" pour que je les installe "par défaut")
sudo pear config-set preferred_state beta
sudo pear install --alldeps PHP_CodeSniffer PhpDocumentor php_CompatInfo Log Text_Diff HTML_QuickForm2 Image_GraphViz MDB2 Mail_Mime PHP_Beautifier-beta SOAP XML_Beautifier XML_RPC Structures_Graph components.ez.no/Graph VersionControl_SVN-alpha Horde_Text_Diff XML_RPC2 VersionControl_Git-alpha
 
# PHPUnit
sudo pear channel-discover pear.phpunit.de
sudo pear install --alldeps phpunit/PHPUnit
 
# Autres outils "QA"
sudo pear channel-discover pear.pdepend.org
sudo pear channel-discover pear.phpmd.org
sudo pear install pdepend/PHP_Depend
sudo pear install phpmd/PHP_PMD
sudo pear install phpunit/phpcpd
sudo pear install phpunit/File_Iterator
sudo pear install phpunit/phploc
sudo pear install --alldeps phpunit/PHP_CodeBrowser
 
# DocBlox (en alternative plus récente (et compatible PHP 5.3) à PhpDocumentor)
sudo pear channel-discover pear.docblox-project.org
sudo pear install --alldeps docblox/DocBlox

(Pour les scripts d’installation de machine de développement PHP dont je parlais juste au-dessus, vous pouvez jeter un coup d’oeil à https://github.com/pmartin/vm-dev-php/)

« Builder un job »

Avec Jenkins, l’Intégration d’un projet passe par un job : c’est ce job qui définira tout le processus d’intégration de votre application :

Extraction des sources depuis votre système de gestion de versions,
Opérations de construction — en particulier, lancement des outils d’analyse de qualité que nous avons vu plus haut,
Et publication des résultats de cette construction.

Chaque construction de votre application, idéalement, après chaque commit d’une modification, est appelée un build — et, par extension, lorsque Jenkins exécute un build de votre application, celle-ci sera buildée.

Jenkins vous permettra alors, pour chaque job, de consulter l’historique des builds, ou de déclencher un nouveau build.

Automatisation du process de build

Bien entendu, le processus de build est piloté par un outil d’automatisation : vous configurez le build, et celui-ci sera rejoué à l’identique à chaque construction, ce qui permettra de comparer les builds, d’avoir un historique cohérent, et de mesurer l’évolution du projet.

Jenkins étant un outil JAVA, c’est, par défaut, le programme Ant qui est utilisé pour le processus de build.
Pour faire super-simple, Ant prend en paramètre un fichier XML définissant des tâches à effectuer, et les lance les unes à la suite des autres, tant qu’aucune n’a échoué.

Ces tâches peuvent être fort simples, comme « effacer un fichier », plus complexes, comme « lancer une commande », voire même correspondre à du code personnalisé, répondant aux attentes d’un programme spécifique ou d’un besoin propre à votre projet.

Phing comme outil d’automatisation

Pour ma part, je trouve dommage, dans le cadre d’un projet PHP, d’utiliser l’outil Ant ; et j’ai tendance à lui préférer Phing, qui se veut être un clone de Ant, en PHP.
Avec, au minimum, trois avantages majeurs pour Phing :

Puisqu’il s’agit d’un programme développé en PHP, il peut être utilisé sur une machine sans VM JAVA — votre poste de développement, ou votre serveur de production, par exemple,
Il fourni en standard plusieurs tâches correspondant à certains des outils PHP que nous avons vu plus haut,
Et il est extensible en PHP : libre à vous de développer toute nouvelle tâche dont vous auriez besoin^[1].

Si besoin est, l’installation de Phing est des plus simples — via pear, bien entendu :

# Phing
sudo pear channel-discover pear.phing.info
sudo pear install --alldeps phing/phing

Au cas où vous ne l’auriez pas encore deviné, notez que, pour la suite de cet article, j’utiliserai Phing comme outil de build — et pas Ant.

Un projet PHP ?

Pour les besoins de cet article, je travaillerai avec un mini-projet PHP d’exemple, avec SVN comme système de gestion de versions, à l’URL suivante : https://svn.myserver/test-repository/trunk.

Note : ce projet étant en pleine phase de développement, c’est le trunk que nous placerons en Intégration Continue ; mais il va de soit qu’au fur et à mesure que de nouvelles branches seront crées, nous ajouterons de nouveaux jobs à notre plate-forme d’IC, correspondant à celles-ci.

Pour ce qui est des sources du projet en lui-même, elles sont plutôt minimalistes, et correspondent à l’arborescence suivante :

Pour faire simple :

L’application web que nous développons se trouve sous www,
Le répertoire utils contiendra les différents scripts utilitaires — dont le script Phing correspondant au processus de build : build.xml,
Et nos tests automatisés ont tout naturellement leur place sous tests.

Un job Jenkins pour notre projet PHP

Maintenant que nous avons un projet PHP, sur son système de gestion de versions, passons à sa mise en Intégration Continue sous Jenkins.

Vous vous souvenez peut-être qu’à la fin de l’article Intégration continue avec Jenkins : installation et configuration de base, après que nous nous soyons identifiés, Jenkins nous proposait de « créer un nouveau Job » ?

Et bien, c’est le moment ou jamais

Initialisation du job

La première étape est de spécifier le nom de notre job ; et de choisir de quel type il sera :

Dans le cadre d’un projet PHP, où nous gérerons nous-même le processus de Build (via un script Phing dans mon cas, ou un script Ant dans le cas par défaut), c’est la première option que nous choisissons : « Construire un projet free-style » ; cela nous laissera toute liberté sur la configuration, tout en étant suffisant pour la plupart des projets.

Une fois cet écran renseigné, vous arriverez sur la page de configuration de votre job — celle où vous allez pouvoir le paramétrer, indiquer à Jenkins quel script Phing est à utiliser pour construire votre projet, et quels types de rapports doivent être publiés :

Comme vous pouvez déjà le constater, cette page est un peu longue — et encore, de nombreuses options sont masquées, leurs blocs étant repliés ; dans les faits, cet écran peut vous demander un peu de temps avant que vous ne l’ayez vraiment pris en main… N’hésitez donc pas à le parcourir, en cliquant sur les nombreux boutons « Aide » figurant à côté de quasiment chaque option.

En fonction de l’espace disque dont vous disposez sur votre serveur d’intégration, ainsi que de la taille de chacun des builds de votre projet (généralement assez faible, lors de la mise en place d’une plate-forme d’IC au début d’un projet ; mais elle peut rapidement augmenter), vous ne pourrez probablement pas conserver l’ensemble de l’historique des builds…

Vous tirerez donc certainement parti de la fonctionnalité de suppression des anciens builds :

Tout en sachant que :

Il est intéressant de conserver un certain nombre de builds, afin d’avoir un peu d’historique sur le projet, et de pouvoir mesurer les progrès accomplis,
Vous pourrez indiquer manuellement, pour certains builds particulièrement intéressants, qu’ils devront être conservés sans limite de temps
Vous aurez la possibilité un peu plus loin, gràce aux plugins que nous avons installés, d’indiquer à Jenkins qu’il doit conserver un build de temps en temps :

(Cette option se trouve plus bas sur la page de configuration — mais j’en parle ici, afin que tout ce qui est « nettoyage et conservation des anciens builds » soit regroupé)

Au passage, notez que, si besoin est, Jenkins vous permet de désactiver un job :

Je vois deux cas où ceci est utile :

Lorsque vous savez que les modifications que vous allez faire sur le code-source de votre application vont la « casser » pendant un bon moment (au début d’une grosse phase de rework — que vous aurez menée, pour une raison ou une autre, sur le trunk, au lieu de passer par une branche), et que vous ne souhaitez pas importuner votre équipe avec des mails indiquant — inutilement — des build failed.
Lorsqu’un projet n’est plus en développement actif pendant quelques temps ; si vous avez un nombre important de jobs sur votre plate-forme d’IC, en marquer quelques uns comme inactifs permet de mieux mettre en évidence ceux qui sont utiles à un instant donné.

Accès au système de gestion de versions

L’étape suivante (placée avant le configuration d’accès au gestionnaire de versions — ce qui peut sembler étrange) est de configurer la « Période d'attente ».

Dit simplement : si un build est sur le point de se lancer alors qu’un commit a eu lieu très peu de temps auparavant, alors, le build sera repoussé de quelques secondes ; l’objectif étant de permettre aux développeurs de pousser leurs modifications vers le gestionnaire de versions en plusieurs commits, et d’éviter qu’un build ne se lance qu’avec la moitié des commits effectués^[2].

Nous pouvons maintenant passer à la configuration d’accès au système de gestion de versions — pour ce projet, il s’agit de SVN.

Les écrans sont assez parlant, et Jenkins essaye de vous guider au maximum (par exemple : bien souvent, dès qu’un champ de formulaire perd le focus, une vérification est effectuée sur ce que vous y avez saisi), mais, dans les grandes lignes :

Vous devez renseigner les informations d’accès à votre serveur de versions,
Au besoin, vous devrez indiquer un couple login / password permettant à Jenkins de s’identifier, si besoin est (si votre repository ne permet pas l’accès anonyme, par exemple)

Voici à quoi peut ressembler la saisie des informations d’accès à un serveur SVN :

Et en cliquant sur « Enter credentials », vous arriverez sur le formulaire suivant :

Attention tout de même : l’URL à renseigner correspond à celle du répertoire qui héberge les sources que vous souhaitez placer en intégration continue.
Autrement dit, vous ne travaillerez pas forcément à la racine du projet : il arrivera fréquemment que ce soit le répertoire trunk que vous intégrerez :

Vous noterez aussi que j’ai choisi de spécifier un nom de « répertoire local », que j’ai nommé src, par habitude.
De la sorte, l’extraction SVN du code-source de notre application se fera vers ce répertoire src — et nous serons libre de travailler « à côté » de ce src ; par exemple, notre script de build, que nous verrons plus loin, créera ses rapports d’audit de code dans un répertoire build, au même niveau que src, et sans risque d’interférer avec le contenu de celui-ci.

Une fois les informations d’identification saisies, Jenkins aura accès à votre système de gestion de sources ; et vous pourrez, au besoin, configurer quelques options supplémentaires :

Il ne reste plus qu’à indiquer à Jenkins quand construire notre projet.

Dans une logique d’Intégration Continue, le principe est généralement de scruter régulièrement le système de gestion de versions, pour déterminer si des modifications ont été apportées aux sources du projet ; et, si c’est le cas, de déclencher un build.

On aura donc souvent tendance à cocher « Scruter l'outil de gestion de version », et à renseigner le champ « planning » juste en-dessous :

Bien sûr, en fonction de votre projet, vous pouvez spécifier autre chose que toutes les minutes de toutes les heures de tous les jours.
Par exemple, pour ne scruter le gestionnaire de versions que pendant les heures et jours de travail :

Si vous enregistrez la configuration en cet état, sans compléter la suite de l’écran, le job devrait fonctionner — il ne fera qu’une seule chose : extraire les sources depuis le système de gestion de versions ; mais cela vous permettra de vérifier que cette première étape est fonctionnelle.

Après enregistrement, un build va être lancé automatiquement par Jenkins.
Une fois qu’il sera terminé, si vous cliquez dessus dans « l'historique des builds », vous aurez accès, dans le menu gauche, à une entrée « Sortie de la console » ; ceci vous amènera à un écran affichant le détail de la sortie console obtenue pendant l’exécution du build.
Dans notre cas, voici à quoi cette console ressemble :

Autrement dit, les sources de notre projet ont été extraite depuis le serveur SVN avec succès

Depuis l’écran principal du job dans Jenkins, vous pourrez aussi accèder à l’écran « Espace de travail », qui vous permet de naviguer à travers les fichiers extraits — ceux-ci l’ayant été vers le répertoire src configuré plus haut :

Utiliser Phing comme outil de build

Maintenant que nous savons que les sources de notre projet sont extraites avec succès, et que Jenkins parvient à accéder à notre système de gestion de versions, il ne reste plus qu’à retourner sur l’écran de configuration de notre job, afin d’indiquer que le build va être effectué par Phing.

Pour cela, nous allons « ajouter une étape au build », qui invoquera une target phing :

Nous renseignons ensuite à la fois la liste « Targets » (pour ce projet, le build entier est invoqué depuis la target ci, comme nous le verrons plus bas), et le chemin vers le script de build (le fichier build.xml, dans le projet dont j’ai montré l’arborescence un peu plus haut) :

La dernière étape de configuration de notre job serait de sélectionner et configurer les actions à effectuer à la suite du Build : typiquement, publier les résultats des analyses de qualité sur le code-source de notre application.

Mais, pour l’instant, nous ne cocherons rien :

Avant de se préoccuper des outils de contrôle qualité, nous aimerions nous assurer que notre job fonctionne,
Et nous allons de toute façon, pour cela, mettre en place le script de build Phing : build.xml — sinon, notre projet ne se construira de toute manière pas.

Une fois la configuration du job enregistrée, sa page d’accueil devrait ressembler à quelque chose de ce type :

Et, à chaque fois que vous commiterez une modification sur le code-source de votre application, un nouveau build devrait se lancer (Cf « Historique des builds », à gauche de l’écran) :

Bon, comme je disais plus haut, tant que nous n’avons pas mis en place build.xml, ça risque de ne pas très bien se passer, et les builds échoueront (une puce rouge indique un build en échec, dans l’historique) :

Et sur l’écran de détail du build :

Script de construction : build.xml

Un peu plus haut, nous avons indiqué à Jenkins, en configurant notre job, que celui-ci devait être construit via une target phing nommée ci, dans le fichier utils/build/build.xml.

Initialisation de build.xml : 3 targets

Cette target ci dépendra elle-même de deux autres targets :

clean, pour le nettoyage des répertoires de reporting (où les outils d’analyse enregistreront leurs rapports),
et qa, pour le lancement des outils (qui généreront les rapports que Jenkins mettra à disposition des utilisateurs).

Créons donc ce fichier, en initialisant les trois targets correspondantes :

<?xml version="1.0" encoding="UTF-8"?>
<project name="TestJenkins" default="ci" basedir="../../..">
    <property name="source" value="src" />
 
    <target name="ci"
        description="Tâche principale d'intégration continue"
        depends="clean,qa"
    />
 
    <target name="clean" description="Vide les répertoires d'artefacts">
 
    </target>
 
    <target name="qa" description="Lance les outils d'analyse">
 
    </target>
 
</project>

Vous remarquerez que j’ai commencé par initialiser une propriété, nommée source, qui contient le nom du répertoire où les sources seront extraites sur la plate-forme d’Intégration Continue — si vous avez suivi ce que je disais plus haut, vous utiliserez la même valeur que moi : src.

Si vous commitez ce fichier et attendez quelques instants, Jenkins lancera un build ; et la sortie de la console correspondant à son exécution sera la suivante :

Autrement dit :

Le build a réussi : le fichier utils/build/build.xml existe, et correspond bien à un fichier Phing valide,
Nos trois tâches ont été lancées :
- Tout d’abord, la tâche clean,
- Puis la tâche qa,
- Et enfin, la tâche ci, dont le seul rôle était de dépendre des deux autres, pour assurer leur bonne exécution.

Target clean

La première étape de notre build est de supprimer les éventuels résultats d’analyses du précédent (pour être sûr que les reporting n’utiliseront que les données issues du build courant), et, au besoin, de créer les répertoires qui contiendront les résultats de ces analyses.

Les répertoires à vider / créer dépendent des outils d’analyse que vous utiliserez sur votre projet, mais, en supposant que vous utiliserez ceux que je vais mettre en place plus loin, votre target clean devrait ressembler à ceci :

<target name="clean" description="Vide les répertoires d'artefacts">
    <delete dir="${project.basedir}/build/api" />
    <delete dir="${project.basedir}/build/code-browser" />
    <delete dir="${project.basedir}/build/coverage" />
    <delete dir="${project.basedir}/build/logs" />
    <delete dir="${project.basedir}/build/pdepend" />
 
    <mkdir dir="${project.basedir}/build/api" />
    <mkdir dir="${project.basedir}/build/code-browser" />
    <mkdir dir="${project.basedir}/build/coverage" />
    <mkdir dir="${project.basedir}/build/logs" />
    <mkdir dir="${project.basedir}/build/pdepend" />
</target>

Et, une fois build.xml commité, la sortie console de Jenkins devrait afficher quelque chose de ce type :

Et si vous jetez un coup d’oeil au workspace de votre projet depuis Jenkins, vous y retrouverez les répertoires que nous venons de créer, dans un répertoire build se trouvant au même niveau que notre répertoire src contenant le code-source de notre application (les résultats d’analyse ne viennent donc pas s’enregistrer au même endroit que notre code) :

Target qa : les outils d’analyse de qualité

Nous en arrivons enfin à la partie la plus intéressante de notre script build.xml : la mise en place des outils d’analyse de qualité.

Principe

Dans le principe, ma target qa ne fait généralement rien d’autre qu’appeler d’autres targets : une par outil.

Typiquement, elle ressemblera donc à quelque chose de ce type :

<target name="qa" description="Lance les outils d'analyse">
    <phingcall target="premier-outil" />
    <phingcall target="second-outil" />
    <phingcall target="troisime-outil" />
</target>

Les targets spécifiques à chaque outil étant définies plus bas :

<target name="premier-outil" description="...">
    <!-- Ici, le gros du boulot pour le premier outil  -->
</target>
 
<target name="second-outil" description="...">
    <!-- Ici, le gros du boulot pour le second outil  -->
</target>
 
<target name="troisime-outil" description="...">
    <!-- Et là, le gros du boulot pour le dernier  -->
</target>

Je vois deux avantages à cette solution :

D’une part, les targets spécifiques à chaque outils portent des noms explicites, et ne font que quelques lignes de long ; elles sont donc plus facile à comprendre,
Et, d’autre part, il suffit de commenter ou dé-commenter une <phingcall> pour activer ou désactiver un outil d’analyse.

Ci-dessous, donc, à chaque nouvelle target que nous implémenterons pour un nouvel outil, il faudra penser à ajouter son appel, via <phingcall>, à la target qa.

Target pdepend

La première target que je reproduis ci-dessous est celle qui permet d’invoquer l’outil PHP Depend :

<target name="pdepend">
    <phpdepend file="${project.basedir}/${source}/www">
        <logger type="jdepend-xml" outfile="${project.basedir}/build/logs/jdepend.xml" />
        <logger type="jdepend-chart" outfile="${project.basedir}/build/pdepend/dependencies.svg" />
        <logger type="overview-pyramid" outfile="${project.basedir}/build/pdepend/overview-pyramid.svg" />
    </phpdepend>
</target>

On notera trois choses, ici :

Tout d’abord (et c’est le cas pour un bon nombre des targets que nous verrons ensuite), phing fourni une tâche spécifique pour cet outil : <phpdepend> — ce qui signifie que nous n’avons pas besoin de passer par un tâche <exec> pour directement lancer le binaire correspondant^[3].
Dans pas mal de cas, nous allons specifier des formats de sortie correspondant à ceux des outils du monde JAVA — ces formats étant déjà acceptés par Jenkins
Et, enfin, nos fichiers de sortie seront générés dans le répertoire build, que nous avons présenté plus haut.

Target phpmd

Branchons ensuite l’appel à l’outil PHP Mess Detector, pour la remontée de statistiques susceptibles de mettre en évidence des portions de code-source de qualité médiocre :

<target name="phpmd">
    <phpmd file="${project.basedir}/${source}/www">
        <formatter type="xml" outfile="${project.basedir}/build/phpmd.xml" />
    </phpmd>
</target>

Ici encore, nous utilisons une tâche fournie spécialement par Phing, et indiquons que le fichier en sortie doit être généré vers le répertoire build.

Target phpcpd

Passons ensuite à l’appel de l’outil phpcpd, pour la détection de portions de code copié-collé :

<target name="phpcpd">
    <phpcpd file="${project.basedir}/${source}/www">
        <formatter type="pmd" outfile="${project.basedir}/build/logs/pmd-cpd.xml"/>
    </phpcpd>
</target>

Target phploc

Enchainons ensuite avec la collecte de statistiques du type nombres de méthodes, nombres de classes, nombres de lignes de code, … avec l’outil phploc :

<target name="phploc">
    <exec logoutput="true" dir="${project.basedir}" command="phploc --log-csv '${project.basedir}/build/logs/phploc.csv' '${project.basedir}/${source}/www'" escape="false" />
</target>

Ici, le fichier généré en sortie sera un fichier .csv — Jenkins ne saura pas en faire grand chose en l’état, mais, avec un peu de configuration, nous obtiendrons des graphes de nombres de lignes de code, de nombres de méthodes, …

Target phpcs

Vérifions ensuite le respect des normes de codage, avec PHP_CodeSniffer :

<target name="phpcs">
    <phpcodesniffer standard="Zend">
        <fileset dir="${project.basedir}/${source}/www">
            <include name="**/*.php"/>
        </fileset>
        <formatter type="checkstyle" outfile="${project.basedir}/build/logs/checkstyle.xml"/>
    </phpcodesniffer>
</target>

Target phpdoc

Si vous utilisez phpDocumentor pour la génération de votre documentation d’API, voici une target qui devrait vous intéresser :

<target name="phpdoc">
    <phpdoc title="API Documentation"
            destdir="${project.basedir}/build/api"
            sourcecode="false"
            output="HTML:Smarty:PHP">
        <fileset dir="${project.basedir}/${source}/www">
            <include name="**/*.php"/>
        </fileset>
        <projdocfileset dir=".">
            <include name="README"/>
            <include name="INSTALL"/>
            <include name="CHANGELOG"/>
        </projdocfileset>
    </phpdoc>
</target>

Notez que si vous utilisez phpdox, Phing fourni aussi une tâche <docblox>

Target phpunit

Pour invoquer PHPUnit, Phing fournit une tâche <phpunit>, mais je n’ai pas réussi à la faire fonctionner en utilisant un fichier phpunit.xml pour la configuration des tests.

Ne souhaitant pas dupliquer la configuration de PHPUnit (une fois ici, dans build.xml, et une fois dans phpunit.xml tel qu’attendu par PHPUnit), j’ai préféré utiliser la tâche <exec>, pour invoquer directement l’utilitaire phpunit en ligne de commande :

<target name="phpunit">
    <exec logoutput="true" dir="${project.basedir}/${source}/tests" command="phpunit" escape="false" />
</target>

Et voici un exemple de fichier phpunit.xml, qui colle au projet d’exemple que j’ai utilisé pour rédiger cet article :

<phpunit>
    <testsuites>
        <testsuite name="My Test Suite">
            <directory>./</directory>
        </testsuite>
    </testsuites>
 
    <filter>
        <whitelist>
            <directory suffix=".php">../www</directory>
        </whitelist>
    </filter>
 
    <logging>
        <log type="coverage-html" target="../../build/coverage" title="Name of Project"
             charset="UTF-8" yui="true" highlight="true"
             lowUpperBound="35" highLowerBound="70"/>
        <log type="coverage-clover" target="../../build/logs/clover.xml"/>
        <log type="junit" target="../../build/logs/junit.xml" logIncompleteSkipped="false"/>
    </logging>
</phpunit>

Immense avantage : ce fichier phpunit.xml va être utilisé à la fois par chacun des développeurs de votre équipe sur leurs postes de développement, et par la plate-forme d’Intégration Continue.

Target phpcb

Et pour finir, voici la target invoquant PHP_CodeBrowser, pour intégrer un navigateur de code à Jenkins, qui prenne en compte les résultats issus d’outils cités ci-dessus :

<target name="phpcb">
    <exec logoutput="true" command="phpcb --log '${project.basedir}/build/logs' --source '${project.basedir}/${source}/www' --output '${project.basedir}/build/code-browser'" escape="false" />
</target>

Ici encore, Phing ne fourni pas de tâche spécifique, et nous passons donc par <exec>^[4].

Target qa complète

Maintenant que nous avons mis en place les targets correspondant à chacun de nos outils d’analyse, nous pouvons revenir à la target qa, chargée de les invoquer les uns après les autres, et la compléter :

<target name="qa" description="Lance les outils d'analyse">
    <phingcall target="pdepend" />
    <phingcall target="phpmd" />
    <phingcall target="phpcpd" />
    <phingcall target="phploc" />
    <phingcall target="phpcs" />
    <phingcall target="phpdoc" />
    <phingcall target="phpunit" />
    <phingcall target="phpcb" />
</target>

Résultat du build

Si nous commitons notre fichier build.xml et attendons quelques instants qu’un build se lance, et allons faire un tour sur l’écran « Sortie de la console » de Jenkins, nous verrons que l’ensemble des outils d’analyse ont été invoqués.

Je ne reproduis pas toute la sortie ici, mais voici un bref aperçu du début de la sortie (On voit notamment que les targets pdepend et phpmd ont été invoquées) :

Et voici un aperçu de la fin de la sortie console (ici, on voit que les targets phpunit et phpcb ont été invoquées, et que le build s’est terminé avec succès) :

Publier les résultats du build

Où en sommes-nous ?
Nous avons un projet PHP, nous avons mis en place une plate-forme d’intégration continue, nous avons créé notre script de build, celui-ci lance plusieurs outils d’analyse sur le code de notre projet… Il ne nous reste donc plus qu’à publier les résultats de ces analyses, n’est-ce pas ?

Pour mettre en place la configuration de ces résultats d’analyses, nous allons retourner sur la page de configuration de notre job, sur l’interface web de Jenkins : en bas de cette page figure une section « Actions à la suite du Build », que nous n’avions pas renseignée, plus haut :

Nous allons donc configurer les actions de publications correspondant aux outils que nous avons mis en place lors du build.

Analyse checkstyle

Dans notre fichier build.xml, nous avons invoqué l’outil PHP_CodeSniffer, en lui demandant de générer en sortie un fichier build/logs/checkstyle.xml.

Renseignons donc ce chemin dans le champ de formulaire correspondant :

Si vous souhaitez configurer plus finement certaines options, vous pouvez cliquer sur « Avancé », pour accéder au formulaire complet :

Une fois ceci configuré, enregistrez le job ; et lançons manuellement un build (puisqu’aucune modification de code source n’a été effectuée sur le gestionnaire de versions, Jenkins ne lancera pas de build automatiquement)…

Tout à la fin de la sortie console du build, nous voyons que Jenkins a analysé le fichier checkstyle.xml que nous venons de lui indiquer :

Une entrée « Résultats Checkstyle » figure maintenant dans le menu de notre projet, à gauche de l’écran :

Et cliquer sur cette entrée nous mène à une série d’écrans / onglets nous permettant de consulter les résultats de l’analyse checkstyle :

Enfin, si nous re-lançons un build, nous verrons que, une fois son exécution terminée, un graphe remonte sur l’écran d’accueil de notre projet, mettant en évidence la « tendance » des résultats de notre analyse (un seul build n’étant pas assez pour tracer un graphe de progression : il en faut au moins deux, pour qu’une comparaison soit possible) :

Analyse PMD

L’étape suivante est d’activer la publication des rapports d’analyse PMD :

Avec, ici aussi, la possibilité de configurer le publieur de manière un peu plus poussée :

Une fois un build lancé, nous pouvons constater à la fin de sa sortie console que les résultats de l’analyse PMD ont été pris en compte :

Le nombre de problèmes relevés est indiqué sur la page principale du build :

Et après quelques builds, l’écran d’accueil de notre job voit apparaitre un nouveau graphique de tendances :

Analyse CPD

Après cela, passons à l’activation de la publication des rapports de l’analyse de détection de code copié-collé :

Ou, pour la version « avancée » :

Et la sortie console d’un build, une fois cette publication activée (pour vérifier que notre demande de publication a bien été prise en compte — et que nous n’avons pas raté un point lors de sa configuration) :

Une section supplémentaire s’ajoute à l’écran de détail de notre build, indiquant le nombre de portions de code dupliqué qui ont été relevées par l’analyse (vu la taille de notre projet d’exemple, il aurait été difficile de vraiment trouver des portions de code copiées-collées…) :

Et ici encore, au bout de quelques builds, un nouveau graphique vient s’ajouter à l’écran principal de notre job, illustrant la tendance :

Rapports de Tests Unitaires

Au tour, maintenant, des rapports de tests PHPUnit. Fort heureusement, PHPUnit est capable de générer des fichiers de rapports au format JUnit du monde JAVA — ce qui tombe plutôt bien, quand notre plate-forme d’Intégration Continue est un outil du monde JAVA

Donc, activons la publication des rapport JUnit (PHPUnit, donc, mais faisons comme si) :

Une fois la configuration de notre job enregistrée, lançons un build, et vérifions la console :

Une entrée supplémentaire apparait sur l’écran principal de chaque build :

Et si nous cliquons sur le lien « Résultats des tests », nous pourrons naviguer plus en profondeur dans nos classes et méthodes de tests :

Une fois un second (ou plus) build lancé, nous constaterons une fois de plus qu’un graphique supplémentaire vient s’ajouter à l’écran principal de notre projet, affichant la tendance de résultats de tests :

Rapports de Couverture de Code

L’exécution des Tests Unitaires, dont nous venons de publier le rapport, a permis la création des rapports de couverture de code (qui mettent en évidence les lignes de code exécutées lors des tests unitaires — et donc, le ratio de code testé vs code non testé).

Activons donc la publication de ces rapports ; en tenant compte à la fois du rapport XML (utilisé par Jenkins pour afficher ses statistiques) et du rapport HTML (qui permettra de naviguer dans le code, en visualisant les lignes exécutées ou non) :

Encore une fois, vérifions la sortie console du build que nous lancerons après avoir enregistré notre configuration, pour nous assurer que ce nouveau point est bien pris en compte en fin de build :

Et sur l’écran de détail du build le plus récent, nous voyons apparaitre une section « Clover Code Coverage » (bon, 22%, c’est pas terrible ^^) :

En naviguant vers « Clover HTML report », via le menu à gauche, nous arrivons sur le rapport HTML généré par PHPUnit, qui permet de naviguer dans le code, en visualisant ce qui a ou non été couvert par nos tests automatisés :

Et en choisissant « Clover Summary report », nous avons, présentées de façon un peu plus succinte, quelques statistiques :

Ces statistiques se retrouvent d’ailleurs aussi sur la page principale de notre projet, pour ceux qui voudraient y avoir accès en un coup d’oeil :

Documentation d’API, et Code Browser

Nous avons intégré à notre processus de build la génération de la documentation d’API (via phpDocumentor, ici) et d’un navigateur de code (via PHP_CodeBrowser).
Ces deux outils générent une série de pages HTML, dont Jenkins ne peut pas extraire d’information spécifique ; nous les publierons donc sous forme de « HTML reports », ce qui nous permettra tout de même d’y avoir accès depuis notre plate-forme d’Intégration Continue :

Après avoir ajouté les deux rapports correspondant (les chemins utilisés ici correspondent à ceux que nous avons renseigné dans notre script de construction, build.xml, bien entendu) :

Comme d’habitude, nous vérifions, via la sortie console du build lancé après enregistrement de ces nouveaux paramètres, que ceux-ci ont bien été pris en compte :

Et la page d’accueil de notre job (ainsi que le menu gauche) s’enrichit de deux liens, correspondant aux deux rapports dont nous avons demandé la publication :

« API Documentation »,
et « Code Browser »

Après avoir cliqué sur le premier lien, nous arrivons à la documentation d’API de notre projet (si j’avais positionné quelques docblocks dans mon code, ça serait un peu plus parlant, certes) :

Et le second lien mène à un navigateur de code, qui intégre une partie des résultats d’analyse produits par d’autres outils (ici, en exemple, un extrait de rapport checkstyle généré par PHP_CodeSniffer) :

Rapport PHP Depend

Passons ensuite à la publication du rapport généré par PHP Depend — qui a fourni un fichier correspondant au format JDepend du monde JAVA, ce qui, encore une fois, est bien arrangeant :

Et, une fois notre paramétrage enregistré, lançons un build et vérifions la sortie console :

Le menu gauche de notre job s’enrichit, encore une fois, d’une entrée supplémentaire : « JDepend » :

Et voici un aperçu du rapport qui s’affiche si nous cliquons dessus (encore une fois, sur un projet d’exemple aussi petit, le rapport n’est pas aussi intéressant qu’il pourrait l’être sur un projet plus volumineux…) :

Rapport de violations

Nous pouvons aussi demander à Jenkins de regrouper, sous forme d’un graphe, plusieurs types de rapports.

Typiquement, ici, nous allons regoruper au sein d’un même graphe les informations issues des analyse checkstyle, cpd, et pmd :

Comme d’habitude, jetons un coup d’oeil à la console après avoir lancé un build… Bon, pas bien grand chose d’utile, ce coup-ci :

Par contre, maintenant (éventuellement, au bout de quelques builds, pour avoir des points de comparaison pour pouvoir tracer un graphe), nous avons sur la page d’accueil de chaque build un graphe reprenant les informations que nous avons aggrégées au-dessus :

Ce graphique se retrouve aussi sur la page principale de notre job, d’ailleurs.

Et si nous cliquons sur le lien « Violations » dans le menu gauche, nous arrivons à une page de détails :

Cette page n’est pas forcément celle qui vous sera la plus utile, mais le graphique sur la page principale du job, par contre, peut vous intéresser, pour détecter tout changement brutal du nombre de problèmes causées par les sources de votre projet (par exemple, cela peut vous permettre de vérifier en un clin d’oeil que l’arrivée d’un nouveau développeur dans l’équipe, ne connaissant pas encore vos normes de codage, ne s’accompagne pas d’une hausse catastrophique de violations de celles-ci).

Lignes de code, nombres de méthodes, classes, …

Il reste encore un outil d’analyse dont nous n’avons pas exploité les résultats : phploc.
Nous avons demandé à cet outil de nous générer en sortie un fichier CSV, enregistré dans build/logs/phploc.csv :

Si nous jetons un coup d’oeil au contenu de ce fichier (toujours sur le même mini-projet de test, qui n’est probablement pas le plus intéressant pour ce genre de chose), nous pouvons voir qu’il contient quelque chose de ce type (j’ai ajouté des retours à la ligne dans la première ligne, pour faciliter la lecture) :

Lines of Code (LOC),Cyclomatic Complexity / Lines of Code,Comment Lines of Code (CLOC),Non-Comment Lines of Code (NCLOC),
    Namespaces,Interfaces,Classes,Abstract Classes,
    Concrete Classes,Average Class Length (NCLOC),Methods,Non-Static Methods,
    Static Methods,Public Methods,Non-Public Methods,Average Method Length (NCLOC),
    Cyclomatic Complexity / Number of Methods,Anonymous Functions,Functions,Constants,
    Global Constants,Class Constants
42,0,0,42,0,0,2,0,2,12.5,5,5,0,3,2,5,1,0,0,0,0,0

Un fichier CSV tout ce qu’il y a de plus classique, autrement dit, avec en première ligne les titres de colonnes, et en seconde ligne les valeurs.

Tel quel, ce fichier n’est pas des plus intéressant ; et les chiffres qu’il contient ne le sont pas bien plus.
Par contre, avec ce type d’informations, ce qui peut être intéressant, c’est la progression au cours du cycle de vie du projet, d’un build sur l’autre.

Nous allons donc publier ces chiffres sous forme de graphes, reprenant l’historique d’un nombre non négligeable de constructions, permettant de voir en un rapide coup d’oeil quelle est l’évolution de notre projet en termes de nombres de lignes de codes, de nombres de classes, de nombres de méthodes, …

Les paramètres de configuration que je vais reproduire ici sont ceux proposés par Sebastian Bergmann dans ses Templates PHP pour Jenkins — ils font plutôt bien l’affaire ; et Sebastian sait de quoi il parle, puisque c’est l’auteur de, entre autre, phploc, l’outil utilisé pour effectuer les analyses dont nous présentons ici les résultats.

A - Lines of code

Le premier graphe est celui des nombres de lignes de code.

Il prendra en compte les colonnes suivantes du fichier CSV : Lines of Code (LOC),Comment Lines of Code (CLOC),Non-Comment Lines of Code (NCLOC)
La configuration correspondante dans Jenkins pourrait donc ressembler à ceci :

Libre à vous de personnaliser le titre et le libellé sur l’axe Y ; par contre, veillez à bien cocher la radio « Include columns by name », et à saisir en-dessous les noms des colonnes à utiliser — cette remarque est vraie pour tous les graphes que nous construirons à partir du rapport généré par phploc.

B - Structures

Passons ensuite au graphe affichant les nombres de structures de chaque type, qui prendra en compte les colonnes suivantes du fichier CSV : Directories,Files,Namespaces,Interfaces,Classes,Methods,Functions,Anonymous Functions,Constants

C - Testing

Au tour du graphique présentant les classes et méthodes de tests automatisés, qui tracera les courbes correspondant aux colonnes suivantes : Classes,Methods,Functions,Test Clases,Test Methods

D - Types of Classes

Viennent ensuite les nombres de classes de chaque type, avec les colonnes suivantes : Classes,Abstract Classes,Concrete Classes

E - Types of Methods

Puis les différents types de méthodes : Methods,Non-Static Methods,Static Methods,Public Methods,Non-Public Methods

F - Types of Constants

On passe ensuite aux différents types de constantes : Constants,Global Constants,Class Constants

G - Average Length

Pour enchainer avec les longueurs moyennes de classes et de méthodes (on se rappelle au passage que les méthodes et classes trop longues, c’est pas top ) : Average Class Length (NCLOC),Average Method Length (NCLOC)

H - Relative Cyclomatic Complexity

Et nous terminons avec la Complexité Cyclomatique, tirant profit des colonnes suivantes : Cyclomatic Complexity / Lines of Code,Cyclomatic Complexity / Number of Methods

Et les résultats ?

Une seconde fois, rien de bien intéressant dans la sortie console de notre buid :

Par contre, une entrée « Plots » est venue s’ajouter au menu gauche de notre job ; et cliquer dessus mène à une page présentant les différents graphes que nous venons de configurer.
Par exemple, pour le nombre de lignes de code :

Ou pour les différents types de méthodes :

(Bon, OK, ça devient plus intéressant lorsque vous bossez sur un vrai projet bien vivant — à vous de jouer, pour ça )

Et maintenant ?

Voyons voir… vous savez installer Jenkins et ses plugins, et nous avons vu ici comment le configurer pour placer un projet PHP en intégration continue, construire ce projet avec Phing, et publier les résultats d’analyse… C’est plutôt un bon début

Maintenant, la balle est dans votre camp : c’est ce que vous ferez de cette plate-forme d’Intégration Continue, la façon dont vous travaillerez avec, qui déterminera son utilité réelle pour votre projet.

Si je puis tout de même me permettre quelques conseils :

Plus les outils d’analyse de qualité arrivent tôt (s’ils sont en place avant même que les développement ne commencent, c’est encore mieux), plus il sera facile de former vos équipes, de les sensibiliser à l’importance de la qualité, et de tenir compte de ces retours — si vous mettez en place PHP_CodeSniffer sur un projet en cours de développement depuis des mois, où chacun a codé à sa façon, vous aurez des milliers d’erreurs… et personne n’aura jamais le courage de les corriger ; donc les résultats de cette analyse seront tout simplement ignorés ; et hop, une partie de votre plate-forme qui ne servira à rien !
La plate-forme d’intégration continue ne doit pas être vue comme un ennemi : un test qui échoue, ce n’est pas la fin du monde, ce n’est pas PHPUnit qui est méchant ; au contraire : c’est un problème potentiel identifié rapidement, avant livraison de l’application en production, avant de ne devenir un problème réel ; c’est donc une aide qui est apportée à toute l’équipe^[5].
L’Intégration Continue, tout comme le code de l’application, ce n’est pas réservé à une ou deux personnes : c’est toute l’équipe du projet qui est concernée ; et doit donc être formée à son utilité, et à son utilisation.

Et, sur un plan plus technique :

Si vous utilisez un Framework (Zend Framework, symfony, …), ou construisez autour d’un logiciel existant (Drupal, Magento, …) : ne perdez pas de temps à jouer les tests de ces outils, ni à construire leur documentation d’API — de toute façon, vous n’y arriverez probablement pas (votre build durerait une éternité ; pour rien ou presque, finalement) ; au contraire, excluez les répertoires concernés.
Au fur et à mesure que votre projet va grossir, votre plate-forme d’Intégration Continue va avoir besoin de plus de ressources machine (CPU, RAM, disque, …) — évitez donc de la déployer sur un petit serveur dans un coin, déjà utilisé pour 36 autres trucs

Quelques liens et sources d’inspiration :

Documentation de Phing^[6] : elle vous sera utile, lorsque vous aurez besoin de rendre votre build.xml plus spécifique, ou de développer des tâches personnalisées (ce qui, dans le cadre de l’IC, ne m’est pas arrivé bien souvent ; mais phing, comme outil d’automatisation, peut être utilisé dans d’autres contextes )
Template for Jenkins Jobs for PHP Projects : comment mettre un projet en Intégration Continue sous Jenkins — en utilisant Ant, et pas Phing ; si vous n’avez pas envie de faire toute la création du script de build et toute la configuration du job Jenkins « à la main », ces templates sont fait pour vous
Integrate Your PHP Project with Jenkins : une série de slides (en anglais) de Sebastian Bergmann sur le sujet,
et Intégration continue des projets PHP avec Jenkins : une série de slides de Hugo Hamon ; en français, ceux-ci — jetez-y un coup d’oeil !

Notes

[1] Et rien que cette extensibilité en PHP, c’est une énorme force pour Phing, dans le cadre de projets PHP où les équipes de développement ne savent pas forcément coder en JAVA — en encore moins débugger un programme JAVA qui planterait.

[2] Si votre projet est sous SVN et que vous bossez sur plusieurs demandes en même temps, sans utiliser de branche, vous voyez probablement de quoi je parle…

[3] Un autre avantage de Phing, outil du monde PHP

[4] Libre à vous de coder la tâche correspondante, et de soumettre un patch

[5] Je ne sais pas vous, mais moi, je suis bien content quand j’arrive au bureau et que, avant de livrer une évolution en production, j’ai un mail qui me dit « build failed » ; c’est quand même plus agréable que le coup de fil du client deux heures après, ralant parce que ça fait deux heures que les utilisateurs ne peuvent plus passer de commande sur sa boutique et qu’il a perdu X milliers d’euro sur la matinée… surtout si vous lui avez déjà fait le coup trois semaines avant…

[6] Oui, la documentation de Phing, en son état actuel, est mal foutue — j’ai espoir que ça change dans le futur

Intégration continue avec Jenkins : installation et configuration de base

Pascal MARTIN — lun., 26 sept. 2011 08:00:00 +0200

Jenkins, précédemment connu sous le nom de Hudson^[1], est un outil Open-Source d’Intégration Continue, écrit en JAVA.

Cet article va montrer comment installer un serveur d’Intégration Continue sous Jenkins ; et sera suivi d’un second article, qui montrera comment utiliser cette plate-forme pour intégrer un projet PHP.

Sommaire :

Notes

[1] Pour faire simple, le projet Hudson s’est renommé en Jenkins suite à un désaccord avec Oracle — et, maintenant, les deux projets ont tendance à se considérer l’un-l’autre comme des forks…

Jenkins, précédemment connu sous le nom de Hudson^[1], est un outil Open-Source d’Intégration Continue, écrit en JAVA.

Sommaire :

Intégration continue ?

Pour commencer, quelques mots sur ce qu’est l’Intégration Continue, quelques pré-requis à la mise en Intégration Continue d’un projet… Et aussi quelques points expliquant en quoi l’Intégration Cotninue peut être utile.

L’intégration continue, qu’est-ce que c’est ?

Pour faire simple, le principe est de vérifier, idéalement à chaque modification de code source, que le résultat de ces modifications de produit pas de régression sur l’application.

Autrement dit, le but est de faire de l’intégration un non-événement : au lieu d’avoir le travail de 10 développeurs mis en commun une fois par mois — et, forcément, que tout casse pendant quelques jours, parce que chaque développeur avait interprêté les specs à sa façon —, cette mise en commun se fait maintenant à chaque modification, en continu ; ce qui permet d’augmenter les chances que chaque portion de l’application fonctionne avec ses autres composantes.

Pré-requis

Pour que l’intégration continue soit possible sur un projet, quelques pré-requis doivent être en place :

Le code-source de l’application doit être partagé entre tous les développeurs ; typiquement, en utilisant un système de gestion de versions (CVS, SVN, Bazaar, Git, …),
Les développeurs doivent pousser réglièrement leurs modifications de code vers le système de gestion de versions,
Et des tests (automatisés) d’intégration doivent être mis en place, pour valider l’application (intégrer les sources de l’application sans vérifier le bon fonctionnement de celle-ci, c’est peu utile, mine de rien…)

J’ajouterais que, pour que l’Intégration Continue soit un succès, et pour que la plate-forme d’IC soit pleinement utilisée, il est nécessaire que les équipes (à tous les niveaux : développeurs, testeurs, chefs de projets, …) soient formés à la fois à sont utilité, mais aussi à son utilisation.
Typiquement, si le management se désintéresse de l’intégration continue, une partie des équipes ne s’en souciera plus, les rapports d’échecs ne seront plus analysés, une partie des problèmes ne seront plus corrigés, et la plate-forme perdra petit à petit de son intérêt — devenant, au mieux, un outil de déploiement régulier, et, au pire, un truc plein de rouge envoyant des mails que personne ne prend plus le temps de lire…

Pourquoi ?

Les principaux avantages de l’Intégration Continue sont les suivants :

Les problèmes d’intégration sont détectés rapidement, et peuvent donc être corrigés au fil de l’eau, sans avoir à attendre une passe d’intégration manuelle qui n’a lieu que trop rarement^[2],
Les tests automatisés mis en place sur l’application, et joués à chaque intégration, permettent d’identifier rapidement les changements problématiques,
La dernière version stable de l’application est connue, et peut rapidement être obtenue (pour tests, démonstration, …).

Installation de Jenkins

Installer Jenkins (un des logiciels servant de base pour une plate-forme d’Intégration Continue — et le plus utilisé, en ce moment, pour les projets PHP), pour peu que vous disposiez d’un serveur d’intégration à peu près à jour, n’est pas bien compliqué : l’idée de base est de télécharger un .war, et de le lancer ; en ajoutant éventuellement ce lancement aux services de la machine, pour qu’il soit automatisé.

Sous Ubuntu

J’ai l’habitude d’utiliser la distribution Ubuntu sur mes machines de développement et sur mes serveurs de test/intégration^[3] ; et, justement, l’installation de Jenkins sous Ubuntu est extrêment simple.

Je ne vais pas faire grand chose de plus que citer la page Installing Jenkins on Ubuntu ; mais vous avez juste quatre lignes de commandes à lancer pour installer Jenkins :

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

Avantage : Jenkins sera installé de la même manière que les autres composants du système, via le système de gestion de paquets de la distribution — ce qui facilitera, entre autres, les mises à jour.

Et sous Windows ?

C’est généralement assez peu utile dans le cadre d’un projet PHP (encore que, en fonction du type de projet, vérifier son bon fonctionnement sous une large gamme d’OS ne soit absolument pas une mauvaise idée), mais Jenkins peut aussi être installé sous Windows.

N’ayant pas encore testé par moi-meme, je ne peux que vous pointer vers Install Jenkins as a Windows service.

Une fois que Jenkins est installé ?

Une fois Jenkins installé, il ne vous reste plus qu’à accéder, via votre navigateur web, à son interface.

Par défaut, Jenkins écoute sur le port 8080 ; donc, en fonction de l’adresse de votre serveur d’intégration, vous utiliserez une URL de ce type pour y accéder :

http://192.168.0.14:8080/

Ou, si vous avez défini une entrée DNS ou un alias dans votre fichier hosts, vous utiliserez quelque chose de ce type :

http://jenkins:8080/

Pour la suite de cet article, j’utiliserai généralement cet alias jenkins — à vous d’adapter mes URLs à votre environnement.

Accès en CLI

En plus de cet accès Web, qui vous permet à la fois de gérer la plate-forme et vos projets via une interface relativement agréable à utiliser, il existe un accès en ligne de commande, qui est surtout utile pour scripter des opérations de maintenance.

Depuis l’interface Web, vous pouvez cliquer sur Administrer Jenkins > Ligne de commande (CLI) Jenkins (ou, plus simplement, accéder à http://jenkins:8080/cli) pour plus d’informations à ce sujet, mais le principe de base est de télécharger le fichier .jar permettant l’accès à distance :

wget http://jenkins:8080/jnlpJars/jenkins-cli.jar

Et, ensuite, de l’exécuter, avec les bons noms de commandes — par exemple, pour afficher la liste des commandes disponibles, ainsi qu’un court descriptif :

java -jar jenkins-cli.jar -s http://jenkins:8080/ help

Nous utiliserons un peu plus loin cet accès en ligne de commande, pour semi-automatiser l’installation de plugins.

Petit tour de l’interface d’administration, et gestion de base

Maintenant que nous avons installé Jenkins, et que nous savons y accéder, faisons un rapide tour de l’interface d’administration, avant de commencer à installer les plugins qui seront plus tard utilisés pour la mise en Intégration Continue d’un projet PHP.

Tout d’abord, si nous pointons notre navigateur vers le port 8080 de notre serveur d’intégration (dans mon cas, http://192.168.0.14:8080/ — mais, comme vu plus haut, rien ne vous empêche d’utiliser un nom de machine, comme http://jenkins:8080/), nous arrivons sur la page d’accueil de Jenkins :

On peut ici noter quelques premiers éléments :

En haut à gauche, le menu principal, à partir duquel nous pourrons administrer Jenkins, ajouter des utilisateurs, …
Juste en dessous, toujours à gauche, la file d’attente de construction, qui, à terme, indiquera les projets en attente / en cours de construction,
Et, bien sûr, au milieu de l’écran, puisque nous n’avons pas encore créé de job, un lien nous invitant à le faire.

Cliquer sur le lien Administrer Jenkins, dans le menu gauche, nous mène à la page de gestion de notre plate-forme d’Intégration Continue :

Je vous encourage à cliquer sur la première entrée de cette page, le lien Configurer le système, qui vous permettra de configurer les paramètres généraux de la plate-forme :

Comme vous pouvez le constater, la liste d’options offertes est déjà relativement longue, puisqu’elle ne tient généralement pas sur un seul écran :

Heureusement, vous trouverez, pour quasiment chaque option et paramètre de Jenkins, un bouton « Aide » à droite de l’écran.
Cliquer dessus affichera quelques informations quant aux données attendues par le champ de formulaire à côté duquel cette icône figure.

Par exemple, si je clique sur le bouton « Aide » à droite du champ « Période d'attente » :

En l’état, il n’y a pas grand chose à configurer : les options par défaut ont tendance à faire l’affaire.

Cela dit, je ne peux que vous conseiller de prendre le temps de lire l’aide de chaque option : cela vous permettra de voir ce que vous pouvez faire avec Jenkins, ainsi que de vous familiariser avec la plate-forme.

Dans le même esprit, n’hésitez pas à faire un tour sur les autres écrans de l’interface d’administration : après tout, un peu de curiosité n’a jamais fait de mal

Installation de plugins

Une grande richesse de Jenkins (qui, de base, ne fait pas bien grand chose — surtout pour ce qui est de projets PHP) est son système de plugins, ainsi que le grand nombre de plugins existant.

Pour accéder aux écrans de gestion des plugins, : Administrer Jenkins > Gestion des plugins, qui devrait vous mener à http://jenkins:8080/pluginManager/.
Ici, vous aurez sous les yeux la liste des plugins installés (quelques plugins sont fournis avec Jenkins, et, donc, déjà installés, même si ce n’est pas par vous), pour lesquels une mise à jour est disponible :

L’onglet d’à-côté est celui qui donne la liste des plugins disponibles, plus ou moins rangés par catégories — comme vous pouvez le constater, la liste est longue ; et la parcourir rapidement peut vous donner une idée des possibilités réelles d’une plate-forme d’Intégration Continue Jenkins :

Continuons avec le troisième onglet, qui affiche la liste des onglets installés.
Pour l’instant, il n’y en n’a que quelques uns, mais nous allons rapidement allonger cette liste :

Et enfin, un quatrième onglet « Avancé », qui vous permettra notamment, si besoin est, de configurer un Proxy, par lequel Jenkins passera pour le téléchargement de plugins ou la recherche de mises à jour :

Principe de l’installation de plugins

Généralement, l’installation de nouveaux plugins va se faire via le second onglet vu plus haut : cochez les plugins à installer, validez via le bouton en bas de la liste, et voilà.

Mais j’ai tendance à privilégier, pour ce type d’opération, l’interface en ligne de commandes : ça a l’immense avantage d’être scriptable (autrement dit, une fois que la liste des plugins est connue et la liste des commandes correspondantes saisie, il ne reste plus qu’à la rejouer à chaque installation d’une plate-forme Jenkins — et celles-ci sont toujours installées avec à peu près les même plugins).

En cas d’installation en ligne de commande, notons que le nom du plugin à utiliser dans la commande d’installation est le « nom court »
Par exemple, pour le plugin Green Balls, dont la page de présentation commence comme ceci :

Le nom court sera « greenballs », et la commande d’installation correspondante sera :

java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin greenballs

Que le plugin ait été installé en ligne de commande, ou directement via l’interface web, un redémarrage de Jenkins sera nécessaire — comme indiqué, par exemple, sur la page de liste des plugins installés :

Redémarrons donc la plate-forme :

Et après quelques instants, le plugin que nous venons d’installer et indiqué comme tel :

Au passage, tant que j’y suis : dans une logique d’automatisation de l’installation des plugins, le redémarrage de Jenkins aurait aussi pu se faire depuis la ligne de commande :

java -jar jenkins-cli.jar -s http://jenkins:8080 safe-restart

Quels plugins installer ?

Considérant la taille de la liste de plugins disponibles, il va vous falloir effectuer un peu de tri, pour n’installer que ceux qui vous sont nécessaires^[4].

Catégoriser les plugins n’est pas forcément évident, mais essayons ; je dirais qu’on peut les regrouper en quatre ensembles :

Les plugins qui sont plus en rapport avec la plate-forme Jenkins en elle-même qu’avec vos projets : le suivi de sa configuration, la gestion des constructions, l’envoi de mails de reporting, la signalisation d’échecs de construction via Jabber, …
Les plugins qui permettent d’accéder au code-source de votre projet : SVN, Git, CVS, …
Les plugins qui effectuent les analyses sur votre projet : tests unitaires, couverture de code, respect des normes de codage, …
Et, enfin, les plugins qui permettent de publier les résultats des analyses : tracé de graphes, mise à disposition de rapports HTML, …

Presque en vrac, voici une liste de plugins que j’ai tendance à installer (certains toujours ; d’autres plus occasionnellement), lorsqu’il s’agit de mettre en place une plate-forme d’intégration continue pour un projet PHP^[5] :
(je copie-colle sauvagement un bout de la présentation de chaque plugin depuis les pages wiki correspondantes — cliquez sur les liens pour en savoir plus)

Green Balls : Changes Hudson to use green balls instead of blue for successful builds.
HTML Publisher Plugin : This plugin publishes HTML reports.
Publish Over SSH Plugin : Publish files and execute commands over SSH (SCP using SFTP)
Audit Trail Plugin : Keep a log of who performed particular Jenkins operations, such as configuring jobs.
Email-ext plugin : This plugin allows you to configure every aspect of email notifications.
Instant Messaging Plugin : This plugin provides generic support for build notifications and a ‘bot’ via instant messaging protocols.
Jabber Plugin : This plugin enables Jenkins to send build notifications via Jabber, as well as let users talk to Jenkins via a ‘bot’ to run commands, query build status etc..
checkstyle : This plugin generates the trend report for Checkstyle, an open source static code analysis program.
Clover PHP Plugin : This plugin allows you to capture code coverage reports from PHPUnit.
DRY Plugin : This plugin generates the trend report for duplicate code checkers like CPD or Simian.
JDepend Plugin : The JDepend Plugin is a plugin to generate JDepend reports for builds.
Plot Plugin : This plugin provides generic plotting (or graphing) capabilities in Jenkins.
PMD Plugin : This plugin generates the trend report for PMD, an open source static code analysis program.
Task Scanner Plugin : This plugin scans the workspace files for open tasks and generates a trend report.
Violations : This plug-in generates reports static code violation detectors such as checkstyle, pmd, cpd, findbugs, fxcop, stylecop and simian.
xUnit Plugin : This plugin makes it possible to publish the test results of an execution of a testing tool in Hudson.
Phing Plugin : This plugin allows you to use Phing to build PHP projects.
Post build task : This plugin allows the user to execute a shell/batch task depending on the build log output.
Build Keeper Plugin : Automatically keep every x builds to enable long term analysis trending when discarding old builds

Et quelques autres plugins que je n’utilise pas forcément, mais que je garde à l’esprit, en me disant que, un jour ou l’autre, il y a des chances qu’ils servent (en l’occurence, ici, j’ai choisi de les installer, sur la plate-forme d’Intégration Continue que je met en place pour la rédaction de cet article) :

Performance Plugin : This plugin allows you to capture reports from JMeter and JUnit. Hudson will generate graphic charts with the trend report of performance and robustness.
Monitoring : Monitoring of Hudson / Jenkins itself with JavaMelody.
SCM Sync configuration plugin : Keep sync’ed your config.xml (and other ressources) jenkins/hudson files with a SCM repository
WebSVN2 Plugin : This plugin integrates WebSVN Version 2 browser interface for Subversion with Hudson
Subversion Tagging Plugin : This plugin automatically performs subversion tagging (technically speaking svn copy) on successful build.

Bien entendu, à vous de personnaliser cette liste en fonction de vos besoins — typiquement, si vous travaillez avec Git pour certains projets, il vous faudra installer un plugin permettant d’interfacer Jenkins avec Git

Et la série de lignes de commandes correspondant à l’installation de l’ensemble de ces plugins, pour ceux d’entre vous qui, comme moi, préférent quelques copier-coller à une série de clicks dans une longue liste (en n’oubliant pas de redémarrer Jenkins en fin d’installation, bien entendu) :

java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin greenballs
 
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin htmlpublisher
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin publish-over-ssh
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin audit-trail
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin email-ext
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin instant-messaging
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin jabber
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin checkstyle
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin cloverphp
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin dry
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin jdepend
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin plot
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin pmd
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin tasks
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin violations
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin xunit
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin phing
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin postbuild-task
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin build-keeper-plugin
 
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin performance
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin monitoring
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin scm-sync-configuration
java -jar jenkins-cli.jar -s http://jenkins:8080/ install-plugin svn-tag
 
java -jar jenkins-cli.jar -s http://jenkins:8080 safe-restart

Une fois ces plugins installés, l’écran « Administrer Jenkins » s’est un peu allongé :

Et ne parlons pas (en fait, si, parlons-en ^^) de l’écran « Configurer le système », qui s’enrichit de la configuration d’une partie des fonctionnalités offertes par les plugins que nous venons d’installer :

Configuration ?

Maintenant que notre plate-forme d’Intégration Continue Jenkins est installée, avec l’ensemble des plugins dont nous aurons besoin pour nos projets PHP, il ne nous reste plus qu’à la configurer, avant de pouvoir passer à la mise en IC d’un projet PHP.

Configuration du système

Nous allons retourner sur l’écran « Administrer Jenkins > Configurer le système » que nous avions entre-aperçu plus haut, et passer en revue quelques éléments de configuration qui sont susceptibles d’être intéressants — tout en sachant que ce intéressant dépend en bonne partie de vos besoin.

Tout d’abord, Jenkins permet de configurer qui peut accéder à la plate-forme, comment, et quels types de manipulations sont autorisés :

En fonction de votre politique, vous choisirez de donner accès à toutes les fonctionnalités à tout utilisateur potentiel, ou vous configurez Jenkins pour que seuls les comptes administrateurs puissent accéder à certaines opérations.

N’oubliez pas deux points, tout de même :

Le succès de l’Intégration Continue repose en partie sur l’implication de l’ensemble des membres de l’équipe,
Si votre serveur est ouvert sur l’Internet, vous ne voudrez peut-être pas tout rendre public

Si vous avez installé le plugin SCM Sync configuration plugin, vu plus haut, vous aurez la possibilité de sauvegarder la configuration de votre plate-forme d’IC vers un serveur de gestion de versions ; cela peut potentiellement être intéressant, ne serait-ce que pour faciliter l’annulation de modifications insuffisament réfléchies :

Ensuite, pour ceux d’entre vous qui vont travailler avec des projets sous SVN, il peut être intéressant de configurer la version de SVN émulée par Jenkins (en particulier, si vous voulez pouvoir bosser avec d’autres outils sur l’extraction effectuée par Jenkins) :

En fonction des projets, des équipes, de l’attention que chacun porte aux mails, vous voudrez éventuellement configurer de manière un peu plus poussée le reporting par e-mails :

Notez tout de même que les notifications par e-mail pourront aussi être activées / configurées par projet.

Enfin, dans le cas où votre plate-forme Jenkins devra se connecter à d’autres machines via SSH, vous voudrez probablement configurer une clef SSH pour Jenkins :

Exemple d’utilisation : pousser en SSH/SCP le résultat du build vers un serveur de reporting ; ou déployer à chaque intégration réussie une archive contenant le code-source correspondant à celle-ci.

Création d’un compte utilisateur

En fonction des réglages que vous avez effectué plus haut, chaque utilisateur de la plate-forme devra peut-être se créer un compte utilisateur — j’ai tendance à préférer cela à un fonctionnement anonyme, ne serait-ce que pour pouvoir suivre qui agit sur la plate-forme :

En l’occurence, ici, j’ai configuré Jenkins pour que seul les utilisateurs identifiés puissent créer / configurer des tâches.

Donc, remplissons le formulaire — qui ne demande que peu de données à saisir :

Et l’identification devient possible :

Nous allons donc pouvoir passer à la création et au paramétrage d’un premier job — dont je parlerai dans un second article, qui sera publié dans les jours à venir.

Et la CLI, alors ?

Avant de terminer, je reproduis ici, à titre de curiosité, la liste des opérations qu’il est maintenant possible d’effectuer depuis la ligne de commandes :

$ java -jar jenkins-cli.jar -s http://jenkins:8080/ help
build
Builds a job, and optionally waits until its completion.
cancel-quiet-down
Cancel the effect of the "quiet-down" command.
clear-queue
Clears the build queue
connect-node
Reconnect to a node
copy-job
Copies a job
create-job
Creates a new job by reading stdin as a configuration XML file
delete-builds
Deletes build record(s)
delete-job
Deletes a job
delete-node
Deletes a node
disable-job
Disables a job
disconnect-node
Disconnects from a node
enable-job
Enables a job
groovy
Executes the specified Groovy script
groovysh
Runs an interactive groovy shell
help
Lists all the available commands
install-plugin
Installs a plugin either from a file, an URL, or from update center
install-tool
Performs automatic tool installation, and print its location to stdout. Can be only called from inside a build
keep-build
Mark the build to keep the build forever.
list-changes
Dumps the changelog for the specified build(s)
login
Saves the current credential to allow future commands to run without explicit credential information
logout
Deletes the credential stored with the login command
mail
Reads stdin and sends that out as an e-mail.
offline-node
Stop using a node for performing builds temporarily, until the next "online-node" command.
online-node
Resume using a node for performing builds, to cancel out the earlier "offline-node" command.
quiet-down
Quiet down Jenkins, in preparation for a restart. Don't start any builds.
reload-configuration
Discard all the loaded data in memory and reload everything from file system. Useful when you modified config files directly on disk.
restart
Restart Jenkins
safe-restart
Safely restart Jenkins
set-build-description
Sets the description of a build
set-build-result
Sets the result of the current build. Works only if invoked from within a build.
version
Outputs the current version
wait-node-offline
Wait for a node to become offline
wait-node-online
Wait for a node to become online

Si ça peut donner des idées à certains d’entre vous

Mises à jour ?

Tout comme l’installation, les mises à jour sont relativement simple à effectuer.

Mise à jour de Jenkins

J’ai rédigé le plus gros de cet article il y a plusieurs semaines, et, depuis, une (au moins) nouvelle version de Jenkins a été publiée.
Si une mise à jour existe, Jenkins le signale, en haut de l’écran d’administration :

Vous pourriez cliquer sur le lien pour télécharger la nouvelle version du fichier .war de Jenkins, et le déployer à la main, mais, considérant que nous avons effectué notre installation en utilisant le gestionnaire de paquets de notre distribution Linux, ce serait un peu dommage…

A la place, utilisons ce gestionnaire de paquets pour installer la mise à jour : tout d’abord, mettons à jour la liste des paquets disponibles :

sudo apt-get update

Et ensuite, nous pouvons soit mettre à jour l’ensemble des logiciels installés sur notre serveur d’Intégration Continue :

sudo apt-get dist-upgrade

Soit ne mettre à jour que Jenkins^[6] :

sudo apt-get install jenkins

Ce qui donnerait :

Et le numéro de version de notre plate-forme d’Intégration Continue, en bas à droite de l’écran, a changé ; ici, nous sommes passés de la version 1.424 à la version 1.431.

Mise à jour des plugins

Pour ce qui est des plugins, il est aussi possible de les mettre à jour.

Le plus « simple » est probablement d’ouvrir l’écran de gestion des plugins, qui affichera la liste des modules pouvant être mis à jour :

Cochez les plugins que vous souhaitez mettre à jour, cliquez sur le bouton « Installer », et voila, les plugins se mettent à jour

Et notez que vous pouvez même cocher la case en bas de l’écran de mises à jour, pour que Jenkins redémarre tout seul après cette mise à jour, chargeant la nouvelle version des plugins :

Liens utiles

Je ne peux terminer sans ajouter quelques liens, pour ceux qui voudraient en savoir plus, ou n’auraient pas la patience d’attendre :

Wiki "utilisation" : Use Jenkins
Les fiches wiki de l’ensemble des plugins : Plugins
Les sources de Jenkins^[7] : https://github.com/jenkinsci

Notes

[2] Pour ceux qui ont déjà travaillé sur des projets avec une intégration manuelle peu fréquente et difficile, l’Intégration Continue est un changement agréable !

[3] Je connais pas trop mal Ubuntu, que j’utilise depuis plusieurs années, après avoir utilisé Debian pendant quelques années aussi ; ça marche pas trop mal pour un environnement de « non-production » ; il est assez facile (indispensable pour ceux d’entre-nous qui n’ont pas trop l’habitude de Linux) de trouver de la documentation et du support autour d’Ubuntu ; et les paquets en rapport avec PHP sont à peu près à jour

[4] Si vous avez envie de vous amuser et de tester 36 plugins, libre à vous de le faire — mais, éventuellement, privilégiez une installation de test de Jenkins, sur une autre machine que votre vrai serveur d’intégration

[5] Au pire, certains des modules installés ne seront pas utilisés pour certains projets — en gardant à l’esprit qu’installer plein de plugins rend potentiellement plus complexe la configuration d’un projet

[6] Oui, c’est apt-get install qui permet de mettre un jour un paquet spécifique, sans mettre à jour les autres logiciels

[7] C’est de l’Open Source, libre à vous de participer et d’améliorer et l’hébergement sur GitHub devrait vous aider à le faire

Slides de ma conférence "Ligne de commandes sous Linux : effrayant ? Non : indispensable !" au Forum PHP 2010

Pascal MARTIN — mar., 16 nov. 2010 08:00:00 +0100

Mardi 9 et mercredi 10 novembre avait lieu, à Paris, le Forum PHP 2010, organisé par l’AFUP.

J’y ai donné une conférence intitulée "Ligne de commande sous Linux : effrayant ? Non : indispensable !".
Voici les slides que j’ai utilisé comme support lors de cette présentation :

Ligne de commandes sous Linux : effrayant ? Non : indispensable !

View more documents from Pascal MARTIN.
(tags: php, afup, forumphp )

Vous pouvez aussi directement télécharger le fichier PDF correspondant.

Bonne lecture !

Les slides des autres conférences ont été mis en ligne sur le site de l’AFUP.
Et vous pouvez poster des commentaires sur l’ensemble des conférences sur Joind.in.

Et, au passage, le photos de ces deux journées ont commencé à apparaitre sur flickr : Photos du groupe Forum PHP.

Forum PHP 2010, les 9 & 10 novembre : j'y serai !

Pascal MARTIN — lun., 13 sept. 2010 13:00:00 +0200

Cette année, le Forum PHP organisé par l’AFUP aura lieu les 9 et 10 novembre à la Cité des Sciences et de l’Industrie à Paris.

Il sera organisé autour de quatre thèmes directeurs :

PHP de A à Z : Débuter en PHP, Réussir un projet avec PHP, Choisir son hébergement
Les outils basés sur PHP : Drupal , outils de e-commerce et de business, CRM et ERP
L’industrialisation de PHP : Performances, tests, authentification centralisée, frameworks
Technologies autour de PHP : HTML 5, référencement…

Cette année, j’animerai une session intitulée Ligne de commande sous Linux : effrayant ? Non : indispensable !, qui s’inscrit dans le premier de ces quatre thèmes.

Pour résumer en quelques mots : nos applications PHP sont souvent déployées sur des serveurs Linux — et nous savons tous que, un jour ou l’autre, nous aurons besoin de nous connecter à ce serveur…
Alors, pourquoi ne pas anticiper, et découvrir quelques commandes qui vous seront forcément utiles un jour ou l’autre ?

Pour les conférences auxquelles je pense assister, je n’ai pas encore fait un choix définitif, mais une première pré-selectionne me donne au moins celles-ci :

PHP, son ecosystème : passé, présent et futur : forcément, la conférence donnée par Rasmus Lerdorf, je pense que tout le monde y assistera — surtout qu’il n’y en n’aura pas d’autre en parallèle.
PHP inside, par curiosité, ou Les revues de code ou comment faire fructifier son capital humain, qui se rapproche de ce que j’ai parfois l’occasion de faire au bureau.
Plein phar !
Migration d’une base de code de subversion vers git
Optimisation des performances LAMP
Un site web performant, tout est dans le réseau et le navigateur
Analyse statistique du code - Écoutez votre code PHP
HTML 5 : prêt à l’usage ? ou Windows et PHP : Un couple qui évolue.
APC & Memcached the High Performance Duo

Enfin, bref, encore une fois, un lot de conférences intéressantes — et le choix final va encore être difficile, dans certains cas

Et, pour finir, voici quelques liens susceptibles d’intéresser ceux qui hésitent encore :

Je suppose que cela sera l’occasion de croiser certains d’entre vous ; à bientôt, donc !