Architecting for Continuous Delivery

Retour sur la conférence d’Axel Fontaine (Snow Mountain Labs) à Devoxx Fr. Axel est un consultant freelance qui s’est spécialisé dans les problématiques de déploiement continu. Pour résoudre la question de la migration des bases de données il a créé le projet open source Flyway. 

Pour ceux qui ne connaissent pas le “continuous delivery” je vous laisse lire mon compte rendu de la session faite au Lyon Jug par Henry Gomez sur le mouvement devops en décembre 2011.

La présentation d’Axel n’est pas révolutionnaire mais elle a le mérite d’être très pragmatique et de fournir tous les éléments de base qu’il est important de prendre en compte en début de projet si vous voulez ensuite faciliter le cycle de vie de votre application et faciliter son déploiement rapide.

Le tour de salle en début de séance sur le nombre de mises en production, était symptomatique du problème de nombreuses d’entreprise. A la question posée “Est ce que vous faites au moins 1 mise en production par an ?” la salle entière avait la main levée. Puis au fur et à mesure que la fréquence de mise en production augmentait, les mains se baissaient de plus en plus vite. En dessous d’un délai d’un mois plus de la moitié de la salle avait la main baissée et pour des livraisons journalières il y avait moins d’une dizaine de personnes (sur 150). Donc forcément quand on parle des exemples des nombreux sites qui livrent plusieurs fois par jour, on peut se dire qu’il y a du travail à faire dans nos entreprises.

Pourquoi livrer vite? 
Quand on a mis en place un produit nous ne pouvons pas rester sur nos acquis et nous devons en permanence aller de l’avant en développant de nouvelles fonctionnalités. Quand la cible est floue il est important de valider au plus vite les hypothèses que vous émettez. Si vous pensez qu’une fonctionnalité peut intéresser des personnes, il faut vite la mettre en place pour savoir si elle leur apporte quelque chose. Plus vite vos hypothèses seront confirmées ou infirmées, plus vous gagnerez l’intérêt de vos clients et moins vous gaspillerez vos ressources. Une méthode est adaptée aux entrepreneurs qui veulent mettre en place ou faire évoluer leur produit, elle se nomme Lean Startup et je vous laisse lire le compte rendu que j’ai publié dernièrement sur le livre d’Eric Ries.

L’adoption des méthodes agiles a changé l’organisation des équipes de développements. Nous pouvons compter entre autre les tests unitaires, l’intégration continue avec le déploiement quotidien de la version en cours de développement, le suivi des sources dans un SCM. Le déploiement continu n’est que l’étape d’après où cette industrialisation touche maintenant les services de production. Les structures qui font du développement web sur le cloud ou sur des serveurs virtualisés peuvent trouver un fort intérêt à cette pratique.

Des freins qui n’en sont pas 
Dernièrement j’ai écouté « non nous ne pouvons pas passer au déploiement continu car si on fait ça on met des gens au chômage ». Je trouve que cette affirmation est fausse. Je pense qu’il y a un amalgame entre les effets de passer sur du cloud et les effets liés au déploiement continu. Sur une architecture PAAS oui on délègue l’administration des machines, de la base, des serveurs d’application à un prestataire mais on a toujours besoin de déployer. Ce n’est pas très intéressant de dérouler la même procédure papier sur x serveurs. Travailler sur le déploiement et la maintenance de scripts pour faire ces tâches ennuyeuses est beaucoup plus motivant intellectuellement et apportera plus de valeurs ajoutées à une entreprise. Car en automatisant l’installation, on peut aussi penser aux retours arrières, multiplier les mises en production sans risque permettant de répondre rapidement aux besoins des utilisateurs, avoir du temps pour travailler sur d’autres sujets comme les performances, la montée en charge….

Que faut t-il faire pour passer au continuous deployment ? 
La réponse à cette question était le sujet de la présentation d’Axel Fontaine. La transition vers le déploiement continu ne se fait pas en un claquement de doigt. Un logiciel ne fonctionnant pas sur un environnement de développement n’a pas les mêmes répercussions que lorsque l’erreur se passe sur un serveur de production. Si on accélère les déploiements on doit garantir ou plutôt limiter au maximum les risques.

