Mise en ligne : méthode pour (semi-)industrialiser ses développements

En fin de semaine dernière, ce fut la mise en ligne de la V8 de notre [superbe] plateforme d’applications. Nous éditons/développons sur cette dernière plusieurs applications Web en mode extranet pour quelques milliers d’utilisateurs.

Ce qui peut-être intéressant, c’est d’expliquer les différentes étapes du développement d’une nouvelle version d’un logiciel à son déploiement le jour J, pas LA méthode, mais au moins une qui est utilisée depuis quelques années et qui s’avère efficace.

En préambule, le délai entre 2 versions est dans la mesure court (2, max 3 mois) afin de réduire au maximum le taux de bugs¹ et de faciliter la mise en ligne². Egalement, un gestionnaire de sources (VSS, SVN) est hautement recommandé lors de développements en équipe. Idéalement, la plateforme de validation/recette est à l’identique de la plateforme d’exploitation : si cette dernière a 3 serveurs alors la validation en aura 3, etc.

Phases entre une version V, et une version V+1 :

développement de la V+1

Le développement des évolutions d’effectue sur la branche de développement (plateforme de développement). Cette branche est continue, et elle est juste flaggué ou libellée (étiquette sous VSS) à chaque nouvelle version. La dernière étiquette est par exemple v7.3 (version V). On peut ainsi retrouver les sources d’une version d’il y a 5 ans si on le souhaite.

Chaque chantier ou projet est bien évidemment mené en mode projet.

Chaque développeur qui est chargé d’un chantier doit remplir au moins 2 fichiers :

• chaque modification de configuration est noté dans un fichier : ajout de clé, suppression, ...
• chaque modification du schéma de base est scripté (ALTER, CREATE, DELETE, ...)

phase de validation, recette – tests

Cette phase permet de valider les nouveaux développements, d’un point de vue fonctionnel (est-ce le besoin attendu a bien été développé), et technique (en gros…les bugs).

Une fois la planification d’un mise en ligne (mise en exploitation de la version V+1), les développements sont arrêtés au moins 2 semaines avant : plus d’ajout de code n’est toléré, la correction de bugs (pannes franches, performances) est la seule possibilité.

La plateforme de validation-recette est préparée à l’identique de ce que sera l’exploitation V+1. Plusieurs itérations peuvent être nécessaires, cette validation sert non seulement à recetter les applications mais aussi la mise en ligne qui aura lieu le jour J :

• on part d’une base de données à l’identique de l’exploitation (backup exploitation, restore sur validation), avec certaines données modifiées pour la validation (principalement les e-mails).
• déroulement du script SQL sur cette base
• déploiement des sources sur la plateforme de validation : utilisation d’un script avec des commandes XCOPY afin de recopier dans un répertoire de déploiement les application (web ou pas) à installer
• modification des configurations par application

Une fois la plateforme en place, la recette peut commencer.

A chaque ensemble de dysfonctionnements, bugs corrigés, un nouveau déploiement des applications devra être effectué, et recetter ce qui a été corrigé. Cette phase de validation est itérative, jusqu’à ne plus trouver…de bugs, même si le 0 défaut reste utopique.

mise en ligne

Les applications sont recettées, prêtes à être déployées sur la plateforme d’exploitation. Le jour J à telle heure est le jour de la mise en ligne de la nouvelle version.

Avant le jour J, nous établissons une todo list qui énumère de façon la plus exhaustive possible toutes les opérations qui seront à effectuer sur chacun de serveurs pour la mise en ligne le jour J. Par exemple :

frontal :

1. sauvegarde des configurations
2. sauvegarde des répertoires sources des applications Web (typiquement c:\inetpub\wwwroot)
3. pages de maintenance
4. mise en place des applications : copie manuelle dans les répertoires idoines ou exécution des setup pour les applications packagées
5. modification des configurations selon le fichier tenu lors des développements
6. etc.

sql :

1. backup des bases
2. déroulement du script de modification de schéma de base
3. copie des procédures stockées
4. etc.

serveur y :

1. tâche 1
2. tâche 2
3. etc.

Les tâches ne sont pas forcément linéaires, certaines seront effectuées en parallèle, certaines sont subordonnées à d’autres (page de maintenance avant les backups par exemple) : plusieurs membres de l’équipe participent au déploiement.

