¿Sigue vigente el “Read-Only Friday”?

Definición de Read-Only Friday

Un clásico del área IT es que el viernes sea un día en donde hay menos actividad de “teclado” y mucho más trabajo de equipo. Es un dia donde se refuerza mucho las actividades como teambuilding, capacitaciones y donde muchos devs salen de sus topo-cuevas para socializar con otras personas. Se discuten planes de fines de semana… viajes, paseos, actividades, visita a familiares… eventos que podemos disfrutar gracias al “Read-Only Friday”.

¿Que es Read-Only Friday? Pues, en el ámbito de IT se considera que el viernes no deberíamos subir ningún cambio ni hacer ninguna modificación a los entornos productivos. El viernes no se toca nada para que nadie deba trabajar horas extras el fin de semana o debamos quedarnos trabajando hasta tarde para arreglar el error o tener que restaurar un backup.

Pero cuidado mis cielas! Hoy contamos con metodologías, herramientas y soporte de otros equipos que deberían al menos poner en duda este concepto.

• La implementación de Blue-Green deployment nos permite desviar tráfico desde nuestro servidor productivo(blue) a un nuevo servidor productivo (green). Pudiendo hacer un deploy sin perder el entorno que antes estaba funcionando.
• Continuous Integration / Continuous Delivery nos proporciona herramientas para un deploy controlado con test automatizados y control de código eficiente(Hola SonarQube!)
• Y finalmente el viejo y querido Backup pre-deploy que a más de uno ha salvado de muchos problemas.

Pero entonces, ¿Conviene hacer deploy un viernes? si… pero no…

Aun con todas estas herramientas y equipos que nos colaboran yo (al menos por el momento) sigo pensando que es mejor no realizar ningún deploy de funcionalidad un dia viernes. No por miedo a romper algo en producción si no por que utilizo ese tiempo para otras actividades como capacitaciones, teambuilding, planificaciones y demás tareas administrativas.

Si decidimos hacer Read-Only Friday debemos tener cuidado de no caer en los siguientes problemas.

Primer problema: Dejar los cambios a producción para el lunes “por si fallan” esconde una falencia en mi circuito de Testing/QA. Si no realizo cambios un viernes por que tengo dudas de si van a funcionar, debería trabajar para tener la certeza de que no va a fallar en lugar de evitar hacerlo un viernes.

Segundo problema: Falta de inversión en infraestructura para el negocio que estoy atendiendo. Si el funcionamiento de mi aplicación es crítica para el negocio debería tener una infraestructura que me permita tener un SLA acorde al valor que aporta.

Tercer y último problema (que se me ocurre a mi): No estamos preparados para ir a producción con cambios que realmente requieran romper un Read-Only Friday. Si existe una modificación/corrección que es realmente importante implementar puedo llevarme una sorpresa desagradable si mi equipo, infraestructura y metodologías no están preparadas.

En resumen, en mi humilde opinión, prefiero no hacer cambios en producción los viernes pero quiero tener la certeza de que si necesito puedo hacerlo o si lo necesito y, fundamental, que mi decisión no esconde una falencia en mis procesos o en mi equipo.

Que tengan un excelente fin de semana! Feliz Read-Only Friday! y….