La version RC3 contient pour le moment :

• Amélioration de l’extension
• Built-in webserver
• Traits
• déréférencement des tableaux
• Les appels de méthodes via les tableaux
• La notation binaire pour les entiers
• Instanciation d’une classe sans passer par son constructucteur
• Amélioration de l’extension Json
• Amélioration de l’extension Curl

Dans un prochain billet je reviendrai sur la signification de chacun de ces points.

Qu’est ce que l’intégration continue ?

« L’intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement ». (Source : wikipedia).

Je rajouterai à cette définition, la notion de « build » a pour objectif de générer automatiquement un produit opérationnel et testable. Cette approche consiste à inspecter (revue de code), compiler, tester (tests unitaires, tests d’intégration, de performance..), déployer, documenter, notifier (Email, Sms, rsss…).

Pourquoi l’intégration continue ?

Source : martinflower.com

Comme schématiser ci-dessus, en général, dans un projet dépourvu de plateforme d’intégration continue, plus le projet grossi en termes de code et de nombre de développeur, plus le nombre de bugs augmente. En général, ces bugs sont corrigés en phase de recette. Par contre il y’a toujours une limite dans la correction de ces bugs (limite rouge), dans le sens où il y’a de très fortes chances d’avoir des « bugs cachés » indétectable par l’utilisateur et là « Oups !! bonjour les dégats ».

De plus on entend souvent de la part des développeurs, une fois avoir livré une fonctionnalité à l’utilisateur des réflexions du genre : « Ca ne marche pas chez toi !!!C’est bizarre pourtant Ca marche sur mon poste de développement».

En plus de pouvoir livrer automatiquement sur un environnement, une plateforme d’intégration continue permet d’éviter ce genre de problème.

Comment ça marche ?

Pour appliquer cette technique, il faut d’abord que :

- l’équipe mette en place un environnement de travail stable et homogène incluant par exemple :

• une instance virtuelle LAMP (VMWARE) proche techniquement de l’environnement cible
• Un IDE du type éclipse PDT ou Zend Studio qui exploite l’environnement d’exécution PHP localisé sur le serveur LAMP. Cet IDE facilite le débogage et le travail au quotidien avec des technologies “externes” (XML, webservices, Javascript) dont les plugins sont maintenus par des spécialistes.

- le code source soit partagé (en utilisant des logiciels de gestion de versions tel que Subversion) ;

- les développeurs intègrent dans leur méthode de développement des tests unitaires, tests d’intégration, de performance, des tests IHM automatiques avec sélénium et PHPUnit

- les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications ;

- Ensuite, il faut un outil d’intégration continue tel que Hudson , Xinc ou PHPUndercontrol pour automatiser les tâches de vérification, de compilation, de déploiement et de consolidation des indicateurs de qualité logiciel.

Une telle technique de développement permet de :

• diminuer fortement les problématiques de déploiement lors de la mise en recette ou en production de l’application.
  • les problèmes d’intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute ;
  • test immédiat des unités modifiées ;
  • prévient rapidement en cas de code incompatible ou manquant ;
  • une version est toujours disponible pour test, démonstration ou distribution

• aider l’équipe projet à connaître l’état de son projet en fonction d’indicateurs tels que :
  • la proportion des intégrations réussies/échouées
  • l’évolution de la couverture de code. Le code coverage permet d’analyser les statistiques et le détail de la couverture de code des tests unitaires
  • l’évolution des tests unitaires (échoués/total)
  • l’évolution du nombre de violations. Le CodeSniffer permet de fournir un résumé par classe avec le nombre d’erreurs et de warnings générés par fichier
  • Il faut donc documenter le code avec la PHPDoc et écrire les tests unitaires avant de coder les méthodes correspondantes
• dynamiser le développement, responsabiliser les développeurs et toujours disposer d’un build qui fonctionne.
• fiabiliser le code en insistant sur les tests unitaires et accroître la qualité logicielle

Comment le mettre en place dans une entreprise ?

Commencer petit (test unitaires, métriques) et rester pragmatique.

Avoir un projet pilote…

Communiquer sur l’existence de ce service et avoir des retours

La pertinence de l’intégration continue s’amplifie lors que l’on conduit un projet avec des méthodes agiles

Conclusion

L’intégration continue, de nos jours est le moyen le plus efficace d’éviter le « boom » pendant une phase d’intégration. Elle permet d’avoir des applications plus robustes et fonctionnellement pertinentes, de capitaliser des bonnes pratiques de fabrication logiciel.

L’intégration continue pouvant être automatisable, et qui dit automatisable dit réactivité, donc plus de réactivité dans nos projets.

$years = range(1920, 2000); //On crée par exemple un tableau de valeur
$years_list = array_combine($years, $years);
new sfWidgetFormDate(array('years' => $years_list))

Et voilà..

C’est ce que je fais, mais patatrac, je me trouve confronté à une, voire deux erreurs :

phar « C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar » does not have a signature

PHP Warning:  require_once(phar://go-pear.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar « phar://go-pear.phar/index.php » in C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar on line 1236

Warning: require_once(phar://go-pear.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar « phar://go-pear.phar/index.php » in C:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar on line 1236

Grâce à Google , j’ai trouvé la solution(Ce fût difficile, raison pour laquelle je poste ce billet qui peut être utile à d’autres) :

Modifier directement votre php.ini, en cherchant la directive phar.require_hash, la décommenter et lui donner la valeur Off.

Comme il dit dans son blog twitter ” As lame as I feared – time to find a new job“

Après plus de 5 ans de développement et d’améliorations, l’éditeur a enfin décidé de sortir toutes ses Google Apps (Gmail mais aussi Google Calendar, Google Docs et Google Talk) de leur « phase d’expérimentation ». Rassurez-vous, rien ne change : seule la petite mention BETA en gris disparaît.

Pour ceux qui avaient fini par s’habituer, l’équipe de développement propose avec humour une  option inédite dans les Gmail Labs. L’application Retour à la version bêta permet ainsi de retrouver la mention BETA sous le logo Gmail.

Reste que Gmail a largement contribué à rendre la notion de version bêta toute relative. Est-ce grave docteur ?

Pour plus d’information voir le site http://www.odtphp.com/

Le système d’exploitation Google Chrome est libre, léger. Il sera destiné aux mini-PC et disponible au second semestre 2010. “La rapidité, la simplicité et la sécurité en sont les principaux aspects”, affirment les concepteurs.

A voir sa pertinence par rapport à d’autres OS!!!