Todo el código está ubicado en un repositorio, por lo que el #especialista en control de calidad acude constantemente a los desarrolladores y pregunta: "¿Y qué componente ha cambiado?. ¿Qué versión del spread para verificar la tarea?". La #pregunta resultó relevante no solo para UI (C #), sino también para el back-end (Java). Después de nuestras #imprudentes promesas de escribir todo con bolígrafos, sugirieron que se creara #automáticamente la lista necesaria en función de los archivos modificados en el momento de fusionar la solicitud de extracción

Condiciones de la tarea

Antes que nada, #definamos lo que nuestra herramienta debería poder #hacer:

  1. Si el ensamblado es exitoso, coloque el número de #ensamblado en JIRA y especifique #información adicional en el comentario (qué rama fue reparada, qué componentes desplegar, etc.)
  2. Si el Montaje no tiene éxito, envíe una #carta a personas específicas con una plantilla específica y una #descripción del problema.

Ahora enumeremos los requisitos para la implementación:

  1. Algún #código no trivial (lógica) después del #ensamblaje.
  2. Usando #agentes de Windows y Linux.
  3. Nada no estándar en los #agentes.
  4. Fácil replicación en la Configuración de #compilación.

Elige la solución

Debido al #primer punto de los requisitos anteriores, la opción no se encuentra en los pasos de compilación de la #línea de comando en el TC, porque:

  1. Es #difícil escribir una #lógica compleja sobre esto (aunque es posible);
  2. Los especialistas que conocen #bash / cmd / powershell son #pocos;
  3. Esto #no está versionado;
  4. El mismo código en los agentes de #Windows y #Linux no se ejecuta.

La versión ensamblada se guardó en un repositorio binario, desde donde se #descargó directamente durante el #proceso de compilación.

Fue posible recopilarlo cada vez durante el ensamblaje, pero esto aumentaría #significativamente el #tiempo de compilación y, además, crearía una dependencia adicional en una raíz de VCS separada, lo que daría lugar a ensamblajes adicionales.

Ahora sobre replicar en una gran cantidad de configuraciones de compilación. Hay dos formas:

  1. Plantilla de compilación Desde allí, puede #heredar nuestro ensamblaje y así #cambiar en un lugar diferentes parámetros / pasos / propiedades.
  2. Meta-Runner. Mímica debajo del corredor, no #aparece en absoluto en el montaje.

La plantilla de compilación en algunos caso no es muy adecuada, porque los ensamblajes en los que queremos #utilizarla ya se heredan de su plantilla de #compilación.

Además, en tal caso, muchos detalles irrelevantes del ensamblaje actual aparecen en los pasos / propiedades. Por lo tanto, una #posible implementación #técnica se ve así:

  1. Se crea un repositorio separado, donde se #almacena el código de nuestro #complemento.
  2. El complemento se ensambla en un ensamblaje #separado y se presenta en un #depósito de artefactos binarios (Nexus o Artifactory).
  3. Para montajes específicos, de una manera #creativa, ejecutamos este #complemento.

Todo esto se #hace como un metacorredor.

¡No te pierdas nuestra pagina de Facebook!!