Utiliser la démarche Accelerate sans production est-ce possible ?

le 02/08/2022 par Cyril NATKOVITCH

Le but du récit

Il s’agit avant tout d’une réflexion et d’un partage autour du sujet suivant : Pouvons-nous utiliser la boîte à outils Accelerate quand nous n’avons pas d’environnement de production ? Y a t-il un intérêt à mesurer ? Que pouvons-nous faire ?

C’est un sujet qui questionne souvent nos clients et les Octos. Je vais vous partager mes convictions plus qu’une vérité absolue.

Quelques définitions

Production

Il s’agit de l'environnement où l'on met à disposition une fonctionnalité aux utilisateurs finaux pour obtenir un retour de leur part. Elle s’apparente dans ce contexte à une ouverture de service.

Accelerate

Il s’agit d’une étude qui provient du State of DevOps où les auteurs ont cherché à définir quelles étaient les caractéristiques d’une organisation technologique performante. Elle a déterminé un lien de causalité entre performance et delivery “les organisations les plus performantes dans leur delivery atteignent en moyenne deux fois plus souvent leurs objectifs que les organisations les moins performantes”. L’étude a donné un cadre de mesure et d’action :

Quatres indicateurs :
- La fréquence de déploiement (Deployment Frequency) => A quelle fréquence le code est-il déployé en production ?
- Le délai de déploiement (Lead Time for Change) => Combien de temps me faut-il pour envoyer une modification de code en production ?
- Le délai de réparation d’un défaut (Mean Time to Restore) => Combien de temps me faut-il pour restaurer un service inopérant ?
- Taux d’échec sur changement (Change Failure Rate) => Quel est le ratio de déploiement considéré comme des échecs ?
Et 24 capabilities réparties en 5 familles pour agir sur vos indicateurs :
- Product and Process (4 capabilités)
- Continuous Delivery (8 capabilités)
- Architecture (2 capabilités)
- Lean Management & Monitoring (5 capabilités)
- Culture (5 capabilités)
A quel moment mesurons-nous le delivery ?

Lorsque nous parlons de delivery il n’est pas toujours évident de définir à quel moment il commence. Dans le cadre d’Accelerate, il démarre de l’environnement de développement à la mise en production jusqu’à l’utilisateur final.

Pour aller plus loin sur le sujet, je vous renvoie à l’article écrit par Romain Pierlot sur le blog OCTO qui introduit l’approche Accelerate et les concepts sous-jacents.

Quel est l’intérêt de mettre en production ?

A la lecture de l’étude Accelerate nous retirons quelques enseignements :

La vitesse de déploiement conditionne l’excellence (l’amélioration continue),
Entre vitesse et stabilité de votre infrastructure il n’y a pas à choisir, il faut faire les deux. Si la qualité de votre applicatif n’est pas au rendez-vous car vous avez beaucoup d’anomalies en production avec des retours négatifs de vos utilisateurs finaux, il est évident qu’il faudra réduire votre périmètre d’action tout en gardant à l’esprit de mettre du rythme,
Aller le plus vite possible en production permet aux équipes d’obtenir une boucle de feedback rapide et de réfléchir aux prochaines étapes sur l’incrément de valeur que celle-ci souhaite réaliser,
Il s’agit aussi de s’assurer que les choix techniques que vous avez faits lors de l’ouverture de service pour vos utilisateurs finaux sont assez robustes et évolutifs pour répondre à la demande,
Mesurer pour agir.

Cette première mise en production sert de référentiel et permet aux équipes de savoir si elles vont dans la bonne direction. Il s’agit de l’une des raisons pour lesquelles les Octos sont intéressé(e)s par les projets avec une production, afin de se confronter à la réalité des utilisateurs finaux.

Si votre équipe n’a pas de problème ou ne s’intéresse pas à l’amélioration continue (la mise en action) alors les indicateurs ne vous serviront pas, quel que soit le contexte “hors production ou production”.

Vous pouvez noter que tout votre processus de delivery est vu au travers du prisme de la production dans la démarche Accelerate.

Est-ce toujours aussi évident d’aller en production ?

Au sein d’OCTO, nous restons convaincus que pour exploiter la boîte à outils Accelerate de la meilleure façon, nous devons impérativement aller en production et convaincre nos clients de l’intérêt à aller dans cette direction. Cela reste toujours notre volonté.

Mais avec l’expérience et les échanges avec les Octos, il s’avère que ce n’est pas aussi facile de déployer en production en fonction du contexte de nos clients :

