BreizhCamp : Déploiement continu en production par Claude Falguière

BreizhCampPour cette session de REX (Retour d’EXpérience) sur le déploiement continu en production, Claude nous offre son point de vue, appuyé sur deux retours d’expérience.

Je vous propose ici un résumé de cette session présentée au fameux BreizhCamp.

La session a tout d’abord débutée par une petite partie théorique en abordant différents concepts à savoir :

  • Le déploiement continu ne signifie pas obligatoirement “complètement automatisé” puisqu’il peut nécessiter quelques interventions humaines et que le terme continu introduit la notion de périodicité de livraison. Cependant, la notion de périodicité peut être très différente en fonction des équipes puisqu’elle peut être de plusieurs fois par heure à une fois par jour.
  • Le principe de Batch & Queue qui consiste à produire et livrer un lot et qui doit, dans un contexte de déploiement continu, rester exceptionnel et qui peut demander du temps ainsi qu’une livraison conséquente.
  • Le principe de Continuous Flow qui consiste à livrer au fur et à mesure, une ou plusieurs des features voulues. Cela permet d’avoir une bonne réactivité, peut être banalisé et qui cible une partie de l’application précise.

En fait, il faut bien différencier trois notions qui ont émergées au fils du temps :

  • Continuous Integration qui consiste à avoir à disposition un serveur d’intégration continue chargé de tester continuellement le code de manière intégré.
  • Continuous Delivery qui consiste à produire en continu quelque chose de déployable à destination de la QA.
  • Continuous Deployment qui consiste à déployer de manière continue en production.

[ndlr] Bien sûr, on constate qu’il existe une certaine dépendance entre ces différents concepts puisqu’il est difficilement envisageable de faire du Continuous Deployment s’il n’est pas possible de faire au préalable du Continuous Delivery qui dépend lui-même du processus de Continuous Integration.

En plus de cela, Claude nous a fait une petite piqûre de rappel sur différents sujets :

  • Le processus de déploiement peut être décidé selon deux processus :
    • Le promote manual qui est un déploiement décidé par Le Product Owner, le Scrum Master et/ou l’Operationnel.
    • L’autopromote qui correspond au déploiement continu.
  • Le test en production doit être fait au plus tôt et en incluant le smoke testing (qui consiste à vérifier que le système n’est pas KO) et peut être raisonnablement automatisé afin de déminer le processus. Il peut être fait :
    • Soit en faisant un déploiement progressif mais il s’agit d’une tache ardue avec une application J2EE/JEE.
    • Soit en faisant un déploiement dit green-blue qui est la solution la plus souvent choisie et qui consiste à sortir successivement les serveurs de la ferme afin de les tester.
  • Le principal intérêt du déploiement continu permet d’évaluer au plus tôt la qualité d’un développement ainsi que son apport en prenant en compte le retour des utilisateurs (qui peuvent être un sous-ensemble de ces derniers) soit en appliquant un procédé de beta-test (feature flippers ie. par utilisateur), soit en faisant du A/B Testing (feature flags ie. par environnement), c’est-à-dire en permettant la comparaison entre l’ancien système (ou feature) et le nouveau.
  • Le déploiement doit suivre un processus clair, doit être outillé et automatisé autant que faire ce peut, mais il doit aussi être surveillé en offrant la possibilité de l’outillage adéquate (journaux, monitoring, diagnostic) tout au long du cycle (ie. avant, pendant et après) et un rollback doit également être possible (et dans ce cas, il peut être une bonne pratique de sauvegarder les données de production au préalable).

Suite à ces petits rappels, Claude a entamé ses deux REX que je ne me risquerai pas de transcrire ici …

Conclusion

En conclusion, Claude nous a résumé les points essentiels pour la mise en œuvre d’un déploiement continu (points qui ont été détaillés pendant ses REX qui, je le répète, ne sont pas exposés ici) :

  • Il faut comprendre le processus et le simplifier quitte à ne couvrir que les 80% des cas les plus utiles et consommateurs.
  • Il faut outiller mais pas forcément automatiser.
  • Il faut avancer progressivement sans vouloir trop faire d’un coup.
  • Il faut tester le processus au plus tôt afin de vérifier l’installation et le tester dans les conditions réelles d’utilisation.
  • Il est possible d’utiliser des VMs pour tester au mieux le processus.
  • Il est important de prendre en compte les problématiques de rollback en cas de smoke testing peu concluant.
  • Il peut être utile de se tourner vers des solutions comme mCollective, RunDeck, Fabric, Capistrano pour gérer la multiplicité des serveurs.
  • Il est préférable de gérer les données de la base de données de manière incrémentale, de ne pas supprimer de colonnes et de faire en sorte qu’elle soit rétrocompatible au risque d’avoir quelques surprises…
  • Il est important de bien entrevoir la différence entre délivrer et déployer.
  • Le mouvement Devops offre une très bonne approche pour le déploiement continu.

Nombre de vue : 57

AJOUTER UN COMMENTAIRE