Empfehlungen für gitlab im Scrum Workflow

Wer agil Software entwickelt, erledigt das meistens mit Softwaretools wie Jira und gitlab – Jira wird als Issue Tracker verwendet und gitlab als Sourcecode Repository. Bisweilen wird hierbei übersehen, dass gitlab eigene Workflows empfiehlt. Dieser Artikel will exemplarisch zeigen, wie gitlab Workflows sinnvoll in agile Prozesse integriert werden können, die mit Jira gemanaged werden. In einem nachfolgenden Artikel werden dann die Aspekte der Dokumentation in den Systemen ausgearbeitet.

Gitlab ist weit mehr als ein „git Repo Server“ – er bietet neben dem „commit & push“ zwei wichtige Funktionsbereiche, die sich sinnvoll in Jira und den agilen Prozess integrieren lassen:

Continuous Integration und Continuous Deployment (CI & CD)

Im gitlab sich automatisch Scripte starten, sobald ein Ereignis im Repository eintritt (z.B. ein push). Typischerweise erfolgt bei einem Push der Bau der Applikation und die Durchführung von Tests, wobei Docker als Virtualisierungskontext verwendet wird. Commits in spezielle Branches können dazu genutzt werden, automatisch die Software auf einem Zielserver zu deployen. Der Installationsvorgang wird hierbei automatisiert (und damit auch standardisiert). Verbunden mit der Automatisierung ist auch ein veränderter Workflow: die Installation übernimmt kein Admin, sondern jemand der berechtigt ist in den speziellen Branch zu pushen.

Empfehlung für agile Projekte:

Es bietet sich an, ein separates Staging-System und einen Staging-Branch zu führen. Vom Entwickler fertiggestellte Features werden auf das Staging-System deployed, indem sie in den Staging-Branch gepusht werden. Als Staging-Branch kann Master verwendet werden.

Werden die Features am Sprint-Ende vom Product Owner (PO) abgenommen, so können sie auf das Produktionssystem deployed werden – indem auf den Produktionsbranch deployed wird.

Branching Merge Requests (aka Pull Requests)

Git-Branches separieren die Bearbeitung gemeinsamer Objekte/Dateien in getrennte Arbeitsbereiche. Es hat sich eingebürgert, für einzelne Features jeweils eigene Branches zu verwenden – die man deswegen Feature-Branches nennt. Die Entwicklung läuft parallel zum Haupt-Branch komplett im Feature-Branch ab. Bei Fertigstellung muss der Feature-Branch rücküberführt werden in den Haupt-Branch. Da häufig Dateien im Hauptbranch ebenfalls verändert wurden, müssen die daraus entstehenden Konflikte manuell aufgelöst werden (Merge). Gitlab unterstützt die Behandlung von Merge Requests dahingehend, dass man direkt in der gitlab Webanwendung Konflikte auflösen kann.

Mehr noch: Merge Requests können (wie Commits) kommentiert werden; die Kommentare können hierbei zielgerichtet an einzelne Codezeilen gehängt werden. Mit der Durchführung eines Merge Requests lässt sich also auch der Workflow von Code Reviews umsetzen.

Empfehlung für agile Projekte:

Es bietet sich an, für jede Story einen Feature-Branch anzulegen. Eine Story ist „In Progress“, solange der Feature-Branch nicht in den Master gemerged ist.

Verbunden mit dem Merge ist ein Code Review. Dies erfordert die Besetzung der Rolle „System Integrator“. Geeignet sind Personen mit Kenntnis der Programmiersprache, der Werkzeuge und der Architektur.

Per CI&CD an den Merge gekoppelt sollte ein Test und – bei Erfolg – das Deployment auf das Stagingsystem einhergehen.

Zur „Definition of Done“ einer Story gehört also:

  • Tests wurden durchgeführt (automatsich)
  • Code wurde gereviewed (manuell)
  • Feature ist auf Staging-System installiert (automatisch) und wurde dort gegebenenfalls manuell getestet

Jira Workflows

Jira ist ein hervorragendes Werkzeug für die Steuerung agiler Prozesse. Unglücklicherweise ist es so komplex und kompliziert, dass man gleich eine neue Rolle im Team besetzen darf: diejenige des Jira Administrators.

Für die hier diskutierten Ansätze ist zumindest das Thema „Jira Workflows“ relevant: Mit Jira Workflows wird geregelt, welche Zustände ein Issue (aka Story) haben kann. Für die Menge der Status Werte kann/muss nun festgelegt werden, welche Übergänge zulässig sind, und welche Dialoge beim Übergang angezeigt werden.

Empfehlungen für agile Projekte

