Accueil Le blog ebiznext
DevOps : Outils et méthodologie de mise en oeuvre sur un projet concret

DevOps

Constats

L’objet de ce post est de répondre à la question suivante : De l’idée à la mise à disposition de la fonctionnalité aux utilisateurs finaux, comment délivrer la fonctionnalité le plus rapidement possible.

Il est important de garder à l’esprit qu’un projet est livré uniquement une fois l’application en production. Nous préconisons à cet effet une démarche de delivery continu qui part des constats suivants :

Constat 1 : Le processus de delivery est intrinsèquement sujet à des erreurs

La production d’une release est un processus manuel. Les environnements  qui hébergent le logiciel sont construits manuellement par les équipes d’exploitation. Les logiciels tiers sur lesquels s’appuie l’application à mettre en production sont installés. L’application elle-même est copiée. Les données de configuration sont copiées ou alimentées au travers de la console d’administration du serveur d’application. Les données de référence sont copiées et enfin l’application démarrée petit bout par petit bout.

Le processus ci-dessus est d’autant plus fragile que le nombre de changements est important dans la livraison applicative.

Les équipes d’exploitation sont objectivées sur la stabilité des plateformes en production alors que les équipes de développement sont objectivées sur la capacité à produire de nouvelles fonctionnalités dans un délai réduit. Cette opposition dans les objectifs conduit à des tensions entre les équipes lors des mises en production.

Nous répondons à cet antipattern par l’automatisation complète du processus de déploiement, qui limitera les opérations manuelles de déploiement en développement / recette / production au choix d’une version et d’un environnement.

 

Constat 2 : Déploiement dans un environnement de staging / production une fois les développements terminés.

  • Les équipes de développement  sont au contact de la plateforme de production pour la première fois au moment du déploiement sur les plateformes de staging/production
  • La création d’un environnement proche de la production est couteux à installer
  • Les équipes de développement créent les installeurs, les fichiers de configuration, les scripts de migration de données et la documentation de déploiement et la communiquent à l’équipe d’exploitation sans avoir au préalable testé sur des environnements proches de la production.

Nous répondons à cet antipattern en intégrant les activités construction, déploiement, test et release au processus de développement.

 

Le delivery continu repose sur deux bonnes pratiques :

  • L’automatisation : En faisant un processus automatisé, on le rend reproductible et donc libre d’erreurs.
  • La fréquence : Plus l’application est déployée fréquemment, moins il y a de différences d’une release à une autre réduisant ainsi le risque de dysfonctionnement et facilitant le rollback.

Pour atteindre cet objectif de delivery automatisé, nous prévoyons la création d’un environnement aussi proche que possible que celui de production, sur nos infrastructures de développement.

 

Notre démarche de delivery continu

La gestion de la configuration

Mis à part les systèmes d’exploitation, tous les artefacts sont versionnés. C’est à dire aussi bien les composants applicatifs que les configurations des logiciels d’infrastructure. Nous sommes en mesure de reproduire un environnement y compris une version spécifique du système d’exploitation, le niveau de patch, ect …

Il nous est aujourd’hui possible de :

  • Déterminer les composantes logicielles d’une version (applicative & système).
  • Quelles sont les modifications réalisées par qui et quand et surtout pourquoi.

A cet effet, nous stockons la configuration des serveurs de développement dans un système de gestion de versions.

Les équipes de développement y stocker le code source, les tests, les scripts de base de données, les scripts de déploiement, la documentation, les librairies et les fichiers de configuration de l’application ainsi que le compilateur et les divers outils permettant de (re)construire le logiciel.

L’utilisation d’un système de gestion de version nous évite la prolifération des fichiers obsolètes que l’on n’ose pas supprimer par peur de ne pas pouvoir revenir en arrière. Le système de gestion de version permettant de restaurer toutes les données y compris celles supprimées. La conséquence est un environnement d’exécution bien plus propre.

Nous utilisons l’outil Puppet  pour le provisionning, la configuration et la gestion de patch, couplé à Git pour la gestion des versions de configuration d’infrastructure.

 

L’intégration continue

La Plateforme d’Intégration Continue (PIC) est un service d’industrialisation de la chaîne de production logicielle. Elle a pour objectif d’homogénéiser et de normaliser la structure des projets et de produire des métriques publiées sur un portail qualité qui offre une forte visibilité aux managers du projet. Sa finalité est d’intégrer périodiquement l’ensemble des modifications et de produire un livrable logiciel susceptible d’être déployé en production. Tout échec d’intégration (échec de compilation / de test unitaire / de recevabilité / NFR) est diffusé à l’ensemble des membres de l’équipe participant à la construction du logiciel. Une PIC ne doit jamais rester trop longtemps instable. La fréquence élevée d’intégration logicielle garantit un minimum de modifications d’une intégration et rend ainsi prédictible le délai de correction des anomalies d’intégration.

