In diesem Beitrag wird die Einrichtung der Automatisierung von HotFix in Maven-Projekten mit TeamCity beschrieben.
Um einen HotFix durchzuführen, sind oft viele manuelle Schritte erforderlich:
- Einen Branch für die Version erstellen, auf die Sie den HotFix anwenden möchten
- Den Fehler in der Version beheben
- Die Bugfix-Version im Release-Branch ändern
- Den Bugfix-Versionstag veröffentlichen
Die Punkte 1, 3 und 4 können automatisiert werden.
Bevor wir zum Thema kommen, möchte ich ein wichtiges und komplexes Thema ansprechen — der Versionierung Software. Eine kurze Übersicht über Semver ist auf diesem Screenshot ersichtlich. 
Mehr Informationen finden Sie unter folgendem Link: .
Alle in diesem Beitrag beschriebenen Einstellungen basieren auf und .
Beim Trunk-Based Development muss für jede Version ein eigener Branch erstellt werden. Alle Änderungen (Hotfix) in diesem Release werden in diesen Branch kommittiert.
In diesem Beitrag automatisieren wir folgende Aspekte:
CI-Build
Erstellung einer neuen Version
Erstellung eines Branches für die Version
Änderung der Bugfix-Version
Anforderungen:
- Git-Repository zur Speicherung Ihres Codes. Im Beitrag wird das Repository verwendet .
- TeamCity-Server und -Agent. Sie können Ihren eigenen lokalen TeamCity-Server und -Agent mithilfe von
- Wo immer Ihr Teamcity-Agent ist, müssen Java, Maven und Git installiert sein.
Lassen Sie uns im Teamcity-Projekt "Automation Maven Hotfix" anlegen und dort 4 Aufgaben erstellen.
CI-Build
Branch für Release erstellen
Maven Bugfix-Version erhöhen
Maven Release erstellen
Screenshot des Projekts:
Allgemeine Einstellungen
In allen Aufgaben muss das Kontrollkästchen "Sauberes Build: Alle Dateien im Checkout-Verzeichnis vor dem Build löschen" aktiviert werden, da ich ohne dieses Kontrollkästchen Fehler bekam.
Wir erstellen ein einziges VCS. Die Besonderheiten des VCS sind rot umrandet.
Üblicherweise verwendet VCS das HTTPS-Schema. In Branch-Spezifikation: sind alle Branches und Tags anzugeben:
+:refs/heads/*
+:refs/tags/*Es müssen 4 Konfigurationsparameter erstellt werden.
- BRANCH_FOR_INCREMENT
- TAG_FROM_VERSION
- TEAM_USER
- TEAM_USER_EMAIL
Das Feld Wert in BRANCH_FOR_INCREMENT und TAG_FROM_VERSION sollte leer gelassen werden.
Es muss ein privater Schlüssel hochgeladen/hinzugefügt werden. In allen Aufgaben, außer CI Build, ist ein privater Schlüssel erforderlich.
In jeder Aufgabe, außer CI Build, muss im Abschnitt Build Features der private Schlüssel aktiviert werden.
Beispiel für Maven Release.
CI Build**.
In der Aufgabe CI Build gibt es nur einen Schritt mvn clean test
Maven Release.
In der Aufgabe Maven Release. 2 Schritte. Der erste Schritt überprüft, ob der Branch masterist. Wenn der Branch nicht master, schlägt die Aufgabe fehl.
BRANCH=$(git branch | grep * | cut -d ' ' -f2)
echo "$BRANCH"
if [[ "$BRANCH" != "master" ]]; then
echo 'Der Branch ist nicht master';
echo 'Abbruch';
exit 1;
fi
Der zweite Schritt ist standardmäßig mvn release:prepare mit der Option —batch-mode
Branch für Release erstellen
Um einen Hotfix für das Release zu erstellen, muss ein Branch angelegt werden. Dies erfolgt durch die Aufgabe Branch für Release erstellen. Sie besteht aus 2 Schritten.
Der erste Schritt überprüft, ob der Branch nicht master, und der zweite stellt sicher, dass die Version in der Datei pom.xml das Wort SNAPSHOT
BRANCH=$(git branch | grep * | cut -d ' ' -f2)
echo "$BRANCH"
if [[ "$BRANCH" == "master" ]]; then
echo 'Der Branch ist master';
echo 'Abbruch';
exit 1;
fi
echo "Versionspaket aus pom.xml abrufen"
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 "Überprüfen auf SNAPSHOT"
if [[ $version == "*SNAPSHOT*" ]]; then
echo "******************* W A R N U N G *************************"
echo "************ Du erstellt einen Branch für SNAPSHOTS ******************"
echo "***********************************************************"
exit 1
fi
Der zweite Schritt ändert im developerConnection das Verbindungsprotokoll von HTTPS zu GIT.
# Здесь получаем developerConnection из файла pom.xml
developerConnection=$(xmllint -xpath "/*[local-name() = 'project' ]//*[local-name() = 'developerConnection']/text()" pom.xml | sed 's|scm:git:ssh://||')
echo developerConnection
echo $developerConnection
# Здесь меняем / на : в URL для git_remote_url
git_remote_url=$(echo $developerConnection| sed 's/gitlab.com//gitlab.com:/g')
echo git_remote_url
echo $git_remote_url
git remote set-url origin $git_remote_url
# Если вы не используете ввстроенную возможность Teamcity получения user и email из ~/.gitconfig, то можно указать их здесь
echo 'git config user.name %TEAM_USER%'
git config user.name %TEAM_USER%
echo 'git config user.email %TEAM_USER_EMAIL%'
git config user.email %TEAM_USER_EMAIL%
# Здесь получаем версию из файла pom.xml
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 $version
# Почему-то без fetch выдавало ошибку.
git fetch
if [ `git branch -a | egrep "${version}$"` ]
then
echo "Branch exists"
exit 1
fi
# Создаем бранч той версии, который был в файле pom.xml
echo "Create branch"
git checkout -b $version
# Чистый git всегда предлагает настроить политику отправки.
git config --global push.default simple
# Пушим в ветку совпадающую с версией в pom.xml
echo "Push release branch"
git push --set-upstream origin $version
Maven-Inkrement Bugfix
Die Aufgabe besteht aus 6 Teilen. Man hätte sie refaktorisieren können, aber so funktioniert es auch.
Der erste Schritt — Überprüfung, dass der Branch nicht masterist. Wenn der Branch master fehlt, schlägt die Aufgabe fehl.
BRANCH=$(git branch | grep * | cut -d ' ' -f2)
echo "$BRANCH"
if [[ "$BRANCH" == "master" ]]; then
echo 'Branch ist master';
echo 'Abbruch';
exit 1;
fi
# Hier erhalten wir die Version aus der Datei pom.xml
echo "Version aus pom.xml abrufen"
BRANCH=`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)"`
# Gehe zurück zu dem benötigten Branch.
# Andernfalls zeigt git status einen losgelösten Status an.
# Wir brauchen, dass git status einfach den Branch anzeigt
git checkout $BRANCH
# Exportiere die Bash-Variable in eine Teamcity-Variable zur weiteren Nutzung.
echo "##teamcity[setParameter name='BRANCH_FOR_INCREMENT' value='$BRANCH']"
Zweiter Schritt Maven ändert die Bugfix-Version in der Datei pom.xml.
Ziele: bei maven alles in einer Zeile
build-helper:parse-version versions:set -DnewVersion=${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.nextIncrementalVersion} versions:commit
Dritter Schritt — Ausgabe von Git-Status und anderen Informationen:
echo 'cat pom.xml'
cat pom.xml
echo 'git status'
git status
echo 'git remote -v'
git remote -v
echo 'git branch'
git branch
Der vierte Schritt ändert das Schema der developerConnection von HTTPS auf GIT.
Und pusht die Änderungen in den Branch, der in der Teamcity-Variable %BRANCH_FOR_INCREMENT% angegeben ist.
# Здесь получаем developerConnection из файла pom.xml
developerConnection=$(xmllint -xpath "/*[local-name() = 'project' ]//*[local-name() = 'developerConnection']/text()" pom.xml | sed 's|scm:git:ssh://||')
echo developerConnection
# Здесь меняем / на : в URL для git_remote_url
git_remote_url=$(echo $developerConnection| sed 's/gitlab.com//gitlab.com:/g')
echo git_remote_url
echo $git_remote_url
git remote set-url origin $git_remote_url
# Если вы не используете ввстроенную возможность Teamcity получения user и email из ~/.gitconfig, то можно указать их здесь
echo 'git config user.name %TEAM_USER%'
git config user.name %TEAM_USER%
echo 'git config user.email %TEAM_USER_EMAIL%'
git config user.email %TEAM_USER_EMAIL%
echo 'git add .'
git add .
echo 'git commit -m "Increment bugfix"'
git commit -m "Increment bugfix"
git push --set-upstream origin %BRANCH_FOR_INCREMENT%
Der fünfte Schritt erhält aus der Datei pom.xml die Version und setzt sie in Teamcity Variable TAG_FROM_VERSION. Beachten Sie, dass die Version aus der Datei pom.xml ohne das Buchstabe v davor ist. Das Tag, basierend auf dieser Version, beginnt jedoch bereits mit v.
echo "Version des Pakets aus pom.xml abrufen"
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']"
Der sechste Schritt – Tagging Bugfix Versionen. Dies erfolgt mithilfe von Maven der gewünschten Option in Ziel.
Option Ziele:
-Dtag=%TAG_FROM_VERSION% scm:tag
Quelle: habr.com
