Détail de notre process de mise en production

Conçu pour compenser les difficultés connues

This article is also available in English.

J’ai introduit notre process de mise en production dans un précédent article, avec un focus particulier sur comment nous l’utilisions comme outil de management visuel.

De 1 release par trimestre à plus de 2 par semaine

Dans cet article nous allons nous pencher sur le process en lui-même, en mettant en valeur ses éléments intéressants.

Quelles sont les étapes du process ?

Pour aider Google à indexer le contenu de cette image, voici une transcription des différentes étapes du workflow :

1. Planification de release : définir le périmètre de la release
2. Estimation de la date de mise à disposition en pre-prod pour validation par les partenaires
3. Communication aux partenaires de la date estimée de mise en pre-prod
4. Développement des tâches et User Stories individuelles qui deviennent “done”
5. Parfois, on découvre durant le développement que le périmètre de la release doit être modifié
6. Dans l’hypothèse d’une évolution du périmètre de la release, il faut alors ré-estimer la date de disponibilité en pre-prod, et la communiquer à nouveau aux partenaires (= retour à l’étape 3)
7. Tous les développements sont terminés ! Le périmètre de l’itération est complet
8. Evaluation du risque de mettre en production la release
9. Définition de la stratégie de gestion du risque
10. Blocage des versions des dépendances
11. Déploiement en pre-prod
12. Vérifier que la pre-prod est OK et q’il y a bien le contenu de la release
13. Exécution de la stratégie de gestion du risque
14. Communication aux partenaires que tout est prêt pour recette en pre-prod
15. Si des bugs sont découverts (que cela soit par l’équipe ou par les partenaires), alors on les corrige ! Cependant, cela veut dire qu’on a effectué de nouveaux développements et on retourne alors à l’étape trois. On doit bien entendu tenir les partenaires au courant et refaire toute une boucle avec gestion de risque et un nouveau déploiement en pre-prod
16. Avant de passer à la mise en production proprement dite, s’assurer que l’on sait comment faire un rollback et que la méthode/l’outil fonctionne bien
17. Super ! Tout est prêt pour la mise en production
18. Commencer avec une mise en production partielle
19. Terminer la mise en production en déployant la release à l’intégralité des utilisateurs

Vous l’avez sans doute constaté, il est ici question d’un process de haut niveau, axé sur les personnes. À côté de cela les développeurs suivent bien entendu des règles strictes de gestion des branches, des tags… Mais ce n’est pas le sujet dans ce process.

Communiquer et se synchroniser, autant que nécessaire

Un élément récurrent dans ce process est l’accent donné à la communication, faire en sorte que l’équipe est bien synchro avec les partenaires. C’était en effet un point de douleur historique. Ce process aide donc l’équipe à avoir une bonne communication.

On n’oublie pas de communiquer !

Communiquer n’est pas forcément notre activité favorite, mais il faut le faire, alors merci du rappel.

Partager l’information qui permettra de prendre des décisions

• Nos partenaires vont devoir allouer des resources pour valider la release en pre-prod, aussi les choses se passeront mieux s’ils savent en avance quand la validation sera à faire.
• Que devraient-ils vérifier ? Si on ne partage pas le changelog et l’analyse de risque alors ils n’ont guère d’autre option que de tout vérifier.

Il faut prévenir tout le monde lorsque le plan change

• On a trouvé un bug ! Faisons leur savoir qu’il y aura un délai, ou que le bug est connu et que ne devraient pas le tester à nouveau, ou perdre du temps à nous le remonter.
• La disponibilité de la release candidate en preprod sera retardée. Dans la mesure où ils allouent des ressources en avance, faisons en sorte de leur donner cette information dès que possible pour qu’ils puissent mettre à jour leurs propres plans.
• On ne devrait jamais entendre “Ce n’est pas encore disponible ?” Nos partenaires devraient savoir quand cela sera disponible. Lorsque le plan change, nous devons partager le nouveau plan.

Suivre l’ordre de la stratégie de test

J’ai expliqué l’importante de la synchronisation avec nos partenaires dans la section précédente.

Fondamentalement, il est question de savoir qui teste quoi. Pour avancer sur le sujet, nous devions définir le périmètre de test de chacun, et appliquer ces tests dans le bon ordre. Certains appelleraient ce travail la définition d’une stratégie de test.

