Esta publicación describirá cómo configurar la automatización HotFix en proyectos Maven usando Teamcity.
Para hacer HotFix, generalmente se realizan muchas acciones manuales:
- Cree un brunch para la versión a la que desea enviar HotFix
- Fix release bug
- Cambiar la versión de corrección de errores en el brunch de lanzamiento
- Implementar versión de corrección de errores de etiqueta
Los artículos 1,3,4 pueden ser automatizados.
Antes de pasar al tema, quiero tocar un tema importante y complejo: el software de versiones . Brevemente sobre Semver se puede entender en esta captura de pantalla. 
Puede leer más en el enlace: 1 .
Todas las configuraciones descritas en esta publicación se basan en Semver y Trunk-Based Development .
En el desarrollo basado en troncales, para cada versión debe crear su propio brunch. Todos los cambios (revisión) dentro de esta versión están comprometidos con este brunch.
Como parte de esta publicación, automatizamos las siguientes cosas:
Requisitos:
Creemos el proyecto "Automation Maven Hotfix" en Teamcity y creemos 4 tareas allí.
CI Build (construcción CI)
Crear rama para lanzamiento
Maven increment bugfix (Cambiar versión de corrección de errores))
Lanzamiento de Maven (Creación de un nuevo lanzamiento)
Captura de pantalla del proyecto:
Configuraciones generales
En todas las tareas es necesario configurar la casilla de verificación "Generación limpia: eliminar todos los archivos en el directorio de pago antes de la compilación ", porque cuando faltaba este daw, recibí errores.
Crea un solo VCS. Características VCS en círculo en rojo.
VCS generalmente usa el esquema HTTPS. En la especificación de Branch: se indica para ver todos los brunches y todas las etiquetas:
+:refs/heads/* +:refs/tags/*
Es necesario crear 4 parámetros de configuración.
- BRANCH_FOR_INCREMENT
- TAG_FROM_VERSION
- TEAM_USER
- TEAM_USER_EMAIL
El campo de valor en BRANCH_FOR_INCREMENT y TAG_FROM_VERSION debe dejarse en blanco.
Debe cargar / agregar una clave privada. Todas las tareas excepto CI Build requieren una clave privada.
En cada tarea, excepto CI Build, en la sección Build Features, debe conectar una clave privada.
Ejemplo de lanzamiento de Maven
CI Build **.
En la tarea CI Build , solo un paso para la prueba de limpieza
Lanzamiento de Maven
Hay 2 pasos en la versión de Maven . El primer paso es verificar que el brunch sea maestro . Si el brunch no es maestro , entonces la tarea cae.
BRANCH=$(git branch | grep \* | cut -d ' ' -f2) echo "$BRANCH" if [[ "$BRANCH" != "master" ]]; then echo 'Branch is not master'; echo 'Aborting'; exit 1; fi
El segundo paso es la versión estándar de mvn: prepárese con la opción --batch-mode
Crear rama para lanzamiento
Para crear una revisión para su lanzamiento, debe crear un brunch. Esto se hace mediante Crear rama para la tarea de lanzamiento . Ella tiene 2 pasos.
El primer paso verifica que el brunch no sea maestro , y el segundo verifica que la versión en el archivo pom.xml no contenga la palabra SNAPSHOT
BRANCH=$(git branch | grep \* | cut -d ' ' -f2) echo "$BRANCH" if [[ "$BRANCH" == "master" ]]; then echo 'Branch is master'; echo 'Aborting'; exit 1; fi echo "Get version package from pom.xml" version=`python -c "import xml.etree.ElementTree as ET; print(ET.parse(open('pom.xml')).getroot().find('{http://maven.apache.org/POM/4.0.0}version').text)"` echo "Check SNAPSHOT" if [[ $version == "*SNAPSHOT*" ]]; then echo "******************* WARNING *************************" echo "************ You are create branch for SNAPSHOTS ******************" echo "***********************************************************" exit 1 fi
El segundo paso cambia el esquema de conectividad de developerConnection de HTTPS a GIT.
Maven increment bugfix
La tarea consta de 6 partes. Podría ser refactorizado, pero funciona así.
El primer paso es verificar que el brunch no sea maestro . Si la tarea maestra de brunch cae.
BRANCH=$(git branch | grep \* | cut -d ' ' -f2) echo "$BRANCH" if [[ "$BRANCH" == "master" ]]; then echo 'Branch is master'; echo 'Aborting'; exit 1; fi
El segundo paso de Maven es modificar la versión de corrección de errores en el archivo pom.xml.
Objetivos: Maven tiene todo en una línea.
build-helper:parse-version versions:set -DnewVersion=${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion} versions:commit
El tercer paso es mostrar información de estado de Git y otros:
echo 'cat pom.xml' cat pom.xml echo 'git status' git status echo 'git remote -v' git remote -v echo 'git branch' git branch
El cuarto paso cambia el esquema de conectividad de developerConnection de HTTPS a GIT.
Y empuja los cambios a la rama especificada en la variable Teamcity% BRANCH_FOR_INCREMENT%
El quinto paso obtiene la versión del archivo pom.xml y establece la variable TAG_FROM_VERSION en Teamcity . Observe que la versión del archivo pom.xml sin la letra v está al frente. Y la etiqueta, basada en esta versión, ya con la letra v al principio.
echo "Get version package from pom.xml" VERSION_AFTER_CHANGE=`python -c "import xml.etree.ElementTree as ET; print(ET.parse(open('pom.xml')).getroot().find('{http://maven.apache.org/POM/4.0.0}version').text)"` echo $VERSION_AFTER_CHANGE echo "##teamcity[setParameter name='TAG_FROM_VERSION' value='v$VERSION_AFTER_CHANGE']"
El sexto paso es etiquetar la versión de corrección de errores . Esto se hace usando Maven con la opción deseada en Goal .
Opción de objetivos :
-Dtag=%TAG_FROM_VERSION% scm:tag
