Branch name convention:
story/<jira-id>_<story-name>
Rebase the story branch continuosly on master!
Link to the CI build for story branches on the SEEBURGER Jenkins: com.seeburger.airsupply.build-story
If build fails a notification will be sent via jabber or email.
SonarQube is not part of CI-build ⇒ static code analysis should be triggered manually. This should be done at least once after full implementation.
To manually trigger the static code analysis with SONARQube execute the job com.seeburger.airsupply.build-story on the SEEBURGER Jenkins with the following parameters:
After creating the story branch the first commit should be the update of the maven version according to the following convention:
<major>.<minor>.<service>.<alpha>-<jira_id>-SNAPSHOT
Update all POMs:
mvn versions:set -DnewVersion=<new-version-number> -DgenerateBackupPoms=false
For example:
cd D:\dev\git\airsupply mvn versions:set -DnewVersion=12.0.1.4-AIRS-75-SNAPSHOT -DgenerateBackupPoms=false
Wichtig: die POMs getrennt vom Code commiten, so dass sie beim Mergen in den Master rausgenommen werden können. D.h.:
abcdef sein)abcdefTo deliver a story to a new test environment the existing job CreateAirSupplyEnvironmentWithHost on the CD-Jenkins has to be executed with the following parameters:
Regression tests should be run manually against local environment or e.g. OpenStack environment.
After approval → merge into the master.
Do squash(!) → so we will have only one commit per story on master branch.
See also: The end of a topic branch...
Keys will be visible only after approval and transfer to the master branch.
Verify the implementation of your story - Beschreibung des “Verifizierungsjobs” com.seeburger.airsupply.story-verification, der nach dem Implementieren der Story ausgeführt werden soll.
Von master einen eigenen Branch erstellen. Der Name von dem Branch muss mit “story/” anfangen. Z.B. “story/AIRS-75_Blubberbla”, oder “story/rm25124_Blubber”.
Im Maven die Version mit dem folgenden Befehl hochsetzen (“12.0.1.4-AIRS-75-SNAPSHOT” ist natürlich nur ein Beispiel):
cd D:\dev\git\airsupply mvn versions:set -DnewVersion=12.0.1.4-AIRS-75-SNAPSHOT -DgenerateBackupPoms=false
Als Erstes muss man die durch das obige Befehl geänderten POMs pushen. Das ist notwendig um dieses Commit beim späteren Mergen auf Master wieder herausnehmen zu können.
Jetzt Feature entwickeln (bzw. Bug fixen) und pushen. Bei jedem Commit wird automatisch ein Jenkins CI Build gestartet.
Nach dem die Story entwickelt ist, kann man sie verifizieren. Da ich das auf eine einfache Weise nicht machen darf muss ich 2 Schritte machen.
Dazu muss man zuerst mit dem Job “CreateAirSupplyEnvironmentWithHost” eine OpenStack Instanz erzeugen.
Dann auf dieser Instanz einen der AirSupply-Integration-Tests laufen lassen (z.B. wenn PO Collaboration betroffen ist, dann “airsupply-integrationtests-PO-Collaboration”). Wichtig: “Bauen mit Parametern” wählen und dort entsprechende Parameter auswählen. Insbesondere die Version und den Namen der OpenStack-Instanz. Außerdem nicht vergessen Häkchen bei “Skip Issue Creation” zu setzen.
Der einfachere Weg ist: einen speziellen Verification-Job starten. Wie man das konkret macht kann man im Artikel des DEV-Blogs Verify the implementation of your story nachlesen.
Das Blöde an diesem Weg: der Job ist auf dem “Seeburger-Jenkins”, d.h. ich darf ihn nicht starten. D.h. ich muss jemanden bitten, den Job für mich zu starten. Den Schritt kann man leider nicht rauslassen, da noch eine SonarQube Analyse läuft.