L’idée est que cela ne fait pas sens d’envoyer une release candidate pour validation à un partenaire si nous n’avons pas fini nos propres vérifications au préalable. Nous l’avons vécu à plusieurs reprises : nous sommes confiants dans notre travail (et parfois, nous sommes même pressés de passer à autre chose) alors on balance la release aux partenaires avant d’avoir terminer d’exécuter nos propres tests de non-régression. À pratiquement chaque fois il se passe l’une des deux choses suivantes :

• On trouve des problèmes qui doivent être corrigés, mais notre partenaire a déjà perdu du temps à valider la release candidate et va du coup devoir tout reprendre à zéro une fois que nous aurons corrigé les problèmes et déployé une nouvelle release candidate
• Nos partenaires trouvent des bugs et se rendent compte que nous les aurions trouvés si nous avions terminé d’exécuter nos propres tests avant de leur demander de commencer la validation

Dans les deux cas, cela va altérer notre relation avec nos partenaires puisque cela envoie le signal que nous n’apportons pas d’importance à leur temps. Une conséquence directe est qu’il sera plus dur de réserver rapidement leur temps pour valider nos releases candidates. Ce qui nous mène à un goulet d’étrangement dans notre tuyau de releases, et ce qui nous ralentit tous.

Essayer d’aller plus vite en gesticulant plutôt que de suivre le process en place mène à un ralentissement. Il n’est tout simplement pas possible d’aller plus vite que la musique.

Gestion de risque intelligente

Nous évitons autant que possible de faire une passe de no-régression complète.

Nous récupérons la liste exhaustive des choses qui ont changé, souvent appelé changelog, et à partir de là nous essayer de deviner ce qui est à risque.

Le but n’est pas de vérifier que le nouveau code fonctionne comme attendu ; plusieurs personnes sont déjà passées par là et l’ont testé dans le détail. Ce qui nous intéresse réellement c’est de vérifier les impacts potentiels du nouveau code. Nous appelons cet élément une analyse de risque.

À partir de cette analyse de risque nous déduisons :

• L’ensemble des scenarios de test qu’il faudra exécuter
• Quels appareils/OS/navigateurs devront être vérifiés
• Faut-il mettre en production simultanément sur tous les produits ou bien vaut-il mieux faire une ou plusieurs mises en production partielles sur un périmètre restreint d’utilisateurs pour pourvoir analyser incrémentalement l’impact des changements sur la production

S’assurer plutôt deux fois qu’une que les éléments connus pour partir en sucette ont bien fonctionné

Nous avons directement intégré les problèmes connus de notre outillage actuel dans les contraintes de fonctionnement du vaisseau. Le but n’est pas de se dire que nous n’essaierons pas de corriger ces problèmes, mais plutôt d’acter que ces problèmes ne seront pas corrigés immédiatement et aussi nous ferions mieux d’apprendre à vivre avec pour le moment.

Bloquer les versions des dépendances

… Car jusqu’ici, rien n’empêchait ces dépendances d’avoir une montée de version entre le moment où la release candidate est validatée en preprod et le moment où la release est poussée en production. Ce qui voudrait dire que ce que nous pousserions en preprod ne serait pas ce que nous avons validé.

Quelle pensée effrayante !

Par ailleurs le problème s’est réellement présenté avec des dépendances internes, mélangeant la production et les branches expérimentales ou de version de certains composants donnés. En effet, lorsque’on découvrait le problème, c’est comme si le monde s’effondrait.

Aussi, en attendant de meilleurs moyens de gérer les versions des dépendances, nous nous contentons de s’assurer que les versions sont bien bloquées à la main.

Vérifier la preprod

… Car de temps en temps (et parfois même, de nombreuses fois d’affilée) les scripts de mise en production fonctionnent pas ou mal. Mais aussi parce qu’il arrive que les choses ne se passent pas comme prévu.

Dans la mesure où l’environnement de preprod est géré par une équipe externe “ops”, la correction des problèmes n’est seulement qu’en partie entre nos mains. Nous ne pouvons pas corriger ça immédiatement. Nous devons vivre avec pour le moment.

Alors, faisons en sorte de s’assurer que tout est bien OK en preprod et que la preprod contient bien la release candidate avant de procéder aux tests.

Gâcher du temps à tester la version précédente et remonter des bugs parce que les nouvelles fonctionnalités ne fonctionnent pas : c’est déjà arrivé à l’équipe dans le passé.