Vous lancez un projet et vous n’avez pas de production dans l’immédiat.
La difficulté d’accès à l’hébergement que ce soit dans la même entreprise ou chez un prestataire de service qui vous oblige à faire du ticketing pour déployer.
La non disponibilité de l'environnement par l’équipe de développement pour des raisons de culture, “de sécurité”,...
La peur d’aller en production avec des impacts majeurs pour les citoyens dans des contextes gouvernementaux. Les déploiements se font via un pilote qui s'étend sur plusieurs mois avant de mettre en œuvre l’ouverture du service.
Des contextes réglementaires forts comme les banques par exemple qui souhaitent s’assurer qu'avant de déployer une nouvelle fonctionnalité elle n’aura aucun impact sur les comptes de ses clients
Le souhait d’ouvrir un service dans plusieurs mois, voire années pour correspondre à une date commerciale indiquée par le client aux utilisateurs.
Le fait de devoir faire des demandes de changement 3 semaines à l'avance.
Un nombre limité de déploiements par mois autorisé.

A partir de là, ça se complique :)

Certains vous diront que si n’avez pas de production, il n’y a pas d’intérêt à implémenter Accelerate car les préconisations et les actions mises en œuvre en amont de la production seront peut être différentes et l’impact sur votre produit pourrait avoir un effet négatif sur les utilisateurs finaux.
Certains de nos clients, ou des équipes, même s’ils comprennent la démarche, se demandent l’intérêt de le faire car ils n’ont pas de production.

Ma conviction : Je pense qu’il est tout à fait possible de s’améliorer en utilisant l’approche Accelerate même si nous n’avons pas accès aux utilisateurs finaux tout de suite.

Lorsque vous n’avez pas de production

Il existe des situations, comme indiqué plus haut dans ce paragraphe, où vous ne disposez pas d’un environnement de production. Accelerate s’appuie sur des pratiques issues du monde du devops, agile, lean qui impactent le delivery. Il serait dommage de s’en priver pour plusieurs raisons :

Les équipes définissent et mettent en œuvre des pratiques qui sont connues et reconnues et qui améliorent le processus de delivery (mise en place d’une CI/CD, d’un management visuel, de tests automatisés,...). Testez-les et mesurez ce que vous pouvez, afin de vérifier si vous vous améliorez ou pas.
En mesurant, les équipes s’obligent à s’interroger sur l’impact de leur choix pour s’assurer qu’elles vont dans la bonne direction ou pas en fonction du problème qu’elles souhaitent résoudre.

Est-ce qu’il s’agit de la meilleure situation et le reflet d’une réalité avec des utilisateurs finaux ? Non, il faut rester pragmatique, rien ne vaut la réalité avec des retours utilisateurs.

Est-ce que nous pouvons utiliser les indicateurs Accelerate lorsque nous n’avons pas d’environnement de production ?

Nous sommes d’accord que les indicateurs n’auront pas la même portée que lors d’une ouverture de service avec des utilisateurs finaux où avec l’accès en production sans ouverture de service.

Vous pouvez vous concentrer et déjà travailler sur la prédictibilité

Mesurer la fréquence de déploiement sur vos environnements d' intégration, recette, pré-production. Vous assurer de la répétabilité de vos gestes opérationnelles
Le lead time. Ici nous allons nous intéresser au temps mis par un commit de la phase de développement pour passer d’un environnement à un autre dans un contexte hors production

Pour la stabilité :

Vous pouvez regarder le nombre de fois où vous devez livrer à nouveau sur un environnement donné quand un problème survient.

Prenons quelques exemples :

Votre client souhaite déployer le plus souvent possible, mais vous constatez par la mesure qu’entre votre environnement de développement et votre environnement de recette, vous devez livrer à nouveau régulièrement car vous avez de multiples anomalies. Cela peut vous amener à vous poser des questions :
La qualité de mes développements est-elle conforme aux exigences spécifiées ?
La couverture de test est-elle suffisante et robuste ?
La description des users stories est-elle suffisante ?
La chaîne de CI/CD est-elle facile à utiliser par l’ensemble des équipes
La quality gate est-elle opérationnelle ? Dans notre cas, il s’agit d’un jalon à la fin de la chaîne d’intégration qui exige de respecter certains critères prédéfinis avant le passage à la phase de déploiement continue. Si vos tests ne respectent pas les exigences que vous avez définies, vous ne pouvez pas déployer votre code.
….
Vous n’avez pas d’environnement de production mais un environnement de pré-production qui doit être à l’image de la production (ce qui n’est pas toujours totalement le cas) : utilisez-le pour effectuer vos mesures.
Vous avez des environnements pilotes avec des utilisateurs pour tester votre produit bien avant d’arriver en production : n’hésitez pas à utiliser les indicateurs Accelerate et les capabilities pour vous améliorer.