Es sollte eine Definition of Done (DoD) festgelegt werden. Wenn zu der DoD gehört, dass die Story durch einen Dritten geprüft werden soll, dann sollte hierfür ein eigener Status angelegt werden (z.B. „Approval“). Es ist sinnvoll, automatisch mit Durchführung des Merge Requests den Issue Status entsprechend zu setzen (z.B. auf „Approval“).

Scrum Workflow und gitlab im Prozess

Das folgende Schaubild zeigt exemplarisch den agilen Workflow, den gitlab Workflow und die Schnittstellen der Workflows:

(Klicken Sie auf das Bild für eine vergrößerte Ansicht)

sprintdoc-gitlab-1

 

  1. Scrum: im Planungsmeeting werden die Stories gesammelt und für den Sprint festgelegt.
  2. Jira: Einzelne Stories sind „todo“ solange sich nicht begonnen sind.
  3. Startet ein Entwickler die Arbeit, so setzt er das Issue auf „in Progress“.
  4. Für jede Story wird ein Feature Branch geöffnet.
  5. Der Entwickler arbeitet lokal, testet lokal, commited lokal.
  6. Git: Zumindest täglich werden lokale Stände auf den Server gepusht, die automatisch per CI getestet werden.
  7. Ist laut Entwickler die Arbeit erledigt, öffnet er einen Merge Request (stark vereinfacht ausgedrückt. Üblicherweise wird der Merge Request beim ersten Push angelegt und als „WiP“ – work in progress – manuell markiert. Der Entwickler signalisiert die Fertigstellung des Features, indem er die WiP Markierung entfernt. Der Systemintegrator prüft die technische Qualität der Lösung per Code Review. Wenn die Prüfung erfolgreich ist, wird der Branch gemerged.
  8. Git: Sobald der Merge durchgeführt wurde, wird automatisch das Staging-System aktualisiert.
  9. Nun beginnt das Fachliche Review – bspw. durch den Team Lead oder Product Owner – auf dem Staging-System.
  10. Falls das Feature nicht vollständig oder richtig implementiert wurde, geht es (noch innerhalb des Sprints) zurück in die Entwicklung. Die Entwicklung wird im selben Feature-Branch weitergeführt (stark vereinfacht ausgedrückt; mit dem Merge Request wird der Feature-Branch in der Regel gelöscht. Bei der Fortsetzung der Entwicklung wird einfach ein neuer Branch – mit dem selben Namen wie vorher – angelegt.)
  11. Das geht solange, bis das Feature vollständig implementiert wurde.
  12. Parallel können weitere Entwickler an anderen Stories / Feature-Branches arbeiten.
  13. Scrum: Im Review Meeting  können alle Stories / Features im Verbund auf dem Staging-System vom Product Owner begutachtet werden.
  14. Die vom PO abgenommenen Features können nun per CD auf das Produktionssystem übertragen werden – das Release / Product Inkrement wird verfügbar gemacht. Der Sprint ist abgeschlossen.

Optimierung des Ablaufs

Etwas unglücklich in dem oben formulierten Ablauf ist, dass die fachlichen Reviews innerhalb des Sprints am zentralen Staging-System stattfinden: die Features können nicht isoliert getestet werden, sondern immer nur im Verbung mit anderen Features, die bereits deployed wurden. Konkretes Problem: Wird ein Feature A gemerged welches die Systemverfügbarkeit stört, so kann auch nicht Feature B getestet werden.

Aber selbst wenn nichts kaputt geht – die Auswirkung eines einzelnen Features lassen sich häufig nicht differenziert beurteilen, wenn permanent Updates eingespielt werden.

Eine Lösung hierfür besteht darin, dem fachlichen Reviewer das Feature in einem Virtualisierungs-Container zur Verfügung zu stellen – er sieht dann die Auswirkungen der Implementation so, wie es der Entwickler sieht. Gitlab nutzt bereits Docker als Prozessvirtualisierung für die CI-Tests. Es ist naheliegend, diese Virtualisierung auch in die Entwicklungsumgebungen und in den Arbeitsplatz des fachlichen Reviewers auszurollen.

sprintdoc-gitlab-4

  1. Psuhes werden im gitlab als Container Images abgebildet und dort archiviert
  2. Entwickler arbeitet optimalerweise lokal ebenfalls mit einem dem Produktionssystem ähnlichen Container Setup
  3. PO / fachlicher Reviewer kann das Feature in einem lokalen Kontext prüfen, indem er exakt dasjenige Containerimage zum Testen verwendet, welches im gitlab mit dem Push verwendet wurde.
  4. Wenn Produktions- und Testsystem ebenfalls als Containersystem verwaltet wird, erleichtert das die Wartung der Systeme.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.