Las reuniones provocadas por un despliegue lento (2015)

El despliegue lento provoca reuniones

• El diseño de software es un ejercicio de relaciones humanas. Lo mismo ocurre con las demás habilidades que usamos en el desarrollo de software.
• La queja de un ingeniero de que hay tantas reuniones como para que no se pueda desplegar código puede deberse a un límite de capacidad de despliegue.
• Chuck Rossi observó en Facebook que la cantidad de cambios que se pueden manejar en un despliegue está fijada. Para tener más cambios, se necesitan más despliegues.
• Facebook ha aumentado su velocidad de despliegue en los últimos cinco años de semanal a diaria y a tres veces al día; además, redujo el ciclo de despliegue de su app móvil de 6 semanas a 4 y luego a 2 semanas.
• Los “cambios por despliegue” son una métrica rígida; puede mejorarse, pero toma tiempo. Si los cambios actuales superan el umbral, se deben reducir la cantidad de cambios.
• Si aumenta la sobrecarga organizacional, se inicia un bucle de retroalimentación positiva: menor carga de trabajo -> mayor presión -> más errores -> menos cambios por despliegue -> más sobrecarga -> menor carga de trabajo.
• Para procesar más cambios, debes aumentar la capacidad de despliegue. Puedes hacerlo reduciendo el ciclo de despliegue o aumentando los cambios por despliegue.
• Los intentos por reducir la sobrecarga pueden terminar, finalmente, en más reuniones. Eso limita la tentación de desplegar demasiado código.

Diseño de software: Tidy First?

• El diseño de software es un ejercicio de relaciones humanas. Una forma de mejorar las relaciones es mejorar las habilidades.

[roxie]

Esta opinión está bien.

[GN⁺]

Opinión de Hacker News

• Aunque es importante mejorar las pruebas y los aspectos organizacionales para reducir el riesgo de despliegue, no es el único enfoque

  • Es más efectivo reducir la cantidad de cambios por despliegue
  • Desplegar cambios pequeños con frecuencia permite entregar valor más rápido y experimentar fallos menores
  • Si se combina con despliegues canario y lanzamientos graduales, el despliegue deja de ser un gran riesgo
  • Los estudios de DORA y los libros Accelerate, The Phoenix Project y The Goal respaldan este enfoque

• Quiso explicar el concepto de "alfabetización en software"

  • Significa la capacidad de una compañía para operar mediante software
  • Si los tomadores de decisiones no se enfocan en el código, la empresa carece de alfabetización en software
  • La empresa debe poder operar de una forma nueva

• Al hacer más largo el tiempo de pruebas en el pipeline de CI, se decidió centrarse en la recuperación

  • Se simplificaron las pruebas y se enfocaron en la recuperación, usando el despliegue canario como estrategia de despliegue
  • Esta fue una experiencia novedosa

• La organización puede obstaculizar la mejora del despliegue

  • Luchar contra la burocracia es imposible en la mayoría de las organizaciones
  • La lentitud en despliegues es un problema, pero no el único

• El miedo al cambio grande aumenta las pruebas

  • A menudo las reuniones se vuelven el objetivo
  • Se necesita asesoría sobre cómo conducir la gestión no técnica y el cambio técnico

• Pregunta por qué CloudFormation es lento

• Los microservicios permiten escalar horizontalmente la frecuencia de despliegues

• El rendimiento del software, es decir, el rendimiento humano, importa

  • Para iteraciones rápidas y reducción de riesgo se necesita automatización de pruebas rápida

• Los despliegues rápidos provocan reuniones de respuesta a incidentes