Llevar la versión de un nuevo proyecto a producción requiere un cuidadoso equilibrio entre la velocidad de implementación y la confiabilidad de la solución. Slack valora las iteraciones rápidas, los ciclos de retroalimentación cortos y la respuesta rápida a las solicitudes de los usuarios. Además, la empresa cuenta con cientos de programadores que se esfuerzan por ser lo más productivos posible.
Los autores del material, cuya traducción publicamos hoy, dicen que una empresa que se esfuerza por adherirse a tales valores y al mismo tiempo crece debe mejorar constantemente su sistema de implementación de proyectos. La empresa necesita invertir en transparencia y confiabilidad de los procesos de trabajo, para garantizar que estos procesos correspondan a la escala del proyecto. Aquí hablaremos de los flujos de trabajo que se han desarrollado en Slack y de algunas de las decisiones que llevaron a la empresa a utilizar el sistema de implementación de proyectos que existe en la actualidad.
Cómo funcionan hoy los procesos de implementación de proyectos
Cada PR (solicitud de extracción) en Slack debe estar sujeta a revisión de código y debe pasar con éxito todas las pruebas. Sólo después de que se cumplan estas condiciones el programador podrá fusionar su código en la rama maestra del proyecto. Sin embargo, este código se implementa solo durante el horario comercial, hora de América del Norte. Como resultado, debido a que nuestros empleados se encuentran en sus lugares de trabajo, estamos completamente preparados para resolver cualquier problema inesperado.
Cada día llevamos a cabo unos 12 despliegues previstos. Durante cada implementación, el programador designado como líder de implementación es responsable de poner la nueva compilación en producción. Este es un proceso de varios pasos que garantiza que el ensamblaje entre en producción sin problemas. Gracias a este enfoque, podemos detectar errores antes de que afecten a todos nuestros usuarios. Si hay demasiados errores, se puede revertir la implementación del ensamblaje. Si se descubre un problema específico después del lanzamiento, se puede solucionarlo fácilmente.
Interfaz del sistema Checkpoint, que se utiliza en Slack para implementar proyectos
Se puede considerar que el proceso de implementar una nueva versión en producción consta de cuatro pasos.
▍1. Creando una rama de lanzamiento
Cada lanzamiento comienza con una nueva rama de lanzamiento, un punto en nuestra historia de Git. Esto le permite asignar etiquetas a la versión y proporciona un lugar donde puede realizar correcciones en vivo para errores encontrados en el proceso de preparación de la versión para su lanzamiento a producción.
▍2. Implementación en un entorno de ensayo
El siguiente paso es implementar el ensamblaje en servidores de prueba y ejecutar una prueba automática para el rendimiento general del proyecto (prueba de humo). El entorno de prueba es un entorno de producción que no recibe tráfico externo. En este entorno, realizamos pruebas manuales adicionales. Esto nos da una confianza adicional de que el proyecto modificado funciona correctamente. Las pruebas automatizadas por sí solas no son suficientes para proporcionar este nivel de confianza.
▍3. Despliegue en entornos dogfood y canarios
La implementación en producción comienza con un entorno de prueba interna, representado por un conjunto de hosts que sirven a nuestros espacios de trabajo internos de Slack. Dado que somos usuarios muy activos de Slack, adoptar este enfoque nos ayudó a detectar muchos errores al principio de la implementación. Una vez que nos hemos asegurado de que la funcionalidad básica del sistema no esté rota, el ensamblaje se implementa en el entorno canary. Representa sistemas que representan aproximadamente el 2% del tráfico de producción.
▍4. Lanzamiento gradual a producción.
Si los indicadores de seguimiento de la nueva versión resultan estables y si después de implementar el proyecto en el entorno canary no hemos recibido ninguna queja, continuamos transfiriendo gradualmente los servidores de producción a la nueva versión. El proceso de implementación se divide en las siguientes etapas: 10%, 25%, 50%, 75% y 100%. Como resultado, podemos transferir lentamente el tráfico de producción a la nueva versión del sistema. Al mismo tiempo, tenemos tiempo para investigar la situación si se detecta alguna anomalía.
▍¿Qué pasa si algo sale mal durante el despliegue?
Realizar modificaciones al código siempre es un riesgo. Pero podemos hacer frente a esto gracias a la presencia de "líderes de implementación" bien capacitados que gestionan el proceso de poner en producción una nueva versión, monitorean los indicadores de seguimiento y coordinan el trabajo de los programadores que lanzan el código.
En el caso de que algo realmente salga mal, intentamos detectar el problema lo antes posible. Investigamos el problema, encontramos el PR que está causando los errores, lo revertimos, lo analizamos minuciosamente y creamos una nueva compilación. Es cierto que a veces el problema pasa desapercibido hasta que el proyecto entra en producción. En tal situación, lo más importante es restablecer el servicio. Por lo tanto, antes de comenzar a investigar el problema, volvemos inmediatamente a la versión anterior.
Componentes básicos de un sistema de implementación
Veamos las tecnologías que subyacen a nuestro sistema de implementación de proyectos.
▍Implementaciones rápidas
El flujo de trabajo descrito anteriormente puede parecer, en retrospectiva, algo obvio. Pero nuestro sistema de implementación no llegó a ser así de inmediato.
Cuando la empresa era mucho más pequeña, toda nuestra aplicación podía ejecutarse en 10 instancias de Amazon EC2. Implementar el proyecto en esta situación significó usar rsync para sincronizar rápidamente todos los servidores. Anteriormente, el código nuevo estaba a sólo un paso de la producción, representado por un entorno de prueba. Los ensamblajes se crearon y probaron en dicho entorno y luego pasaron directamente a producción. Era muy fácil entender un sistema de este tipo; permitía a cualquier programador implementar el código que había escrito en cualquier momento.
Pero a medida que crecía el número de nuestros clientes, también crecía la escala de la infraestructura necesaria para respaldar el proyecto. Pronto, dado el crecimiento constante del sistema, nuestro modelo de implementación, basado en enviar código nuevo a los servidores, ya no estaba haciendo su trabajo. Es decir, agregar cada nuevo servidor significó aumentar el tiempo necesario para completar la implementación. Incluso las estrategias basadas en el uso paralelo de rsync tienen ciertas limitaciones.
Terminamos resolviendo este problema pasando a un sistema de implementación completamente paralelo, que fue diseñado de manera diferente al sistema anterior. Es decir, ahora no enviamos código a los servidores mediante un script de sincronización. Ahora cada servidor descargó de forma independiente el nuevo ensamblaje, sabiendo que necesitaba hacerlo monitoreando el cambio de clave del Cónsul. Los servidores cargaron el código en paralelo. Esto nos permitió mantener una alta velocidad de implementación incluso en un entorno de constante crecimiento del sistema.
1. Los servidores de producción monitorean la clave Consul. 2. La clave cambia, esto le dice a los servidores que deben comenzar a descargar un código nuevo. 3. Los servidores descargan archivos tarball con el código de la aplicación.
▍Despliegues atómicos
Otra solución que nos ayudó a alcanzar un sistema de implementación de múltiples niveles fue la implementación atómica.
Antes de utilizar implementaciones atómicas, cada implementación podría generar una gran cantidad de mensajes de error. El hecho es que el proceso de copiar archivos nuevos a servidores de producción no fue atómico. Esto resultó en un corto período de tiempo en el que el código que llamaba a nuevas funciones estaba disponible antes de que las funciones en sí estuvieran disponibles. Cuando se llamó a dicho código, se devolvieron errores internos. Esto se manifestó en solicitudes API fallidas y páginas web rotas.
El equipo que trabajó en este problema lo resolvió introduciendo el concepto de directorios "fríos" y "calientes". El código en el directorio activo es responsable de procesar el tráfico de producción. Y en los directorios "fríos", el código, mientras el sistema está en ejecución, sólo se prepara para su uso. Durante la implementación, el código nuevo se copia en un directorio frío no utilizado. Luego, cuando no hay procesos activos en el servidor, se realiza un cambio de directorio instantáneo.
1. Descomprimir el código de la aplicación en un directorio "frío". 2. Cambiar el sistema a un directorio "frío", que se vuelve "caliente" (operación atómica)
Resultados: cambio de énfasis hacia la confiabilidad
En 2018, el proyecto creció a tal escala que un despliegue muy rápido comenzó a dañar la estabilidad del producto. Teníamos un sistema de implementación muy avanzado en el que invertimos mucho tiempo y esfuerzo. Todo lo que teníamos que hacer era reconstruir y mejorar nuestros procesos de implementación. Nos hemos convertido en una empresa bastante grande, cuyos desarrollos se han utilizado en todo el mundo para organizar comunicaciones ininterrumpidas y resolver problemas importantes. Por lo tanto, la confiabilidad se convirtió en el centro de nuestra atención.
Necesitábamos hacer más seguro el proceso de implementación de nuevas versiones de Slack. Esta necesidad nos llevó a mejorar nuestro sistema de implementación. De hecho, discutimos este sistema mejorado anteriormente. En lo más profundo del sistema, seguimos utilizando tecnologías de implementación atómica y rápida. La forma en que se realiza el despliegue ha cambiado. Nuestro nuevo sistema está diseñado para implementar gradualmente código nuevo en diferentes niveles, en diferentes entornos. Ahora utilizamos herramientas de soporte y monitoreo del sistema más avanzadas que antes. Esto nos brinda la capacidad de detectar y corregir errores mucho antes de que tengan la oportunidad de llegar al usuario final.
Pero no nos vamos a quedar ahí. Estamos constantemente mejorando este sistema, utilizando herramientas auxiliares y herramientas de automatización del trabajo más avanzadas.
Estimados lectores! ¿Cómo funciona el proceso de implementación de nuevas versiones de proyectos en su lugar de trabajo?
Fuente: habr.com