🥃 🌆 👩🏿‍🎤 Metodología de implementación del proyecto utilizada por Slack 🤾 👩‍👩‍👧 ™️

La conclusión del lanzamiento de un nuevo proyecto en producción requiere un cuidadoso equilibrio entre la velocidad de implementación y la confiabilidad de la solución. Slack aprecia las iteraciones rápidas, los ciclos de retroalimentación cortos y la capacidad de respuesta a las solicitudes de los usuarios. Además, la compañía tiene cientos de programadores que se esfuerzan por lograr la mayor productividad posible.

Los autores del material, cuya traducción publicamos hoy, dicen que una empresa que busca adherirse a dichos valores y al mismo tiempo crece debería mejorar constantemente su sistema de implementación de proyectos. La empresa necesita invertir en la transparencia y confiabilidad de los procesos de trabajo, para garantizar que estos procesos se correspondan con el alcance del proyecto. Aquí hablaremos sobre los procesos de trabajo que se han desarrollado en Slack, y sobre algunas de las soluciones que llevaron a la compañía a utilizar el sistema de implementación de proyectos que existe actualmente.

Cómo funcionan los procesos de implementación de proyectos hoy

Cada PR (solicitud de extracción) en Slack debe someterse a una revisión de código y debe pasar todas las pruebas con éxito. Solo después de que se cumplan estas condiciones, un programador puede fusionar su código con la rama maestra del proyecto. Sin embargo, la implementación de dicho código se realiza solo durante el horario comercial de acuerdo con la hora de América del Norte. Como resultado, nosotros, debido al hecho de que nuestros empleados están en el trabajo, estamos completamente preparados para resolver cualquier problema inesperado.

Todos los días completamos alrededor de 12 implementaciones planificadas. Durante cada implementación, el programador, designado como la implementación principal, es responsable de llevar el nuevo ensamblaje a producción. Este es un proceso de varios pasos, que proporciona una conclusión fluida del ensamblaje en modo de trabajo. Gracias a este enfoque, podemos detectar errores antes de que afecten a todos nuestros usuarios. Si hay demasiados errores, la implementación del ensamblaje puede revertirse. Si se detecta un problema particular después del lanzamiento, se puede liberar fácilmente una solución.

La interfaz del sistema Checkpoint utilizado por Slack para implementar proyectos.

El proceso de implementación de una nueva versión en producción se puede representar en cuatro pasos.

▍1. Crear una rama de lanzamiento

Cada lanzamiento comienza con una nueva rama de lanzamiento, desde el momento en nuestra historia de Git. Esto le permite asignar etiquetas a la versión y proporciona un lugar donde puede hacer correcciones operativas para los errores encontrados en el proceso de preparación de la versión para su lanzamiento en producción.

▍2. Despliegue intermedio

El siguiente paso es implementar el ensamblado en los servidores de ensayo y ejecutar una prueba automática para el rendimiento general del proyecto (prueba de humo). Un entorno intermedio es un entorno de producción en el que el tráfico externo no cae. En este entorno, realizamos pruebas manuales adicionales. Esto nos da más confianza de que el proyecto modificado funciona correctamente. Las pruebas automatizadas por sí solas no son suficientes para ganar tanta confianza.

▍3. Despliegue en ambientes canarios y canarios

El despliegue en la producción comienza con un entorno de comida para perros representado por un conjunto de hosts que sirven a nuestros espacios de trabajo internos de Slack. Como somos usuarios muy activos de Slack, el uso de este enfoque ha ayudado a detectar muchos errores en las primeras etapas de implementación. Después de asegurarnos de que la funcionalidad básica del sistema no esté rota, el ensamblaje se implementa en un entorno canario. Es un sistema que recibe alrededor del 2% del tráfico de producción.

▍4. Conclusión gradual en producción

Si los indicadores de monitoreo de la nueva versión resultan estables, y si después de implementar el proyecto en el entorno canario no hemos recibido ninguna queja, continuamos la transferencia gradual de 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 una nueva versión del sistema. Al mismo tiempo, tenemos tiempo para investigar la situación en caso de revelar algunas anomalías.

Hat ¿Qué pasa si algo salió mal durante el despliegue?

Hacer modificaciones al código siempre es un riesgo. Pero podemos hacer frente a esto gracias a nuestros "gestores de despliegue" bien entrenados que gestionan el proceso de introducir una nueva versión en la producción, supervisar el rendimiento del monitoreo y coordinar el trabajo de los programadores que lanzan el código.

En caso de que algo realmente saliera mal, tratamos de detectar el problema lo antes posible. Investigamos el problema, encontramos el RP que causa los errores, lo retrocedemos, lo analizamos cuidadosamente y creamos un nuevo ensamblaje. Es cierto que a veces el problema pasa desapercibido antes de que el proyecto se ponga en producción. En tal situación, lo más importante es restaurar el servicio. Por lo tanto, antes de comenzar la investigación del problema, volvemos inmediatamente a la asamblea de trabajo anterior.

