<\/a><\/noindex><\/p>\nC\u00f3mo funcionan actualmente los procesos de despliegue de proyectos<\/h2>\n \nCada PR (pull request) en Slack debe someterse obligatoriamente a una revisi\u00f3n de c\u00f3digo y debe pasar todas las pruebas exitosamente. Solo despu\u00e9s de cumplir con estas condiciones, el programador puede fusionar su c\u00f3digo con la rama master del proyecto. Sin embargo, el despliegue de dicho c\u00f3digo se realiza \u00fanicamente durante el horario laboral en la zona horaria norteamericana. Como resultado, al contar con nuestros empleados en el lugar de trabajo, estamos completamente preparados para resolver cualquier problema inesperado.<\/p>\n
Cada d\u00eda realizamos alrededor de 12 despliegues planificados. Durante cada despliegue, el programador designado como responsable del despliegue es el encargado de llevar la nueva compilaci\u00f3n a producci\u00f3n. Este es un proceso de m\u00faltiples etapas que asegura una transici\u00f3n fluida de la compilaci\u00f3n al modo operativo. Gracias a este enfoque, podemos detectar errores antes de que afecten a todos nuestros usuarios. Si hay demasiados errores, el despliegue de la compilaci\u00f3n puede revertirse. Si se identifica alg\u00fan problema individual despu\u00e9s del lanzamiento, se puede liberar f\u00e1cilmente una correcci\u00f3n para ello.<\/p>\n
La interfaz del sistema Checkpoint, que se utiliza en Slack para el despliegue de proyectos<\/i><\/p>\n
El proceso de despliegue de una nueva versi\u00f3n en producci\u00f3n se puede imaginar como compuesto por cuatro pasos.<\/p>\n
\u258d1. Creaci\u00f3n de la rama de lanzamiento<\/h3>\n \nCada lanzamiento comienza con una nueva rama de lanzamiento, desde un punto en nuestra historia de Git. Esto permite asignar etiquetas al lanzamiento y proporciona un lugar donde se pueden realizar correcciones operativas para errores encontrados durante la preparaci\u00f3n del lanzamiento para su producci\u00f3n.<\/p>\n
\u258d2. Despliegue en el entorno intermedio<\/h3>\n \nEl siguiente paso en el trabajo consiste en desplegar la compilaci\u00f3n en los servidores intermedios (staging) y ejecutar pruebas autom\u00e1ticas para comprobar la funcionalidad general del proyecto (prueba de humo). El entorno intermedio es un entorno de producci\u00f3n al que no llega tr\u00e1fico externo. En este entorno realizamos pruebas manuales adicionales. Esto nos brinda confianza adicional en que el proyecto modificado funciona correctamente. Solo las pruebas automatizadas no son suficientes para obtener dicha confianza.<\/p>\n
\u258d3. Despliegue en entornos dogfood y canary<\/h3>\n \nEl despliegue en producci\u00f3n comienza con el entorno dogfood, que consiste en un conjunto de hosts que sirven nuestros espacios de trabajo internos en Slack. Dado que somos usuarios muy activos de Slack, este enfoque ha ayudado a descubrir numerosos errores en las primeras etapas del despliegue. Una vez que nos aseguramos de que la funcionalidad b\u00e1sica del sistema no se ve afectada, se lleva a cabo el despliegue de la compilaci\u00f3n en el entorno canary. Este \u00faltimo es un sistema que recibe aproximadamente el 2% del tr\u00e1fico de producci\u00f3n.<\/p>\n
\u258d4. Introducci\u00f3n gradual en producci\u00f3n<\/h3>\n \nSi los indicadores de monitoreo de la nueva versi\u00f3n se mantienen estables, y si despu\u00e9s del despliegue del proyecto en el entorno canary no hemos recibido quejas, continuamos con la transici\u00f3n gradual de los servidores de producci\u00f3n a la nueva versi\u00f3n. El proceso de despliegue se divide en las siguientes etapas: 10%, 25%, 50%, 75% y 100%. Como resultado, podemos transferir lentamente el tr\u00e1fico de producci\u00f3n a la nueva versi\u00f3n del sistema. Al mismo tiempo, tenemos tiempo para investigar la situaci\u00f3n en caso de que se detecten anomal\u00edas.<\/p>\n
\u258d\u00bfQu\u00e9 hacer si algo sale mal durante el despliegue?<\/h3>\n \nModificar el c\u00f3digo siempre implica un riesgo. Pero lo manejamos gracias a que contamos con \"l\u00edderes de despliegue\" bien preparados, que dirigen el proceso de lanzamiento de una nueva versi\u00f3n a producci\u00f3n, supervisan las m\u00e9tricas de monitoreo y coordinan el trabajo de los programadores que lanzan el c\u00f3digo.<\/p>\n
En caso de que algo realmente salga mal, tratamos de detectar el problema lo antes posible. Investigamos el problema, encontramos el PR que causa errores, lo revertimos, analizamos cuidadosamente y creamos una nueva compilaci\u00f3n. Sin embargo, a veces el problema pasa desapercibido hasta la implementaci\u00f3n del proyecto en producci\u00f3n. En esa situaci\u00f3n, lo m\u00e1s importante es restaurar el servicio. Por lo tanto, antes de comenzar a investigar el problema, revertimos de inmediato a la \u00faltima compilaci\u00f3n funcional.<\/p>\n
Bloques de construcci\u00f3n del sistema de despliegue<\/h2>\n \nVeamos las tecnolog\u00edas que sustentan nuestro sistema de despliegue de proyectos.<\/p>\n
\u258dDespliegues r\u00e1pidos<\/h3>\n \nEl proceso de trabajo descrito anteriormente puede parecer, en retrospectiva, algo completamente obvio. Pero nuestro sistema de despliegue no lleg\u00f3 a ser as\u00ed de inmediato.<\/p>\n
Cuando la empresa era mucho m\u00e1s peque\u00f1a, toda nuestra aplicaci\u00f3n pod\u00eda funcionar en 10 instancias de Amazon EC2. Desplegar un proyecto en esa situaci\u00f3n significaba usar rsync para una r\u00e1pida sincronizaci\u00f3n entre todos los servidores. Antes, solo hab\u00eda un paso que separaba el nuevo c\u00f3digo de producci\u00f3n, representado por un entorno intermedio. Las compilaciones se creaban y verificaban en ese entorno, y luego iban directamente a producci\u00f3n. Era muy sencillo entender ese sistema, permit\u00eda a cualquier programador desplegar en cualquier momento el c\u00f3digo que hab\u00eda escrito.<\/p>\n
Pero a medida que aumentaba el n\u00famero de nuestros clientes, tambi\u00e9n crec\u00eda la infraestructura necesaria para soportar el proyecto. Pronto, debido al crecimiento continuo del sistema, nuestro modelo de despliegue, basado en la entrega de nuevo c\u00f3digo a los servidores, dej\u00f3 de funcionar adecuadamente. Espec\u00edficamente, a\u00f1adir cada nuevo servidor significaba un aumento en el tiempo requerido para realizar el despliegue. Incluso las estrategias basadas en la aplicaci\u00f3n paralela de rsync tienen ciertas limitaciones.<\/p>\n
Al final, resolvimos este problema al pasar a un sistema de despliegue completamente paralelo, estructurado de manera diferente a nuestro antiguo sistema. Espec\u00edficamente, ahora no envi\u00e1bamos el c\u00f3digo a los servidores utilizando un script de sincronizaci\u00f3n. Cada servidor ahora descargaba la nueva versi\u00f3n de manera independiente, enter\u00e1ndose de la necesidad de hacerlo al observar el cambio en la clave de Consul. Los servidores cargaban el c\u00f3digo en paralelo. Esto nos permiti\u00f3 mantener una alta velocidad de despliegue incluso en un entorno de crecimiento constante del sistema.<\/p>\n
1. Los servidores de producci\u00f3n observan la clave de Consul. 2. La clave cambia, lo que informa a los servidores que deben comenzar a cargar el nuevo c\u00f3digo. 3. Los servidores descargan archivos tarball con el c\u00f3digo de la aplicaci\u00f3n.<\/i><\/p>\n\u258dDespliegues at\u00f3micos<\/h3>\n
\nOtra soluci\u00f3n que nos ayud\u00f3 a implementar un sistema de despliegue multinivel fue el despliegue at\u00f3mico.<\/p>\n
Antes de utilizar los despliegues at\u00f3micos, cada despliegue pod\u00eda generar numerosos mensajes de error. Esto se deb\u00eda a que el proceso de copiar nuevos archivos a los servidores de producci\u00f3n no era at\u00f3mico. Esto resultaba en un breve periodo durante el cual el c\u00f3digo que invocaba nuevas funciones estaba disponible antes de que las propias funciones estuvieran disponibles. Cuando se llamaba a tal c\u00f3digo, se retornaban errores internos. Esto se manifestaba en solicitudes de API fallidas y en p\u00e1ginas web \"rotas\".<\/p>\n
El equipo que trat\u00f3 este problema lo resolvi\u00f3 introduciendo el concepto de directorios \"calientes\" (hot) y \"fr\u00edos\" (cold). El c\u00f3digo en el directorio \"caliente\" se encarga del tr\u00e1fico de producci\u00f3n. En los directorios \"fr\u00edos\", el c\u00f3digo se prepara para su uso mientras el sistema est\u00e1 en funcionamiento. Durante el despliegue, el nuevo c\u00f3digo se copia a un directorio \"fr\u00edo\" que no se est\u00e1 utilizando. Luego, cuando no hay procesos activos en el servidor, se realiza un cambio instant\u00e1neo de directorios.<\/p>\n
1. Descompresi\u00f3n del c\u00f3digo de la aplicaci\u00f3n en el directorio \"fr\u00edo\". 2. Cambio del sistema al directorio \"fr\u00edo\", que se convierte en \"caliente\" (operaci\u00f3n at\u00f3mica).<\/i><\/p>\nResultados: un cambio de enfoque hacia la confiabilidad.<\/h2>\n
\nEn 2018, el proyecto alcanz\u00f3 una escala en la que el despliegue r\u00e1pido comenz\u00f3 a perjudicar la estabilidad del producto. Ten\u00edamos un sistema de despliegue bastante avanzado, en el que invertimos mucho esfuerzo y tiempo. Solo necesit\u00e1bamos reorganizar y mejorar los procesos de despliegue. Nos convertimos en una empresa bastante grande, cuyos desarrollos se utilizan en todo el mundo para asegurar la comunicaci\u00f3n ininterrumpida y para resolver tareas importantes. Por lo tanto, la fiabilidad se convirti\u00f3 en nuestra principal prioridad.<\/p>\n
Necesit\u00e1bamos hacer que el proceso de despliegue de nuevas versiones de Slack fuera m\u00e1s seguro. Esta necesidad nos llev\u00f3 a mejorar nuestro sistema de despliegue. De hecho, lo que hemos discutido anteriormente es este sistema mejorado. En el coraz\u00f3n del sistema, seguimos utilizando tecnolog\u00edas de despliegue r\u00e1pido y at\u00f3mico. Lo que ha cambiado es la forma en que se realiza el despliegue. Nuestro nuevo sistema est\u00e1 dise\u00f1ado para llevar a cabo el despliegue de nuevo c\u00f3digo de manera gradual, en diferentes niveles y entornos. Ahora utilizamos herramientas y recursos de monitoreo m\u00e1s avanzados que antes. Esto nos permite detectar y corregir errores mucho antes de que tengan la oportunidad de llegar al usuario final.<\/p>\n
Pero no pensamos detenernos aqu\u00ed. Continuamente mejoramos este sistema utilizando herramientas y recursos de automatizaci\u00f3n m\u00e1s sofisticados.<\/p>\n
\u00a1Estimados lectores!<\/b> \u00bfC\u00f3mo est\u00e1 organizado el proceso de despliegue de nuevas versiones de proyectos en su lugar de trabajo?<\/p>\n
habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t