He visto esta consejo/chascarrillo miles de veces en memes de internet, tweets y foros. Un día incluso me encontré una oferta de trabajo que incluía la prohibición de hacer deploy en viernes como uno de los perks para trabajar en esa empresa. Parece ser que gran parte de la industria del software ha comprado la idea de que poner código en producción el último dia de la semana es una mala práctica de desarrollo.

Hasta cierto punto entiendo los motivos para evitar hacer un lanzamiento el viernes. Estos motivos pueden ser técnicos pero también tácticos: Cualquier lanzamiento de algo medianamente grande requiere una coordinación entre equipos para asegurarse que todos los frentes (comunicación interna y externa, soporte de usuario, monitorización, etcétera) quedan cubiertos. Esto no siempre es fácil el día antes del fin de semana.

‘No Friday deployments’ es un antipatrón

A pesar de todo, la frase “aquí no vamos a producción el viernes” me suena poco profesional y es un reflejo de falta de confianza en los procesos y herramientas de desarrollo internos. Sin duda es más fácil escudarse en la tradición o el mantra religioso tantas veces repetido que dice que ir a producción en viernes equivale a un fin de semana perdido arreglando la aplicación.

Evidentemente, nadie quiere perder su fin de semana arreglando bugs en producción, pero vamos a preguntarnos algunas de las razones por las que una aplicación puede fallar en el momento de pulsar el botón rojo:

  • Los procesos de testing o QA no fueron capaces de identificar los defectos.
  • Los sistemas de monitoreo fallaron o no fueron capaces de alertar del problema a tiempo.
  • Deshacer los cambios o lanzar un bugfix es un proceso dificil y/o largo.
  • El lanzamiento incluyó demasiados cambios, lo que hace casi imposible identificar la parte de la aplicación donde aparece el bug.

Cómo lanzar a producción un viernes y no morir en el intento

Los equipos más eficaces y productivos son capaces de lanzar código a producción múltiples veces al día gracias a una buena planificación y una inversión en buenas prácticas y herramientas usadas durante el proceso de desarrollo de software.

Esta lista no prentende sentar cátedra sobre cuáles son estas buenas prácticas, pero en mi humilde experiencia muchos de los problemas y riesgos antes mencionados se pueden mitigar con una correcta aplicación de las siguientes ideas:

  • Ve a producción frecuentemente. Cuánto más lo hagas, menos te dolerá cada vez.
  • Reduce el ámbito del lanzamiento. Es mejor lanzar muchas cosas pequeñas poco a poco que una grande de golpe, tanto para el negocio como para tu salud mental y niveles de estrés.
  • Escribe tests para tu código. No te vuelvas loco pero procura que las partes críticas de tu sistema estén bien cubiertas por tests.
  • Implementa un proceso repetible y confiable para generar artefactos y lanzar código a producción.
  • Si todo lo demás falla, asegúrate que es fácil volver a una versión anterior de tu aplicación.

Y en tu equipo, ¿váis los viernes a producción? Me gustaría conocer tu historia, dejame un comentario en Twitter y charlamos.