Les tests sont primordiaux à tous les niveaux

• Small >> Tests unitaires du code 
• Medium >> Test d’intégration de l’application avec les différents composants comme la base de données 
• Large >> Tests fonctionnels. 

La mise en place des tests, l’enrichissement (à chaque bug), le maintien, l’automatisation est peut être coûteux mais c’est la seule garantie que vous avez pour rapidement savoir si votre application a des problèmes ou des régressions.

Les tests doivent être faits sur le poste des développeurs. S’ils sont satisfaisants, ils sont également exécutés sur un autre serveur d’intégration. La release intervient que si toutes ces étapes se passent sans problème. La release permet de produire un artifact (langage Maven), une version unique et figée de l’application. L’artifact est le livrable et la base de ce qui sera utilisé par le script d’installation. Il est important de toujours avoir une version figée de l’application pour faciliter les retours arrières

Quand on parle déploiement on peut diviser en trois parties: l’application, la configuration et les sources de données. La procédure de déploiement doit être formalisée par un script qui fera partie de la livraison et qui devra gérer la sauvegarde de la configuration actuelle en prévision d’un retour arrière.

Au niveau de la configuration on peut distinguer plusieurs cas.

• Elle peut être dépendante de l’environnement et dans ce cas le script de déploiement pourra accéder à un serveur qui fournira ces informations (webservice, serveur web…) 
• Les éléments peuvent être dépendants de l’application et de l’environnement. Dans ce cas vous devrez prévoir dans le package de livraison, plusieurs répertoires de configuration liés à l’environnement 
• Si la configuration dépend de l’application seule, vous devez l’inclure dans le code 
• Pour les données propres à la sécurité vous devez les externaliser dans le système de fichier par exemple et jouer sur les droits systèmes pour limiter les accès 

Pour la migration de la base de données il est préférable de choisir un outil permettant d’enchaîner les différents scripts de migration.

Blue green deployment 
Pour certaines applications il est difficile de couper le service pour une livraison ou pour des problèmes techniques. Dans ce cas on multiplie les instances de l’application. Pour livrer sans interrompre les utilisateurs, on peut se reposer sur un système blue/green. Quand on coupe le serveur blue, l’instance green reste opérationnelle. Quand le serveur blue est fini de migrer vers la nouvelle version on coupe la version green pour la mettre à jour.

Le déploiement blue green offre aussi un bon système de retour arrière en cas de problème sur la nouvelle version. 

Pour se simplifier la vie il faut faire la chasse au statefull. Quand ce n’est pas possible comme par exemple pour les sessions utilisateurs, le cache,....,  il est important de mettre en place des mécanismes de partage des informations entre les différentes instances de l’application.

Au niveau de la base de données si elle est partagée vous devez faire attention aux mises à jour. Vous ne pouvez pas par exemple supprimer des colonnes. Si vous devez le faire vous attendrez la livraison de la prochaine version

• Dans la version 1 j’ai deux tables T1 et T2 
• Dans la version 2 la table T2 n’est plus utilisée et le champ C1 de la table T1 est remplacé par le champ C11 ==> dans la livraison de cette V2 je ne supprime pas les éléments qui ne seront pas utilisés : la table T2 et la colonne C1. J’ajoute par contre la nouvelle colonne 
• Dans la version 3 quand je sais que plus personne n’utilise ces éléments, je les supprime

Au niveau des outils on peut en citer quelques uns

• Junit : tests unitaires 
• DbUnit : tests d’intégration avec la base de données 
• Maven ou gradlle pour gérer le cycle de vie de l’application : compilation, exécution des tests, packaging 
• Jenkins : ordonnancement des tests et des différents jobs 
• Git ou SVN pour la gestion des sources 
• Nexus, Artifactory pour la gestion des artifacts 
• Flyway, Liquibase… pour la migration de la base de données 
• … 

Conclusion

Si vous voulez revivre la conférence d’Axel Fontaine je vous laisse voir ce site http://axelfontaine.com/blog/continuous-delivery-parleys.html

Autre référence sur le blue/green deployment http://martinfowler.com/bliki/BlueGreenDeployment.html