vwiki

User Tools

Site Tools

Trace: • gfn_einfuehrungsveranstaltung
impact_of_scrum_on_the_dev_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
impact_of_scrum_on_the_dev_process [2018/04/10 16:10] – [5. Abschließen] kalaschnikowimpact_of_scrum_on_the_dev_process [2019/04/08 15:56] (current) – [5. Abschließen] kalaschnikow
Line 1: Line 1:
 +====== Impact of SCRUM on the DEV process ======
 +Konspekt von http://10.15.100.164/index.php/2018/02/15/impacts-of-scrum-on-the-dev-process/
 +
 +===== Dedicated story branches =====
 +
 +Branch name convention:\\ 
 +**story/<jira-id>_<story-name>**
 +
 +Rebase the story branch continuosly on master!
 +
 +===== CI-Build =====
 +Link to the CI build for story branches on the SEEBURGER Jenkins: 
 +[[https://build.seeburger.de/build/view/SupplyOn/view/Airsupply/job/com.seeburger.airsupply.build-story/|com.seeburger.airsupply.build-story]]
 +
 +If build fails a notification will be sent via jabber or email.
 +
 +===== SonarQube =====
 +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 [[https://build.seeburger.de/build/view/SupplyOn/view/Airsupply/job/com.seeburger.airsupply.build-story/|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 ‘.’.
 +
 +===== Delivery =====
 +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:
 +<code bash>
 +mvn versions:set -DnewVersion=<new-version-number> -DgenerateBackupPoms=false
 +</code>
 +
 +For example:
 +<code bash>
 +cd D:\dev\git\airsupply
 +mvn versions:set -DnewVersion=12.0.1.4-AIRS-75-SNAPSHOT -DgenerateBackupPoms=false
 +</code>
 +
 +**Wichtig**: die POMs getrennt vom Code commiten, so dass sie beim Mergen in den Master rausgenommen werden können. D.h.:
 +  - Branch erstellen
 +  - POMs taggen
 +  - Commiten (z.B. Commitname wird ''abcdef'' sein)
 +  - Story/Task entwickeln
 +  - Commiten ...
 +  - Merge in den Master OHNE commit ''abcdef''
 +
 +==== Deliver the story ====
 +To deliver a story to a new test environment the existing job [[http://10.11.20.56:8180/jenkins/view/TestEnvOnDemand/job/AirSupply-TestEnvironments/job/CreateAirSupplyEnvironmentWithHost/|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
 +
 +===== Automated regression tests =====
 +Regression tests should be run manually against local environment or e.g. OpenStack environment.
 +
 +===== Story approval =====
 +
 +After approval -> merge into the master.
 +
 +Do squash(!) -> so we will have only one commit per story on master branch.
 +
 +See also: [[http://10.15.100.164/index.php/2018/01/26/the-end-of-a-topic-branch/|The end of a topic branch...]]
 +
 +===== Jabylon =====
 +Keys will be visible only after approval and transfer to the master branch.
 +
 +===== Weiterführende Links =====
 +[[http://10.15.100.164/index.php/2018/03/05/verify-the-implementation-of-your-story/|Verify the implementation of your story]] - Beschreibung des "Verifizierungsjobs" [[https://build.seeburger.de/build/view/SupplyOn/view/Airsupply/job/com.seeburger.airsupply.story-verification/|com.seeburger.airsupply.story-verification]], der nach dem Implementieren der Story ausgeführt werden soll.
 +
 +
 +===== Alles noch ein Mal mit eigenen Worten =====
 +
 +==== 1. Eigenen Branch erstellen ====
 +
 +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".
 +
 +==== 2. Version hochsetzen ====
 +
 +Im Maven die Version mit dem folgenden Befehl hochsetzen ("12.0.1.4-AIRS-75-SNAPSHOT" ist natürlich nur ein Beispiel):
 +
 +<code>
 +cd D:\dev\git\airsupply
 +mvn versions:set -DnewVersion=12.0.1.4-AIRS-75-SNAPSHOT -DgenerateBackupPoms=false
 +</code>
 +
 +==== 3. POMs pushen ====
 +
 +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.
 +
 +==== 4. Feature entwickeln und pushen ====
 +
 +Jetzt Feature entwickeln (bzw. Bug fixen) und pushen. Bei jedem Commit wird automatisch ein [[https://build.seeburger.de/build/view/SupplyOn/view/Airsupply/job/com.seeburger.airsupply.build-story/|Jenkins CI Build]] gestartet.
 +
 +==== 5. Abschließen ====
 +
 +=== 5.1 Mit zwei CI-Jenkins Jobs ===
 +
 +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 "[[http://10.11.20.56:8180/jenkins/view/TestEnvOnDemand/job/AirSupply-TestEnvironments/job/CreateAirSupplyEnvironmentWithHost/|CreateAirSupplyEnvironmentWithHost]]" eine OpenStack Instanz erzeugen.
 +
 +Dann auf dieser Instanz einen der [[http://10.11.20.56:8180/jenkins/view/ContinuousTesting/job/AirSupply-Integration-Tests/|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.
 +
 +=== 5.2 Mit dem Verification-Job ===
 +
 +Der einfachere Weg ist: einen speziellen Verification-Job starten. Wie man das konkret macht kann man im Artikel des DEV-Blogs [[http://10.15.100.164/index.php/2018/03/05/verify-the-implementation-of-your-story/|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.
 +