¿Cuál es el mejor momento para pasar a producción? La respuesta corta es: ¡Ninguno! No existe un momento ideal. Voy a explicar el por qué.
Cada vez que corregimos un error o que agregamos una nueva funcionalidad a nuestras aplicaciones, debemos realizar el proceso de despliegue a producción (también conocido como deploy). No hablemos de los procesos anteriores como pruebas, staging, etc. Concentrémonos en el deploy a producción.
A todos nos ha pasado (y si no te ha pasado a ti, tarde o temprano te pasará) que en algún deploy algo falla. No importa si tienes unos procesos de devops infalibles. Corres los CI (integración continua), luego el CD (despliegue continuo) y todo funciona correctamente, pero cuando está en producción 🔥 comienzan a llegar todos las quejas de los usuarios informando el mal funcionamiento de la aplicación. Le ha pasado a los gigantes como Microsoft con Azure, Amazon con AWS, Google con Gmail, Facebook con Whatsapp, Instagram, Facebook.
Cuando trabajaba en una empresa del Estado Colombiano, era fácil establecer las ventanas de tiempo (se le llama así al tiempo utilizado por los administradores de los sistemas para tener las aplicaciones sin funcionamiento). Las ventanas de tiempo se establecían durante las noches o los fines de semana, ya que los usuarios de las aplicaciones sólo trabajaban de lunes a viernes de 7am a 7pm máximo. Así que podíamos hacer un despliegue de las aplicaciones fuera de esos horarios.
Pero, en una startup como EDteam, donde los usuarios no tienen un horario establecido de uso de la plataforma, debido a que su uso horario es diferente en la mayoría de paises y todos utilizan diferentes espacios de tiempo para aprender, no es posible decir que las ventanas de tiempo lo haremos en la noche o los fines de semana. Por qué? bueno, existen varios desafíos que controlar, ejemplo:
- Supongamos que en la noche hay pocos usuarios (cosa que no es tan cierta, tenemos una gran cantidad de usuarios en las noches) y sacamos a producción una corrección o una nueva característica. Qué pasa si falla? No habrá personal disponible en toda la noche para revisar cual fue el error y tampoco para corregirlo y volverlo a subir. Sería una noche de caos total donde los usuarios se sentirán frustrados y eso genera pérdidas para cualquier startup/empresa.
- ¿Fines de semana? Igual tendríamos problemas, tendrían que estar disponibles todos los que intervienen en el proceso de cambio.
Entonces, ¿en qué momento se deben realizar los cambios?
En realidad, en una startup no es tan escencial el tema de la gestión del cambio (proceso que controla todos los subprocesos que deben existir antes de pasar a producción). Hay tantas iteraciones, tantas nuevas características, tantas mejoras por realizar, que sería un infierno llevar todo un proceso de RFC (solicitud de cambio) para cada uno y no permitiría crecer a la demanda del público.
Por lo tanto, aunque te parezca extraño, los cambios se pueden realizar varias veces al día. Lo importante es que los usuarios no sientan la caída de la aplicación durante dichos cambios.
¿Cómo podemos hacer para que los usuarios no sientan el downtime (tiempo de caida)? Lo que hacemos en EDteam es dividir al máximo los servicios que ofrecemos. Aún no estamos utilizando microservicios como tal, pero tenemos divididos algunas características lo que nos permite realizar cambios sólo de una característica sin afectar el servicio de las demás. Por lo tanto, si cambiamos un servicio de la comunidad (post y respuestas), no estamos afectando el servicio de los cursos.
Otra ventaja es que realizar un deploy de un servicio de backend con Go, es extremadamente rápido. Sólo es copiar el nuevo ejecutable y hacer un systemctl restart cursos este proceso no demora más de 2 segundos. Lo que puede tardar es los cambios en la base de datos, pero se realiza antes de reiniciar el servicio.
Nosotros tenemos como política realizar los deploy en las mañanas con el fin de poder verificar durante el día si algo falla y corregirlo lo más rápido posible. Sin embargo, no es obligatorio realizarlo en dicho horario. En la gran mayoría de veces, no ocurre ningún inconveniente, pero en pocas ocasiones ocurren fallos que hacen que se caiga toda la aplicación. Es allí donde los usuarios comienzan a reportar por diferentes medios que la aplicación está fallando. ¿Qué se debe hacer? Actuar de inmediato y corregir en el menor tiempo posible el error. Si es necesario, deshacer los cambios para que el sistema siga funcionando.
En conclusión, no existe un momento ideal para realizar el deploy en una startup o empresa como EDteam, siempre tendrás que realizar deploy en cualquier momento y puede que algo te falle. Lo importante es que tengas claro cómo deshacer el cambio que generó el problema o que lo corrijas rápidamente.
¿Tú como haces tus deploy? ¿Tienes unas ventanas de tiempo establecidas? ¿Lo haces en cualquier moemento? Siempre me gusta escuchar diferentes ideas. ¡Nos vemos en otro artículo!