Le mot d’ordre est simple : faites cette vérification avant de dire que l’environnement de preprod est prêt, point final.

S’assurer qu’on sait faire un rollback

… Car précédemment nous n’avions aucune procédure fonctionnelle de rollback (à la place nous construisions et déployions à nouveau la version précédente), ce qui veut dire que d’annuler un nouvelle release était long. Ce qui voulait dire que casser la production impliquait un gros coût.

À l’inverse, si vous savez faire un rollback en quelques secondes, on peut alors adopter une attitude plus audacieuse. C’est une très bonne chose car souvent vous apprendrez au moins un ordre de grandeur plus de choses en production que vous n’avez appris précédemment. Retarder une mise en production “pour être sûr que rien n’est cassé” n’est rien d’autre que du temps gâché lorsque vous êtes un produit web, vous ratez des opportunités alors que le coût de se tromper est très faible.

D’une manière générale, cette étape est toujours importante dans le process même lorsque la procédure de rollback a été implantée. En effet il faut continuer de s’assurer qu’il est toujours possible de faire un rollback lorsque le process de déploiement ou l’outillage de build changent.

Faire ces trucs importants, aussi souvent que nécessaire

L’équipe doit faire preuve d’une extrême rigueur. C’est critique ou sinon l’équipe ne pourra jamais atteindre un quelconque niveau d’excellence.

Cela se voit dans le process, un changement de périmètre ou une correction de bug ramènent au début du process. Quoi qu’il arrive, vous devrez revenir en arrière et tout refaire à nouveau.

En particulier, lorsque vous corrigez un bug vous devez remettre en question la stratégie de gestion de risque : nous avons changé un peu plus de code, est-ce qu’il y a des impacts supplémentaires, et comment les gérer ?

Et à nouveau, bien s’assurer que les versions des dépendances sont OK. Et s’assurer à chaque fois qu’on déploie en preprod que l’environnement de preprod est OK.

À quoi ressemble le process désormais ?

Alors que l’équipe a beaucoup gagné en maturité, des éléments de ce process sont devenus obsolètes.

• Le focus sur la communication et la synchronisation avec les partenaires devient de moins en moins important car les adhérences avec les partenaires ont été nettement réduites.
• La planification devient également sans intérêt dans la mesure où l’équipe a graduellement progressé vers Kanban avec une stratégie de mise en production continue. C’est à dire que chaque User Story est mise en production individuellement dès que possible, plutôt que d’avoir un ensemble de User Stories qu’on regroupe dans la même release. Il faut toujours synchroniser plusieurs équipes qui partagent le même tuyau de mise en production ; ce qui est accompli en partageant entre toutes les équipes le même board Kanban pour la partie mise en production.
• L’outillage a rendu impossible d’avoir des versions de dépendances différentes entre les release candidates en preprod et la mise en production effective.

D’un autre côté…

• À l’heure actuelle la gestion de risque est toujours au cœur de comment l’équipe fonctionne, alors même que de plus en plus de tests sont automatisés. Peut-être qu’un jour il suffira de lancer la suite complète de tests automatisés plutôt que de cibler ce qui est à risque ? De même, la compatibilité sur les différents appareils deviendrait de moins en moins nécessaire puisque les suites de test seraient lancées automatiquement sur l’ensemble des cibles qui sont officiellement supportées. Mais nous n’y sommes pas encore.
• Les scripts de déploiement en preprod sont de mieux en mieux mais on ne peut toujours pas les considérer comme fiables.
• Il faudra toujours vérifier que la procédure de rollback fonctionne lorsque des changements sont faits aux process de déploiement/build.
• Faire des mises en production partielles semblent de toute évidence l’avenir, mais idéalement il faudrait le faire d’une manière beaucoup plus sophistiquée. La vision idéale correspond aux tests A/B invisibles pour l’utilisateur.

Envie d’aller plus loin ?

Cet article fait partie d’une série sur comment nous avons réussi à faire des mises en production quotidiennes. Pour voir les autres articles :

Notre recette pour des mises en prod’ quotidiennes

Cet article vous a plu ?

Abonnez-vous à moi via le bouton Follow pour être notifié des autres articles !

Et n’oubliez pas de m’applaudir 👏 et de partager l’article ! N’oubliez pas que c’est votre amour 💓 qui me fait mettre autant de cœur à l’ouvrage.

Merci 😄