Les déploiements lents provoquent des réunions (2015)

Les déploiements lents provoquent des réunions

• La conception de logiciels est un entraînement aux relations humaines. Les autres compétences utilisées en développement logiciel le sont aussi.
• Le fait qu’un ingénieur se plaigne de ne pas pouvoir déployer du code à cause du trop grand nombre de réunions peut résulter de limites de capacité de déploiement.
• Chuck Rossi a observé chez Facebook qu’un nombre fixe de changements peut être traité par déploiement. Pour en avoir davantage, il faut davantage de déploiements.
• Facebook a fait passer la cadence de déploiement des 5 dernières années d’une par semaine à quotidienne, puis à trois fois par jour, et a réduit le cycle de déploiement de l’application mobile de 6 semaines à 4 semaines, puis 2 semaines.
• Le nombre de “changements par déploiement” est un indicateur peu élastique, mais qui peut être amélioré. Si le nombre de changements dépasse le seuil actuel, il faut réduire la quantité de changements.
• L’augmentation de la surcharge organisationnelle déclenche une boucle de rétroaction positive : baisse de la charge de travail -> hausse de la pression -> hausse des erreurs -> baisse des changements par déploiement -> hausse de la surcharge -> baisse de la charge de travail.
• Pour traiter plus de changements, il faut augmenter la capacité de déploiement. Pour cela, il faut réduire la fréquence des déploiements ou augmenter le nombre de changements par déploiement.
• Les tentatives visant à réduire la surcharge peuvent finalement mener à des réunions. Cela permet d’éviter de trop vouloir déployer de code.

Conception logicielle : Tidy First ?

• La conception de logiciels est un entraînement aux relations humaines. Améliorer ses compétences techniques en est une manière d’améliorer les relations.

[roxie]

C'est une bonne opinion.

[GN⁺]

Avis Hacker News

• Réduire le risque de déploiement en améliorant les tests et les aspects organisationnels est important, mais ce n’est pas la seule approche

  • Réduire le nombre de changements par déploiement est généralement plus efficace
  • Déployer de petites modifications plus fréquemment permet de livrer la valeur plus vite et d’encaisser des échecs de petite taille
  • Combiné aux déploiements canary et aux déploiements progressifs, le déploiement n’est plus un risque majeur
  • Cette approche est soutenue par la recherche DORA, ainsi que par Accelerate, The Phoenix Project et The Goal

• Ils ont voulu expliquer la notion de « software literacy »

  • Cela signifie la capacité d’une entreprise à fonctionner avec du code
  • Si tous les décideurs ne se concentrent pas sur le code, cela traduit un manque de software literacy
  • Une entreprise doit être capable de fonctionner avec de nouveaux concepts

• Dans la pipeline CI, le temps des tests ayant été jugé trop long, ils ont décidé de se concentrer sur la reprise

  • En simplifiant les tests et en se concentrant sur la reprise, ils ont utilisé le canary comme stratégie de déploiement
  • Cette approche a constitué une expérience nouvelle

• L’organisation peut empêcher l’amélioration des déploiements

  • Lutter contre la bureaucratie est impossible dans la plupart des organisations
  • Les déploiements lents posent problème, mais ne sont pas le seul problème

• La peur des changements de grande ampleur augmente les tests

  • Les réunions ont tendance à devenir une finalité en soi
  • Des conseils sont nécessaires pour conduire le changement technique face à des managers non techniques

• Question sur la raison pour laquelle CloudFormation est lent

• Les microservices permettent de faire monter en charge horizontalement la fréquence de déploiement

• Les performances logicielles, c’est-à-dire la performance humaine, sont importantes

  • Pour aller plus vite en itérations et réduire les risques, il faut automatiser rapidement les tests

• Les déploiements rapides provoquent des réunions de gestion d’incidents