A posta en produción dunha nova versión do proxecto require un coidadoso equilibrio entre a velocidade de implantación e a fiabilidade da solución. Slack valora iteracións rápidas, ciclos de comentarios curtos e resposta rápida ás solicitudes dos usuarios. Ademais, a empresa conta con centos de programadores que se esforzan por ser o máis produtivos posible.
Os autores do material, cuxa tradución publicamos hoxe, afirman que unha empresa que se esforza por adherirse a tales valores e ao mesmo tempo crece debe mellorar constantemente o seu sistema de implantación de proxectos. A empresa precisa investir en transparencia e fiabilidade dos procesos de traballo, facendo isto para garantir que estes procesos se correspondan coa escala do proxecto. Aquí falaremos dos fluxos de traballo que se desenvolveron en Slack, e dalgunhas das decisións que levaron á empresa a utilizar o sistema de implantación de proxectos que existe na actualidade.
Como funcionan os procesos de implantación dos proxectos na actualidade
Cada PR (pull request) en Slack debe estar suxeita a revisión do código e debe superar con éxito todas as probas. Só despois de que se cumpran estas condicións o programador pode fusionar o seu código na rama mestra do proxecto. Non obstante, este código só se implementa durante o horario laboral, horario norteamericano. Como resultado, debido ao feito de que os nosos empregados están nos seus lugares de traballo, estamos totalmente preparados para resolver calquera problema inesperado.
Cada día levamos a cabo preto de 12 despregamentos previstos. Durante cada implantación, o programador designado como xefe de implantación é o responsable de poñer a nova versión en produción. Este é un proceso de varios pasos que garante que a montaxe entre en produción sen problemas. Grazas a este enfoque, podemos detectar erros antes de que afecten a todos os nosos usuarios. Se hai demasiados erros, pódese revertir o despregamento da montaxe. Se se descobre un problema específico despois do lanzamento, pódese liberar facilmente unha solución.
Interface do sistema Checkpoint, que se usa en Slack para implementar proxectos
O proceso de implantación dunha nova versión en produción pódese considerar que consta de catro pasos.
▍1. Creando unha rama de liberación
Cada versión comeza cunha nova rama de lanzamento, un punto no noso historial de Git. Isto permíteche asignar etiquetas á versión e ofrece un lugar onde podes facer correccións en directo para os erros atopados no proceso de preparación da versión para o lanzamento en produción.
▍2. Implantación nun entorno de posta en escena
O seguinte paso é implantar a montaxe en servidores de preparación e realizar unha proba automática para o rendemento global do proxecto (proba de fume). O ambiente de preparación é un ambiente de produción que non recibe tráfico externo. Neste ambiente, realizamos probas manuais adicionais. Isto dános unha confianza adicional en que o proxecto modificado funciona correctamente. As probas automatizadas por si soas non son suficientes para proporcionar este nivel de confianza.
▍3. Implantación en ambientes de proba e canario
A implantación en produción comeza cun ambiente de proba, representado por un conxunto de hosts que serven os nosos espazos de traballo internos de Slack. Dado que somos usuarios moi activos de Slack, este enfoque axudounos a detectar moitos erros no inicio da implantación. Despois de asegurarnos de que a funcionalidade básica do sistema non se rompe, o conxunto desprázase no ambiente canario. Representa sistemas que representan aproximadamente o 2% do tráfico de produción.
▍4. Liberación gradual a produción
Se os indicadores de seguimento da nova versión resultan estables e se despois de implantar o proxecto no entorno canario non recibimos ningunha queixa, seguimos trasladando progresivamente os servidores de produción á nova versión. O proceso de implantación divídese nas seguintes fases: 10%, 25%, 50%, 75% e 100%. Como resultado, podemos transferir lentamente o tráfico de produción á nova versión do sistema. Ao mesmo tempo, temos tempo para investigar a situación se se detecta algunha anomalía.
▍E se algo sae mal durante a implantación?
Facer modificacións no código sempre é un risco. Pero afrontamos isto grazas á presenza de "líderes de despregamento" ben adestrados que xestionan o proceso de posta en produción dunha nova versión, supervisan os indicadores de seguimento e coordinan o traballo dos programadores que lanzan código.
No caso de que algo realmente saia mal, tentamos detectar o problema canto antes. Investigamos o problema, atopamos o PR que está causando os erros, retírao, analizámolo a fondo e creamos unha nova compilación. É certo que ás veces o problema pasa desapercibido ata que o proxecto entra en produción. En tal situación, o máis importante é restaurar o servizo. Polo tanto, antes de comezar a investigar o problema, volvemos inmediatamente á versión anterior de traballo.
Elementos básicos dun sistema de implantación
Vexamos as tecnoloxías que subxacen ao noso sistema de implantación de proxectos.
▍Impregacións rápidas
O fluxo de traballo descrito anteriormente pode parecer, en retrospectiva, algo obvio. Pero o noso sistema de despregamento non se fixo deste xeito de inmediato.
Cando a empresa era moito máis pequena, toda a nosa aplicación podía executarse en 10 instancias de Amazon EC2. Implantar o proxecto nesta situación significaba usar rsync para sincronizar rapidamente todos os servidores. Anteriormente, o novo código estaba a só un paso da produción, representado por un ambiente de posta en escena. Os conxuntos creáronse e probáronse nun ambiente deste tipo e despois pasaron directamente á produción. Era moi doado entender un sistema así; permitía a calquera programador despregar o código que escribira en calquera momento.
Pero a medida que creceu o número dos nosos clientes, tamén foi a escala da infraestrutura necesaria para apoiar o proxecto. Pronto, dado o constante crecemento do sistema, o noso modelo de implantación, baseado en impulsar código novo aos servidores, deixou de facer o seu traballo. É dicir, engadir cada novo servidor significaba aumentar o tempo necesario para completar a implantación. Mesmo as estratexias baseadas no uso paralelo de rsync teñen certas limitacións.
Acabamos resolvendo este problema pasando a un sistema de implantación completamente paralelo, que foi deseñado de forma diferente ao sistema antigo. É dicir, agora non enviamos código aos servidores mediante un script de sincronización. Agora cada servidor descargaba de forma independente a nova montaxe, sabendo que era necesario supervisar o cambio da chave Cónsul. Os servidores cargaron o código en paralelo. Isto permitiunos manter unha alta velocidade de implantación incluso nun entorno de constante crecemento do sistema.
1. Os servidores de produción supervisan a clave Consul. 2. A chave cambia, isto indica aos servidores que necesitan comezar a descargar código novo. 3. Os servidores descargan ficheiros tarball co código da aplicación
▍Desplegamentos atómicos
Outra solución que nos axudou a acadar un sistema de despregamento de varios niveis foi o despregamento atómico.
Antes de usar despregamentos atómicos, cada despregamento podería producir un gran número de mensaxes de erro. O caso é que o proceso de copia de novos ficheiros aos servidores de produción non foi atómico. Isto deu lugar a unha pequena xanela de tempo na que o código que chamaba novas funcións estaba dispoñible antes de que as propias funcións estivesen dispoñibles. Cando se chamou a tal código, producíase que se devolvían erros internos. Isto manifestouse en solicitudes de API fallidas e páxinas web rotas.
O equipo que traballou neste problema resolveuno introducindo o concepto de directorios "quentes" e "fríos". O código do directorio activo é o responsable do procesamento do tráfico de produción. E nos directorios "fríos", o código, mentres o sistema está en execución, só se está a preparar para o seu uso. Durante a implantación, o código novo cópiase nun directorio frío non utilizado. Despois, cando non hai procesos activos no servidor, realízase un cambio de directorio instantáneo.
1. Descomprimir o código da aplicación nun directorio "frío". 2. Cambiando o sistema a un directorio "frío", que pasa a ser "quente" (operación atómica)
Resultados: cambio de énfase na fiabilidade
En 2018, o proxecto creceu a tal escala que un despregue moi rápido comezou a prexudicar a estabilidade do produto. Tiñamos un sistema de implantación moi avanzado no que investimos moito tempo e esforzo. Todo o que necesitabamos facer era reconstruír e mellorar os nosos procesos de implantación. Convertémonos nunha empresa bastante grande, cuxos desenvolvementos foron utilizados en todo o mundo para organizar comunicacións ininterrompidas e resolver problemas importantes. Polo tanto, a fiabilidade converteuse no foco da nosa atención.
Necesitabamos facer máis seguro o proceso de implantación de novas versións de Slack. Esta necesidade levounos a mellorar o noso sistema de implantación. De feito, comentamos este sistema mellorado anteriormente. Nas profundidades do sistema, seguimos utilizando tecnoloxías de despregamento rápida e atómica. A forma en que se fai a implantación cambiou. O noso novo sistema está deseñado para implementar gradualmente novo código a diferentes niveis, en diferentes ambientes. Agora usamos ferramentas de soporte e ferramentas de seguimento do sistema máis avanzadas que antes. Isto dános a posibilidade de detectar e corrixir erros moito antes de que teñan a oportunidade de chegar ao usuario final.
Pero non imos parar aí. Estamos a mellorar constantemente este sistema, empregando ferramentas auxiliares máis avanzadas e ferramentas de automatización do traballo.
Queridos lectores! Como funciona o proceso de implantación de novas versións de proxectos onde traballas?
Fonte: www.habr.com