Implementación de bloques de construcción

Considere las tecnologías subyacentes a nuestro sistema de implementación de proyectos.

▍ Implementaciones rápidas

El flujo de trabajo descrito anteriormente puede parecer, en retrospectiva, ser algo completamente obvio. Pero nuestro sistema de despliegue no llegó tan lejos de inmediato.

Cuando la empresa era significativamente más pequeña, nuestra aplicación completa podía ejecutarse en 10 instancias de Amazon EC2. Implementar un proyecto en esta situación significaba usar rsync para sincronizar rápidamente todos los servidores. Anteriormente, el nuevo código se separaba de la producción en un solo paso, representado por un entorno intermedio. Los ensamblajes se crearon y probaron en dicho entorno, y luego se pusieron en producción. Entender tal sistema era muy simple; permitía a cualquier programador desplegar el código que escribió en cualquier momento.

Pero a medida que crecía el número de nuestros clientes, también lo hizo la escala de la infraestructura necesaria para garantizar la operación del proyecto. Pronto, dado el crecimiento constante del sistema, nuestro modelo de implementación, basado en el envío de nuevo código a los servidores, dejó de cumplir con su tarea. Es decir, la adición de cada nuevo servidor significó un aumento en el tiempo requerido para completar la implementación. Incluso las estrategias basadas en el uso paralelo de rsync tienen ciertas limitaciones.

Como resultado, resolvimos este problema cambiando a un sistema de implementación totalmente paralelo, que no está organizado como el sistema anterior. Es decir, ahora no enviamos el código a los servidores utilizando el script de sincronización. Ahora cada servidor descargó de forma independiente un nuevo ensamblaje, aprendiendo que era necesario hacerlo, gracias a observar el cambio de clave del Cónsul. Los servidores descargaron el código en paralelo. Esto nos permitió mantener una alta velocidad de implementación incluso en un entorno de crecimiento constante del sistema.

1. Los servidores de producción monitorean la clave Consul. 2. La clave está cambiando, esto le dice a los servidores que necesitan comenzar a descargar el nuevo código. 3. Los servidores cargan archivos tarball con código de aplicación

▍ Despliegues atómicos

Otra solución que nos ayudó a llegar a un sistema de implementación de niveles múltiples fue la implementación atómica.

Antes de usar implementaciones atómicas, cada implementación podría generar una gran cantidad de mensajes de error. El hecho es que el proceso de copiar nuevos archivos a servidores de producción no fue atómico. Esto llevó a la existencia de un corto período de tiempo cuando el código en el que se llamaban las nuevas funciones estaba disponible antes de que las funciones en sí estuvieran disponibles. Cuando se invocó dicho código, devolvió errores internos. Esto se manifestó en solicitudes API fallidas y en páginas web rotas.

El equipo que se ocupó de este problema lo resolvió introduciendo el concepto de directorios "hot" (hot) y "cold" (cold). El código en el directorio "activo" es responsable de procesar el tráfico de producción. Y en los directorios "en frío", el código, mientras el sistema se está ejecutando, solo se está preparando para su uso. Durante la implementación, el nuevo código se copia en el directorio "en frío" no utilizado. Luego, cuando no hay procesos activos en el servidor, los directorios se cambian instantáneamente.

1. Desempaquetar 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)

En pocas palabras: un cambio en el énfasis en 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. Solo necesitábamos reestructurar y mejorar los procesos de organización de la implementación. Nos hemos convertido en una empresa bastante grande, cuyo desarrollo se utilizó en todo el mundo para organizar una comunicación ininterrumpida y resolver problemas importantes. Por lo tanto, el foco de nuestra atención fue la fiabilidad.

Necesitábamos hacer que el proceso de implementación de nuevas versiones de Slack fuera más seguro. Esta necesidad nos llevó a mejorar nuestro sistema de implementación. De hecho, anteriormente discutimos este sistema mejorado. En las entrañas del sistema, seguimos utilizando tecnologías de despliegue rápido y atómico. Se modificó cómo se realiza exactamente la implementación. Nuestro nuevo sistema está diseñado para implementar gradualmente nuevo código en diferentes niveles, en diferentes entornos. Ahora utilizamos herramientas auxiliares más avanzadas que antes y herramientas para monitorear el sistema. Esto nos da la oportunidad de detectar y eliminar errores mucho antes de que tengan la oportunidad de llegar al usuario final.

Pero no vamos a parar allí. Estamos mejorando constantemente este sistema utilizando herramientas auxiliares y herramientas de automatización más avanzadas.

¡Queridos lectores! ¿Cómo es el proceso de implementación de nuevas versiones de proyectos donde trabaja?

Metodología de implementación del proyecto utilizada por Slack