Konspekt von http://10.15.100.164/index.php/2018/02/15/impacts-of-scrum-on-the-dev-process/

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:

• gitbranch > The name of the story branch (e.g. story/4711_ProvideXLSDownload)
• sonarbranch > A unique identifier used as project name in SONARQube (e.g. story-4711). Allowed characters are alphanumeric, ‘-‘, ‘_’ and ‘.’.

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.:

1. Branch erstellen
2. POMs taggen
3. Commiten (z.B. Commitname wird abcdef sein)
4. Story/Task entwickeln
5. Commiten …
6. Merge in den Master OHNE commit abcdef

To deliver a story to a new test environment the existing job CreateAirSupplyEnvironmentWithHost on the CD-Jenkins has to be executed with the following parameters:

• param_webapp_version > Maven version of the story (e.g. 12.0.0.0-4711-SNAPSHOT)
• param_openstack_instance_name > Choose a name which does not yet exist to avoid killing an existing instance in OpenStack (e.g. airsupply_story_4711)
• other parameters > keep default values

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.