Picorer ce qu’on déploie

Déployer en production est un passage important dans le cycle de vie de notre application. Au début, nous devions vérifier que notre environnement de pré-production (staging) était entièrement prêt à être déployé. L’équipe produit devait tester et valider tous les changements. De plus, nous faisions très attention à ne plus merger d’autres features en staging tant que la mise en production n’était pas effectuée. Avec l’augmentation de notre productivité et notre capacité à traiter des sujets en parallèle, nous avons cherché un moyen de déployer plus sereinement, plus aisément et de façon plus fiable. Voici ce que nous avons fait.

“red fruit in selective focus photography” by Darran Shen on Unsplash

Nos besoins

Pour bien aborder la situation, nous avons dressé une liste de besoins précis :

• Pouvoir sélectionner les features que nous voulons déployer
• Être rassurés sur la liste des fonctionnalités que nous sommes sur le point de déployer (avoir un résumé visuel)
• Être sereins à chaque mise en production
• Garder une trace de ce qui a été déployé (pour faire les release notes et corriger efficacement les bugs)
• Garder une liste de toutes les features qui ne sont pas encore déployées pour ne pas les oublier

Nos outils principaux sont github et zenhub, qui fournissent un tableau scrum avec nos User Stories et les fonctionnalités liées. Par dessus tout, il nous fallait une solution avec le moins de développement supplémentaire possible.

Le picorage

Dans un premier temps, nous avons considéré l’utilisation de feature-switch (la fonctionnalité est présente mais activée seulement si la configuration l’autorise) mais cela menaçait d’augmenter fortement notre temps de développement, d’ajouter de la complexité et la nécessité de nettoyer régulièrement le code des fonctionnalités totalement déployées. Nous avons aussi réfléchi à ne merger les pull request qu’une fois certains de vouloir déployer la fonctionnalité, mais cela nécessitait une validation du product owner difficile en amont.

notre équipe qui test la solution (“four white-and-brown eating fruits on the ground” by Wenni Zhou on Unsplash)

Finalement, nous avons décidé d’utiliser la fonctionnalité de picorage (cherry-pick) de git, entre la branche de développement et celle de déploiement pour sélectionner uniquement les commits correspondants aux fonctionnalités que nous désirons déployer. Ce n’est pas trop fastidieux car nous faisons un “squash and merge”, chaque feature se limite donc à un petit nombre de commits sur la branche de développement.

D’autre part, nous avons ajouté une branche intermédiaire sur laquelle nous picorons les fonctionnalités à déployer avant de merger cette branche sur la branche de production qui sera déployée. De cette façon, nous pouvons vérifier clairement que nous sommes sur le point de déployer uniquement les fonctionnalités désirées.

nos branches git

Pour nous assister, nous utilisons les outils suivants :

• Une feuille de calcul avec tous les commits de la branche de développement qui ne sont pas encore en production. Nous utilisons la commande git log --cherry-pick --right-only --pretty=format:%H_%s release...develop pour vérifier régulièrement la justesse de cette liste
• Deux colonnes spécifiques dans notre tableau agile (à mettre en production, en production) pour suivre les fonctionnalités à déployer.

On peut donc résumer notre process de cette façon :

• Décider de déployer des fonctionnalités qu’on met dans la colonne du tableau agile correspondante
• Noter tous les commits de la feuille de calcul qui correspondent à des fonctionnalités dans la colonne “à déployer”
• Réaliser le cherry-pick sur la branche release
• Faire une pull request de la branche release vers la branche production
• Déployer sur le serveur de production
• Pour terminer le process, nettoyer la feuille de calcul et on bouge les fonctionnalités déployées vers la colonne correspondante sur notre tableau agile

Les limites de notre processus

Parfois, on ne peut réaliser le picorage des commits souhaités car il y a des conflits. Il nous faut alors soit déployer aussi les fonctionnalités qui causent le conflit (si elles sont prêtes), soit attendre avant de déployer ce qu’on voulait. La plupart du temps, ce n’est pas un conflit lié à un problème de séparation de notre code métier, nous avons pris l’habitude d’anticiper ce genre de chose. En revanche, des conflits liés aux migrations de la base se matérialisant sur le numéro de version de notre schema.rb sont un vrai problème que nous aimerions régler.

Le mot de la fin

Nous étions insatisfaits de la rigidité de notre processus de déploiement. En particulier à cause de l’accumulation de fonctionnalités développées mais mises en attente par d’autres travaux encore incomplets. Nous avons opté pour un processus basé sur des outils simples (feuille de calcul, tableau agile) et la commande cherry-pick de git. Nous pouvons désormais sélectionner les fonctionnalités que nous désirons mettre en production, tant qu’elles n’entrent pas en conflit avec d’autres fonctionnalités plus anciennes en attente. Notre objectif est atteint, et même si le résultat n’est pas parfait, les frustrations sont bien moindres. Nous espérons un jour régler ces dernières, en particulier en ce qui concerne le numéro de version de la base.

Si vous voulez déployer de façon intelligente avec cherry-pick, rejoignez-nous

Captain Contrat recrute !