urbanisation-si.com

urbanisation-si.com

11/11 Projet informatique, passer du moyen âge à l'ère industrielle. Devenez parano en vérifiant chaque jour votre développement logiciel avec l'intégration en continue.

integration-continue.png

N'attendez surtout pas que les développements soient  commencés pour mettre en place la plate forme  d'intégration continue car vous risqueriez de "brûler du gaz" pour rien. Au contraire investissez dés le départ et soyez audacieux et innovateur, ce sont les clés du retour sur investissement. 

 

En fait l'objectif c'est de rechercher la sérénité. En effet en investissant au départ dans les vérifications automatiques journalières c'est pouvoir dormir comme un bébé chaque nuit. 

Chaque évolution ou modification du code peut engendrer des régressions. N'est il pas rageant de s'apercevoir qu'une fonctionnalité complexe difficile à mettre au point et dûment testée ne marche plus ! L'automatisation des tests de régression exécutés au moins une fois par jour permet de  voir au plus tôt  ce qui ne va pas et empêche d'ajouter des nouvelles fonctionnalités qui ne feraient qu'aggraver la situation. 

Mais que doit faire la plate forme? 

Tout d'abord récupérer le code source, depuis le dépôt qui est la plupart du temps un outil de gestion de source (CVS, SVN, Git, SourceSafe, …).  

Ensuite vérifier et optimiser le code par des outils d'audit (voir mon article :  9/11  Projet informatique, passer du moyen âge à l'ère industrielle. Comment vérifier que les développeurs n'ont pas mijoté un plat de   spaghetti ? (qualité du code, audit, style, ...) 

Bien évidement, il faut compiler des sources. Si un projet ne peut pas être compilé complètement, il faut remonter rapidement l’information, pour que le code problématique soit corrigé. Un projet qui ne compile pas peut bloquer l’ensemble des développeurs qui travaillent dessus. 

Puis passer  les tests unitaires et générez un rapport avec les messages liés aux tests en  échecs. 

Préparer les artefacts de déploiement de manière à ce que l'application puisse être exécutée dans l'environnement cible.  

Déployer l’application sur le serveur d'application cela peut se résumer à une simple copie des artefacts de déploiement. Tous les fichiers de log doivent être activés pour pouvoir analyser si besoin est les erreurs de déploiement. Ce qui parfois peut se révéler difficile à réaliser tellement les facteurs peuvent être nombreux. 

On termine par les tests fonctionnels correspondant aux Use Case. Un rapport structuré doit être généré. 

Et qu'est ce qu'on oublie ? La génération automatique de la documentation de développement, qui est faite à partir des informations présentes dans le code source. C'est toujours plus facile de développer quand on a sous la main une version à jour de la documentation. 

À la fin de l’exécution de toutes ces actions, la plate-forme doit envoyer des messages aux personnes concernées par les problèmes relevés. Ces messages ne doivent pas se transformer en spam, car ils deviendraient inutiles (personne n’y ferait plus attention). Il faut donc faire attention à remonter les vrais problèmes, et ne pas mettre tous les développeurs en copie sauf dans les cas nécessaires. 

La résolution des bugs remontés doit être lapriorité première d’une équipe de développement. C’est simple, si on continue à développer en sachant qu’il y a des bugs, on sait pertinemment qu’il faudra encore plus de temps et d’énergie pour les corriger, tout en risquant de devoir refaire les « sur-développements ». 

En bout de course, l’application déployée par l’intégration continue doit être accessible à l’équipe de test, qui peut ainsi procéder à ses vérifications complémentaires sans avoir à se soucier des étapes techniques en amont (compilation, packaging, déploiement). 

Mettre en place une plate-forme d’intégration continue est un tâche technique assez longue. Mais une fois que c’est fait, c’est à la fois un confort de travail et une sécurité dont on ne peut plus se passer. 

L’écriture des tests unitaire est quelque chose d’un peu fastidieux, qu’il est souvent difficile d’imposer à une équipe qui a pris de mauvaises habitudes. Un développeur ne voit souvent le code source comme seul élément constitutif de son travail, et oublie la documentation et les tests. Encourager l’écriture de tests unitaire est un travail de longue haleine sur lequel il faut maintenir une pression constante, sous peine de laisser prendre la poussière. Et un test qui n’est pas tenu à jour devient rapidement inutile. 

N'attendez surtout pas que les développements soient  commencés pour mettre en place la plate forme  d'intégration continue car vous risqueriez de "brûler du gaz" pour rien. Au contraire investissez dés le départ et soyez audacieux et innovateur, ce sont les clés du retour sur investissement. 

 

Voir aussi :  Bonnes pratiques des SI

Le blog de Rhona Maxwel consultante en urbanisation des SI



14/09/2014
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 705 autres membres