Écrit par Clarence, développeuse

Après plusieurs livraisons compliquées  sur notre environnement de recette en fin de sprint, dont la dernière chaotique, j’ai commencé à échanger le Scrum Master, et avec des développeurs de l’équipe eux aussi frustré par ces dysfonctionnements, pour voir s’il est possible d’orienter la prochaine rétrospective dans l’amélioration de notre processus de livraison continue.

Je propose en amont de faire un état des lieux de notre processus actuel :

1.       Dev + tests unitaires en place

2.       Build automatique à la demande avec Jenkins (avec mail en cas d’erreur bloquante)

3.       Récupération manuelle du build par ftp

4.       Mail pour informer tout le monde que le service va être coupé

5.       Arrêt du service en recette manuelle en journée

6.       Archivage manuelle de l’ancienne version

7.       Déploiement du nouveau build manuellement

8.       Redémarrage du service

9.       Tests d’intégration manuels (une demi-journée)

10.     Mail pour informer tout le monde que le service est accessible

Voici quelques-uns des retours de l’équipe :

Morgan (PO) : « Le temps d’indisponibilité de la plateforme de recette est un vrai problème pour moi lorsque je présente le produit à des parties prenantes, il me faudrait une plateforme stable en journée »

Kim : « La journée passée sur la livraison me semble à chaque fois une journée perdu »

Clarence: « Je suis quand même fier de nos 2 premières étapes de notre processus actuel qui sont automatisées et qui fonctionnent bien »

Noa: « Je n’ai jamais fait de livraison manuelle depuis que je suis arrivé et je n’ai vu aucune documentation sur le sujet »

Claude : « Nous avons aussi perdu plusieurs versions lors de l’archivage en manuel, l’erreur d’écraser l’ancienne version est vite arrivée. Je parle en connaissance de cause »

Swann : « Les tests d’intégration sont fastidieux à faire à la main, surtout avec nos sprints de 2 semaines. J’ai peur que cette lassitude baisse l’attention que l’on a lorsqu’on effectue les tests »

Louison : « On a une seule livraison par sprint sur l’environnement de recette, ce qui ne nous permet de tester au fil de l’eau et de faire des retours rapides »

Noa : « On veut livrer en production directement ? »

Charlie, notre Scrum Master nous remercie pour l’ensemble de nos retours, on essaye maintenant de regrouper un peu les problématiques, et voici les axes qui se dégagent :

1.       Disponibilité de la plateforme en journée

2.       Réduire le temps passé sur la livraison en recette

3.       Fiabiliser le processus d’archivage

4.       Monter en compétence et documentation du processus

5.       Livrer plus souvent

Pour chacun des points, nous cherchons diverses solutions qui pourraient répondre à la problématique :

1 – Disponibilité de la plateforme en journée

  • Livraison automatique la nuit (avec rollback si erreur)
  • Avoir deux environnements de recette (un disponible et un pour la livraison)

2 – Réduire le temps passé sur la livraison en recette

  • Automatiser toute la partie deployement/rollback avec tests manuels
  • Automatiser les tests en gardant la livraison manuelle
  • Tout automatiser

3 – Fiabiliser le processus d’archivage

  • Automatiser le processus pour éviter les erreurs humaines
  • Avoir un gestionnaire de package (type Nexus) pour avoir l’historique de toute les versions

4 – Monter en compétence et documentation du processus

  • Chaque nouveau/nouvelle doit faire au moins une livraison manuelle sur un environnement de test pour comprendre le processus
  • Création de la documentation et enrichissement par chaque nouvelle personne dans l’équipe

5 – Livrer plus souvent

  • Dépendant du point 2, une fois le processus automatisé nous pourrons prévoir une livraison chaque nuit avec les devs de la veille

Viens donc mon moment préféré dans les rétros, le plan d’action 😊

Nous sommes tous d’accord que nous ne pourrons pas faire toutes les actions d’un coup, nous décidons donc de faire un MVP de notre livraison continue que nous améliorerons à chaque sprint. Cela fait sourire Morgan notre PO à qui l’on demande souvent de « MVPiser » ses besoins.

Notre 1er lot est donc le suivant :

  • Automatiser le déploiement sur le serveur de recette en journée
  • Initier la documentation

A titre personnel, je suis très content de cette rétro, où j’ai pu voir toute l’énergie de l’équipe à trouver des solutions à ce problème. Nous allons pouvoir améliorer notre quotidien en menant ces actions, et ça c’est chouette !