Automatización de lanzamientos de aplicaciones basadas en microservices

Estamos trabajando en la aplicación que consta de muchos services independientes. Tiene ventajas sobre la aplicación monolítica única, pero no cuando hacemos lanzamientos.

Hacemos ciclos de lanzamiento semanales. Cada service / componente ubicado en el repository git separado. 'A release' – es varias características que ponemos en salvaje. Por lo general, solo se deben actualizar varios componentes. Administramos serveres usando saltstack. Para hacer una versión, las secuencias de commands de sal actualizan las versiones del componente usando el estado git.latest. El problema es especificar versiones correctas.

Aquí es donde el trabajo manual que me gustaría automatizar. Para actualizar las versiones, debo verificar manualmente el repository de cada componente, fusionar la twig de desarrollo en maestra y labelr de acuerdo con las reglas de versiones de Symantec. Luego escribo una nueva versión en scripts salinos. Tenemos más de 10 componentes, por lo que este es un process bastante aburrido y propenso a errores.

Probablemente lo estemos haciendo mal, estaré encantado de escuchar algún consejo sobre cómo hacerlo mejor, gracias.

En primer lugar, sugeriría seguir una convención para las tags de lanzamiento de sus componentes. En el caso más simple, esa sería la label de git más reciente en cada uno de los repositorys.

Luego, podría crear un script de mapeo (digamos, se llama map_versions ) enumerando las tags de liberación (últimas) git para todos los repositorys, y almacenar ese mapeo en algún lugar para que SaltStack lo recoja, para ser utilizado como las revision en los estados git.latest .

El mismo script de mapeo también se puede usar para preparar las twigs de desarrollo o maestra de todos los componentes para la implementación; todos los valores de revision se cambiarán para develop o master .

Por lo tanto, su flujo de trabajo será:

 // In the dev environment: $ map_versions develop $ salt * state.highstate // Do the development, until all the stable features // are merged back into master. Then, in production: $ map_versions master $ salt * state.highstate // Make sure everything works fine; then, manually tag // the new release versions for all the repos. $ map_versions tags $ salt * state.highstate 

Después de lo cual, todos los componentes lanzados en producción son labeldos.

También puede ahorrar algo de time con el script automático de labeldo git para todos sus componentes desplegables. El script verificará si algo ha cambiado en el master desde la última label y, si lo tiene, pegará una nueva label de git en el repository; digamos, solo el YYYY-MM-DD . Entonces, esas tags serían recogidas por las map_versions tags .

Puede mantener un mapeo de versión explícito para cada componente que desee include en el lanzamiento (y posiblemente otra información de metadatos según sea necesario) en un repo de git separado que se convierte en el control maestro de SCM. Esto ofrece varias ventajas:

  • no mezclar scripts / código con información de metadatos (que es propenso a errores)
  • Puede codificar sus scripts para manejar simplemente la información de versiones de este repository maestro de git, no es necesario cambiar los scripts para cada lanzamiento
  • solo necesita rastrear / labelr el repository maestro de git ya que contiene toda la información de metadatos sobre todos los demás componentes necesarios en el lanzamiento – less churn de SCM
  • puede acceder rápidamente a la información de metadatos relevante para todos los componentes a través de este pequeño repository, no es necesario extraer todo el set de componentes (a less que también necesite acceder a su contenido específicamente)
  • previene la contaminación de los loggings de SCM de los componentes con su información de lanzamiento particular (especialmente importante si estos comps se comparten con otros productos de terceros o completamente independientes que no podrían importarle less sobre su ciclo de lanzamiento particular).

Esto no elimina los pasos de lanzamiento que tiene que hacer, solo agrega algo de order y puede ayudar con la automation.

Creo que la herramienta que estás buscando es un git hook.

Personalmente, probablemente configuré un gancho post-recepción del lado del server [0] en su repository que toma la label semántica y actualiza automáticamente la versión del software en los datos del stackr, o crea un evento Salt que desencadena una actualización o una implementación. usando los datos proporcionados.

También existe la opción de una fuente de datos de stackr externa [1], donde puede get automáticamente la label o compromiso más reciente en la twig maestra de git.

En cualquier caso, mantendría la combinación de git y labelría un paso manual.

[0] http://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

[1] http://docs.saltstack.com/en/latest/topics/development/external_pillars.html

Después de trabajar durante más de un año desarrollando y administrando lanzamientos de plataforms creadas con microservices, calculé que el process repetible puede automatizarse. Más sobre esto a continuación.

Vamos a dividir el process de lanzamiento en 3 fases :

  1. entendiendo qué debería salir en la liberación
  2. preparando cambios
  3. empujándolos en la naturaleza

Estamos usando Git y Un exitoso model de ramificación de Git , que es bastante cuestionable, prefiero el flujo de trabajo FeatureBranch, pero esa es una historia diferente.

Primera fase : comprensión de lo que debería salir

En nuestra herramienta de seguimiento de problemas, las historias que deberían publicarse están marcadas como "Listo para combinar" (usamos jira.com pero no importa). Cojo la list de historias, ejecuto un script simple que se parece a esta mia review --cards=MIA-1022 MIA-988 MIA-1097 MIA-688 . El resultado es una list de los services afectados por estas historias, por lo que no es necesario que vaya y revise manualmente cada historia para ver los services afectados, por ejemplo, el resultado es el siguiente:

 [+] [2/16] user-service: MIA-1198, MIA-2023 [+] [6/16] checkout-service: MIA-1097 MIA-688 [+] [7/16] inventory-service: MIA-1022 MIA-988, MIA-1198, MIA-2023 

Segunda fase : preparación de cambios

Proceso semi-manual para mí, porque en algunos casos las historias "en curso" de la twig de desarrollo deben ser ignoradas y no pueden pasar al máster. Pero en la mayoría de los casos puedo combinar el desarrollo directo con el maestro , y cuando puedo, tengo otro command: mia merge --services=user checkout inventory . Este command repasa los services especificados y crea requestes de extracción para fusionar el desarrollo de twig a principal e imprime enlaces para extraer requestes.

Tercera fase : impulsar los cambios en la naturaleza

Para impulsar algo al entorno de ensayo y luego a la producción, el service debe tener una versión . Empíricamente nos dimos count de que si lo hace para services, y además si lo hace solo para services que tienen cambios, será difícil entender el "último". Porque si el ritmo de desarrollo del service de pago es significativamente más alto que el service de deviseio, terminas con algo como v3.3.6 en el process de pago y v1.2.0 en el deviseio.

Para solucionar esto : estamos labelndo todos los services con la misma versión de label compuesta por el año, mes, día y versión rc. Ejemplo: r2015052601 , y luego también tenemos un command mia diff r2015052401 r2015052601 , que busca la label especificada en cada service e imprime una diferencia de cambios entre 2 tags. Parte de mí piensa que labelr todos los services con la misma versión viola uno de los principios de la architecture de microservices, pero ahora resuelve la compatibilidad de las tags con el punto de mayor dolor y comprende qué es lo último, porque puedes asumir que la última label existe en todas partes, y no hubo cambios, luego no hubo cambios.

Gracias