La démarche de qualité logicielle au coeur des développements

La qualité est au coeur de la société Isogeo, qu’il s’agisse des expertises ou des développements produits. Cette qualité se traduit dans de multiples processus que nous allons aborder dans cet article.

L’intégration continue (Continuous Integration) est en place chez Isogeo depuis plus de 2 ans ; ce qui a été un excellent moyen de mettre sur le marché des versions cohérentes de nos composants backend au fil du temps (API essentiellement). Notre principale réussite en 2014 sur ce domaine a été d’intégrer nos composants frontend (application principale) dans le même processus. C’était un réel défi car les technologies utilisées ne sont pas les mêmes (Javascript vs .NET).

Les processus en place

Notre objectif pour 2015 est d’aller plus loin encore et d’améliorer notre pipeline de déploiement (Deployment Pipeline) pour : 1) assurer une meilleure qualité globale de nos outils et solutions et 2) fournir une disponibilité toujours croissante de notre plateforme. Nous voulons tester plus, plus systématiquement et se rapprocher d’une livraison continue (Continuous Delivery) de notre plateforme.

Intégration continue

La première et plus importante étape de l’intégration continue est la gestion des révisions : chaque projet est enregistré dans un dépôt Git. Chaque dépôt est surveillé par un serveur de compilation (build server) qui est en charge d’assurer que les développeurs intègrent un code compatible (Développement Continu) et qui créé des paquets complets qui peuvent être déployés toutes les nuits (Nightly build).

Pour chacune des modifications de code (commits), l’intégration continue s’assure que :

  • le code source est cohérent, c’est-à-dire qu’il ne doit pas casser le processus de compilation de l’application. Cela permet d’assurer que les versions de l’application synchronisées en local ne posent pas de problème aux autres développeurs.
  • l’application en sortie correspond à des critères de qualité basiques et qu’elle doit :
    • passer tous les tests unitaires ;
    • répondre aux chartes internes qui s’appuient sur un ensemble d’outils dédiés (FxCop or JSHint).

Tous les développeurs sont chargés de surveiller l’état de l’intégration continue et corriger immédiatement le moindre problème.

Continuous Build

La configuration du serveur de compilation peut être simple si l’on observe quelques bonnes pratiques comme :

  • des conventions qui définissent comment sont organisés les dossiers des projets. C’est également très important pour les développeurs qui peuvent ainsi passer d’un projet à un autre sans perdre leurs repères.
  • les gestionnaires de paquets permettent de gérer facilement les dépendances (NuGet ou npm). L’une d’entre elles est un ensemble de scripts commun à tous les projets qui assure la cohérence globale et le respect des conventions sus-mentionnées. Le code source de ces scripts est librement accessible sur GitHub.

Compilation quotidienne

La compilation quotidienne (Nightly Build) est la suite logique de l’intégration continue. Déclenchée toutes les nuits, elle repasse par les mêmes étapes et en plus :

  • elle crée un paquet déployable pour le projet, c’est-à-dire à même d’être déployé sur l’ensemble de nos plateformes (Integration, QualityAssurance et Production) en adaptant seulement la configuration ; la technologie utilisée pour générer ces paquets est Microsoft Web Deploy qui est tout à fait adaptée à ce genre d’usage.
  • elle déploie ensuite automatiquement la paquet sur la plateforme d’intégration. Auto-hébergée à Isogeo, cette plateforme peut être utilisée par les développeurs et les testeurs notamment pour s’assurer que les différents composants assemblés forment toujours une plateforme cohérente.

Nous avons également une plateforme de recette hébergée sur Windows Azure (tout comme la plateforme de production). Elle est utilisée pour tester la plateforme en conditions réelles avant la sortie d’une nouvelle version, tous les 3 mois. La plupart des composants déployés sur Windows Azure utilise également la technologie Microsoft Web Deploy, mais notre API requiert d’être packagée dans un format Azure spécifique. Nous utilisons donc un autre ensemble de scripts pour générer manuellement ces paquets à partir du serveur de compilation.

Nightly Build

Pour le moment, les tests exécutés sur ces plateformes sont manuels. Mais une fois déployées, les plateformes sont automatiquement surveillées :

La route à parcourir

Nos procédures actuelles facilitent grandement la mise en production d’une nouvelle version et nous permettent d’être assez confiants sur tout le processus. Mais il y a encore de nombreuses pistes d’améliorations à apporter sur certains points pour monter d’un cran la qualité de notre plateforme : nous avons besoin de monter en puissance sur les tests automatisés et de nous débarrasser des résidus d’opérations manuelles dans le processus de déploiement.

Tests automatisés

Le principal objectif pour les évolutions à venir est d’améliorer la qualité et la couverture des tests actuels via :

  • plus de tests unitaires sur tous les composants. C’est un processus permanent et de longue haleine ;
  • des tests automatisés d’intégration de notre API. Le principal effort réside dans la création d’une base de données dédiée aux tests de nos différents cas d’usage. Nous nous intéressons de près à des services comme Runscope.
  • des tests automatisés d’intégration de nos applicatifs. Le prérequis est le même : une base de données de test. Une fois satisfaits, des outils tels que Selenium devraient convenir à nos besoins.

Tous ces tests ne feront pas partie de l’intégration continue car ils ont beaucoup trop de dépendances: l’indisponibilité, pour une raison ou pour une autre, de la base de test ou de l’un des serveurs web ne devrait pas nous empêcher de compiler un nouveau paquet ou déployer un correctif, par exemple.

Déploiement automatisé

Nous avons également besoin d’un serveur de déploiement qui puisse automatiquement, à partir d’un ensemble de configurations et de paquets, déployer une nouvelle version de notre logiciel sur n’importe laquelle de nos plateformes (Integration, QualityAssurance, Production). Les principaux bénéfices de ce genre de plateforme seraient :

  • d’automatiser complètement le déploiement de notre solution sans nécessiter un haut niveau de compétence technique ;
  • permettre de faire tourner tout ou partie des tests automatisés d’intégration sur n’importe laquelle e nos plateformes.

Continuous Deployment

La route est droite mais la pente est rude (référence) ! Qu’importe, nous continuons d’avancer en intégrant les outils nécessaires et en instaurant ces nouveaux processus de façon à ce que nos utilisateurs puissent profiter d’une expérience toujours plus sereine sur Isogeo.

Cet article est basé sur une publication du 11 février 2015 en anglais de Mathieu Cartoixa, Directeur technique d’Isogeo.

 

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.