Un retour d’expérience

Dans ma dernière mission chez un acteur majeur de l’énergie, nous n'arrivons pas à réduire le lead time en dessous de 20 jours.

Les développeurs ont spontanément décidé de prendre la main et de déployer sur l’environnement de recette. L’idée était qu’en cas de correctif il leur serait plus facile d’intervenir et de redéployer. C’est ce que nous avons mis en place. Un changement de comportement a été opéré puisqu'avant, ils laissaient l’équipe OPS déployer l'application sans se soucier de la partie infrastructure. Cette action a été faite conjointement entre les équipes de développement et les OPS afin que les développeurs deviennent autonomes.
Nous avons malgré tout vu que si les équipes de développement prenaient la main sur la partie infrastructure, ce qui était une excellente chose, l’impact sur le lead time restait très faible. Il n’y avait pas d'amélioration visible entre le passage de l’environnement de recette à l’environnement de Pré-PROD.

Un post mortem a été effectué avec l’ensemble des équipes pour identifier les axes d’amélioration.

Nous avons identifiés 3 problèmes :

L'environnement de développement était souvent instable et souvent utilisé par les OPS pour déployer des releases d’infra.
La qualité du delivery pouvait être améliorée en demandant aux Product Owners de valider les fonctionnalités le plus en amont possible afin de rencontrer moins de problèmes en environnement de recette.
Les équipes de développement se sont aperçues que les tests dans la phase de développement pouvaient être améliorés afin de stabiliser l’environnement de recette.

L’équipe a pris plusieurs actions suite aux REX et nous sommes passés de 20 jours de lead time à 10 jours.

Est-ce que nous aurions pu nous améliorer sans Accelerate avec ou sans un environnement de production ? Je pense que oui, mais cela aurait pris beaucoup plus de temps.

J’insiste à nouveau, tout ceci vous permettra de mettre des bonnes pratiques au sein de vos équipes (métiers et développement), de dérisquer des sujets (organisationnel, méthodologique, techniques) mais ne reflète pas votre environnement de production avec le comportement de vos utilisateurs finaux.

Pouvons-nous dérisquer l’environnement de production ?

Il est tout à fait possible de proposer des solutions à nos clients afin d’aller pas à pas vers un environnement de production.

L’équipe peut utiliser le feature flipping via kibana qui permet de pousser en production sans activer la feature. Vous n’avez plus de raisons que le code traîne dans un environnement hors production. Vous pouvez vérifier qu’il n’y a pas de régression sur d'autres features ou d'effet de bord en testant sur l'environnement “bac à sable” en activant ou non la feature
La possibilité de déployer en mode canary release. Cela permet de tester les dernières modifications réalisées (appelée version N+1) à une tranche de population restreinte avant de réaliser un déploiement général de cette version.
La possibilité de réaliser des pilotes avec des utilisateurs finaux avant de généraliser pas à pas l’ouverture de service.

Ce sont des exemples mais il est vraiment indispensable de considérer toutes ces solutions avant de protéger la production ou de limiter son accès au développeur et de responsabiliser les équipes de développement.

Tout ça pousse à gagner en confiance et à améliorer l'observabilité de la production.

La production devient un pilier pour l'équipe et crée un cercle vertueux on fait attention à ce qu'on pousse, les équipes sont naturellement poussées à être en maîtrise de la production et donc à corriger plus rapidement (mean time to repair ...) ou pousser son code en production pour l'éprouver. La maîtrise c'est clef pour être efficace, lorsqu'on l'obtient on a plus aucune de raisons de se mettre des barrières pour "protéger la production" ce qui ralentit les équipes et la livraison de valeurs aux utilisateurs et on cherche maintenir cette confiance / maîtrise des équipes.

Conclusion

Je pense que nous serons tous d’accord pour dire que l'idéal est d’avoir un environnement de production et d’être au contact des utilisateurs finaux. Cela nous permet de confirmer ou non nos hypothèses de travail. Une fois notre premier incrément mis en production il devient notre référentiel car dans le cas contraire vous êtes dans l’hypothèse. Cela doit être la priorité pour nos clients et les Octos.
Si nous pouvons convaincre notre interlocuteur de mettre en place pas à pas un environnement de production avec les équipes alors c’est parfait et l’article vous propose quelques solutions.
Si nous n’avons pas moyen de mettre un environnement de production ou d’y accéder, je pense qu’il est toujours possible de se servir des métriques Accelerate et les capabilities afin de nous améliorer collectivement, d’instaurer des bonnes pratiques et de tirer des enseignements. Comme indiqué, ils devront être révisés au moment du déploiement en production.