La plateforme d’intégration continue offre les services suivants :

  • Un système de gestion de versions qui permet le  partage de code source et la construction de releases logicielles.
  • Un référentiel de composants qui répertorie l’ensemble des composants utilisés dans le développement d’applications.
  • Des modèles de projet qui décrivent l’organisation en répertoires des projets. Des modèles sont fournis pour les types de projets suivants : Application Web et librairies (JAR).
  • Un service de compilation qui va à partir des sources du projet et des composants issus du référentiel, générer le projet cible conformément aux règles définies dans le modèle de projet.
  • Un service de vérification suivi qualité qui va dans la chaîne du service de compilation produire un rapport consultable au travers d’une interface HTML.
  • Un service d’exécution des tests unitaires qui va au travers de la chaîne du service de compilation exécuter les tests unitaires et les tests de couverture et publier un rapport consultable au travers d’une interface HTML.
  • Un service de vérification des dépendances entre packages /modules qui permet de visualiser au travers d’un rapport HTML les problèmes éventuels d’architecture et de conception applicatifs.
  • Un service d’exécution périodique des services ci-dessus et de publication des résultats sur un portail qualité.
  • Un service d’audit de la couverture des tests; Un minimum e 80% de couverture des tests est requis pour une acceptation en production.

 

La Plateforme d’intégration continue repose sur :

  • —  Un serveur d’intégration continue (Jenkins)‏
  • —  Un gestionnaire de configuration (Git) pour la prise en charge des versions des fichiers sources et de configuration.
  • —  Un gestionnaire de dépendances binaires (Archiva) pour prendre en charge la complexité liée à la très grande modularité des projets développés en java / Scala.

    • —  Le référentiel de dépendances est utilisé pour fournir les dépendances binaires au build, aussi bien sur le poste de développement que sur le serveur d’intégration
    • —  Il empêche l’utilisation de dépendances non référencés

PIC de développement

Le pipeline de déploiement

Le pipeline linéaire

Les méthodologies de conduite de projet s’en tiennent à la phase de conception (Pilotée par le P.O.) et la phase de réalisation (MOE). La phase de tests et déploiement  est en général traitée en aval. Cela amène à des livraisons qui donnent satisfaction en amont de la mise en production et provoquent le syndrome de la release-candidate : Le logiciel et la plateforme se découvrent tardivement et les réunions de crise se succèdent au rythme des patchs appliqués.

Pipeline llinéaire

Pipeline à delivery continu

La résolution de ce problème en aval passe par l’implication en amont des équipes de développement et de mise en exploitation. A cet effet l’ensemble de la chaine est automatisé autant que faire se peut. Toute correction d’anomalie devient immédiatement disponible à une mise en production.

Les équipes de développement et de tests déploient avec un modèle « pushbutton » en sélectionnant la version logicielle et l’environnement.

Les équipes d’exploitation une fois la version qualifiée, procèdent à la mise en production avec un modèle « pushbutton » également selon le modèle de déploiement approprié.

 

Modèles de déploiement proposés

Deux modèles de déploiement sont à privilégier, le déploiement en miroir et le déploiement incrémental. Dans ces deux modes, la continuité de service doit rester garantie et portée par l’architecture technique cible décrite plus haut dans ce document. Les deux modèles ci-dessous permettent un déploiement sans discontinuité de services à condition que le modèle de base de données soit compatible ascendant, ce qui est généralement le cas.

Déploiement en miroir

La plateforme de production héberge deux plateformes applicatives logiques PAL1 et PAL2 (généralement des VM mais pas nécessairement).  Le déploiement s’effectue sur une PAL pendant que l’autre est active, une fois le déploiement terminé les flux basculent sur la nouvelle PAL fraichement installée. Il est à noter que les sessions utilisateurs sont ininterrompues dans ce modèle.

Le retour arrière sur la plateforme consiste tout simplement à restaurer la PAL active à l’origine.

Ce modèle est adapté au CMS qui fonctionne en cluster avec un cache distribué et qui nécessite une version unique active à un moment donné sur l’ensemble des serveurs.

Déploiement en miroir

Déploiement incrémental

Ce modèle s’applique lorsque le nombre de PAL est important (plus d’une dizaine).  Dans ce modèle, les PAL actuelles sont remplacées par les nouvelles PAL une à une sans interruption de service. Cela signifie qu’à un moment donné, la nouvelle et l’ancienne version cohabitent en production.  Une compatibilité ascendante  des services est requise dans ces cas et une compatibilité descendante des informations de session est nécessaire, ce qui est généralement le cas avec les précautions d’usage (versionning des services et de la sérialisation).

Ce modèle permet d’observer le comportement de la nouvelle version en production pendant une certaine période avant d’opter pour le remplacement définitif de la version précédente.

Ce modèle est adapté aux applications métiers. Le diagramme ci-dessous illustre le déploiement en canari.

devops-canari

Démarche proposée

L’équipe de réalisation et les architectes techniques du client coopèrent dès le début du projet à la construction du logiciel qui devra s’exécuter d’abord sur un environnement de la production. La procédure de déploiement sur l’ensemble des serveurs devra être entièrement automatisée. Les bilans de tests de performance et scripts de performance paramétrables en fonction de l’environnement devront être également fournis. Nous proposons le processus suivant :

  • Production de l’architecture technique définitive
  • Création d’un environnement de développement proche de la production
  • Automatisation de la création de l’environnement de développement,  de son paramétrage et de l’installation des applicatifs
  • A chaque livraison d’itération :

    • Validation du script sur à l’environnement de production
    • Fourniture de la documentation associée
    • Fourniture des résultats des tests de performance et de scripts utilisés paramétrables

Ainsi au même titre que les équipes de recette, les équipes d’exploitation à la fin de chaque itération pourront recetter la capacité de l’application à s’installer automatiquement en production et à respecter les contraintes de performance en charge. Le diagramme ci-dessous illustre ce processus :

Organisation

Références

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))