Cette todo list sert notamment à réduire au maximum la réflexion (ie : que dois-je faire précisément) durant la mise en exploitation, que celle-ci soit dirigée par des tâches à dérouler simplement. En effet, toute mise en ligne reste toujours stressant (je vous assure que d’arrêter une plateforme pour des milliers d’utilisateurs reste toujours impressionnant), donc elle doit être très préparée.

L’improvisation est anecdotique et doit être limitée. Cela évite d’entrer dans une routine qui conduit forcément à faire des erreurs : malgré des dizaines de mises en ligne, le stress est toujours présent et doit le rester pour garder toute vigilance lors d’une mise en ligne.

L’heure arrêtée pour la mise en production, nous déroulons les grandes phases pour une mise en ligne réussie.

• upload des sources (script de déploiement xcopy + FTP) sur le serveur
• page(s) de maintenance (‘le site XY est en cours de maintenance, veuillez nous excuser de la gêne occasionnée, bla bla’), un fichier App_offline.htm vous sera bien utile pour une plateforme .NET.
• déroulement de la todo list (backup bases, sites, scripts, ...).

Une fois toutes les opérations effectuées, nous pouvons remettre en ligne l’ensemble de la plateforme, et allumer un cierge

Normalement, avec les itérations de recette sur la plateforme de validation (test applications, test mise en ligne), nous avons jamais eu à revenir en arrière. Les seuls dysfonctionnements sont souvent liés à des questions d’optimisations³ (services Web, ORM, moteur de recherche, ...) qui se révèlent bien souvent qu’en exploitation (nombre de connexions plus élevées qu’en validation). Pour éviter cela, nous pourrions stresser la plateforme de validation, c’est à dire de simuler un grand nombre d’accès (avec ab) afin de relever les problèmes à ce stade le cas échéant.

La plateforme étant rouverte, nous effectuons des tests unitaires (manuels) sur les différentes applications, sur les grandes fonctionnalités, et sur les nouvelles. Certains batchs sont également lancés en mode simulation.

l’après mise en ligne

Nous laissons au moins 2 jours avant de flagguer, voir si nous avons des retours de dysfonctionnements de l’application (notifications des erreurs d’applications) ou directement par le support. Pendant cette durée, les développements restent figés (ie : personne n’écrit de code).

Une fois que nous estimons que la version est stable, ou du moins qu’il n’y a pas de pannes franches qui font tout planter, nous finalisons la version :

1. libellé (flag) de la version courante sur le gestionnaire de sources (VSS) : on libelle la racine de la version mise en exploitation (v8 par exemple, branche d’exploitation) : cela a pour but de créer une branche à l’identique de l’exploitation : à ce stade, les développements peuvent reprendre sur la branche historique de développement.
2. mise en place d’une station avec l’extraction (grâce au libellé précédent) des sources à l’identique de l’exploitation (branche exploitation), et de la solution Visual studio prête. Cette image de la plateforme d’exploitation (sources, bases de données) servira uniquement à la correction de bugs (fix), correctifs déployés sur l’exploitation. On y gagne en efficacité d’avoir une station dédiée à la correction. Les correctifs sont bien sûr répercutés sur la branche de développement.
3. rapatriement d’une image de la base de données d’exploitation : servira à la station précédente.

conclusion

Comme on peut le voir, le développement logiciel est affaire de rigueur et de professionnalisme, peu de place ici à l’improvisation sauf cas d’urgence (correction d’un gros bug bloquant par exemple). Un seul objectif : descendre au maximum le risque de dysfonctionnements, et d’arrêt des services, pour la plus grande satisfaction des utilisateurs, enfin, nous l’espérons.

Et comme j’aime bien quantifié, depuis le dernier décompte du nombre de lignes de code, nous passons de 219 000 à 221 000, soit +2 000 lignes de code (C# + HTML (aspx) + JS). Cela reste négligeable en regard des nouvelles fonctionnalités apportées. Ceci peut s’expliquer par le refactoring automatiquement fait sur le code existant, en plus de développer de nouvelles fonctionnalités. Le refactoring consiste à revoir le code, en le factorisant, en fédérant toujours plus les services (approche SOA), et éviter ainsi la répétition de code (principe DRY).

¹ très lié au nombre de nouvelles fonctionnalités (fonctionnelles, ou techniques)

² du changement des schémas de base de données, à la modification des configurations, ou tout simplement au déploiement des applications.

³ ou plus récemment, d’un problème lié au composant RssToolkit et à sa méthode de cache qui semble poser problème en exploitation (vraisemblablement un effet de bord de l’anti-virus).