Aprovechando que estamos ya en navidades, vamos a hablar de un tema que a muchos nos toca o nos ha tocado vivir en las empresas por estas fechas, El code freeze.
Índice
1 - Qué es el code freeze?
En el mundo del desarrollo de software llamamos code freeze (o congelamiento de código) a la práctica de no desplegar cambios a producción durante un tiempo, el cual normalmente suele venir en periodos específicos como son las navidades, o si tienes un evento que sucede una vez al año, como la semana del black friday, donde tienes mucho más tráfico que de costumbre.
1.1 - Por qué se hace un code freeze?
La teoría dice que hacer un code freeze minimiza el riesgo de que nuestra app se rompa en dicho periodo, y hasta cierto punto es correcto. Ya que si no despliegas nada, pues no va a petar por cosas que no existen. Pero el motivo principal es para evitar que se rompa cuando más personas están de vacaciones, por lo tanto hay menos ojos y manos para intentar arreglar un problema si lo hubiera.
Esto tiene muchísimo sentido en sistemas monolíticos, sobre todo de empresas grandes donde todos los equipos tocan el código de todo el mundo, y es, relativamente común, hacer un cambio y que a los 3 o 4 días otro equipo descubra que algo se les ha roto.
Pero dejando a un lado, este tipo de empresas/apps y los eventos que suceden una vez al año, ¿tiene sentido el code freeze?
2 - La realidad del code freeze
A pesar de que lo mencionado en el punto anterior pueda tener mayor o menor sentido, la realidad es que el code freeze perjudica más de lo que ayuda. Por qué si, tenemos esos casos concretos, donde puede ayudar. Pero, qué pasa con todas esas empresas, donde no tienen un sistema monolítico, sino que esta partido en microservicios, o mismamente no se va nadie de vacaciones en navidad, qué sentido tiene bloquear los despliegues? Ya te lo digo yo, ninguno, 0 (cero), nada de sentido.
Desafortunadamente esta no es la única pega que vamos a ver hoy. El code freeze sucede y todo el mundo sabe que va a suceder y por cuánto tiempo va a suceder, esto tiene dos pegas:
En las semanas anteriores a dicho code freeze, todo el mundo está desplegando cosas a lo loco, por pequeño que sea el cambio, hay que ponerlo en producción antes del code freeze, lo que implica que muchas funcionalidades van a producción sin estar testeadas como deberían.
Las últimas dos semanas son eso, todo el mundo haciendo despliegues cuantos más mejor y cuanto más metamos mejor, si se testea bien y si no pues también, total si nadie se queja nos vamos a olvidar de ello a final de año.
Y luego viene el otro lado, el final del code freeze. Llegados a este punto suele ser por ejemplo el final del periodo de navidades, eso quiere decir que vas a tener 3 o 4 semanas de cambios, funcionalidades, etc para ser desplegados en producción cuanto antes mejor e igual que antes, ahora tenemos muchísimos cambios que tienen que ser testeados en producción.
Lo normal es que todo vaya bien, más allá de que los QA o quien testee tenga las dos/tres peores semanas de su vida. Aunque si algo va mal, puede ser que sea un cambio realizado hace 3 semanas y quien se acuerda de eso a estas alturas?
Además, en muchos casos, las empresas clientes también se van de vacaciones, eso quiere decir que si publicas algo que tiene un bug el grupo de usuarios afectados es mucho menor que durante el resto del año.
Conclusión
Como habrás podido deducir del texto mi opinión sobre el code freeze, salvo en contadas excepciones es que perjudica más de lo que ayuda.
Las empresas van fardando de CI/CD y luego no despliegan durante un mes no sea que se rompa algo, cada persona y equipo debe ser responsable de lo que hace, si todo tu equipo se va de vacaciones mañana, pues no despliegues hoy, pero si alguien se queda, que mas da?
Por supuesto, si quieres desplegar durante code freeze se puede, solo que suele ser una emergencia, los managers pasan a estar involucrados, tienes que justificar el motivo, etc. Yo he visto con mis propios ojos como un bug (pequeño, pero bug) se subía a producción el dia antes de un code freeze, y ahí se quedó, simplemente para no tener que justificar a los managers y directores el porque hacía falta un “despliegue de emergencia”.
Pero bueno allá cada uno, yo no soy el que paga las facturas, y si a quien paga las facturas le parece bien, solo puedo hacer lo que puedo hacer para intentar hacerles cambiar de idea.
