====== 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/_** 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:\\ **...--SNAPSHOT** Update all POMs: mvn versions:set -DnewVersion= -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.: - 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): cd D:\dev\git\airsupply mvn versions:set -DnewVersion=12.0.1.4-AIRS-75-SNAPSHOT -DgenerateBackupPoms=false ==== 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.