Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery

Software-Entwicklung in einem großen Kundenprojekt funktioniert natürlich nicht nach dem Prinzip „Auf die Plätze, fertig, hacken!“ Vielmehr handelt es sich um einen komplexen Prozess, der einerseits hohen Qualitäts- und Sicherheitsanforderungen unterliegt und der andererseits viel Flexibilität bieten muss. In diesem Beitrag zeigen wir auf, wie ein //SEIBERT/MEDIA-Entwicklungsteam in einem Individualsoftware-Projekt ein neues Feature entwickelt, welche Workflows dabei zugrunde liegen und welche Werkzeuge uns in diesem Prozess unterstützen.

Entwicklungsworkflows und Branching-Modelle

Die Entwicklung eines Features beginnt mit einer User-Story, die in einem Vorgang im Projektmanagement- und Tracking-System JIRA festgehalten wird. User-Stories bieten einen einfachen Weg, um Anforderungen aus Nutzersicht klar zu formulieren und haben oft die Form „Als <Art von Nutzer> will ich <bestimmtes Ziel>, damit ich <bestimmter Grund>“. (Hier finden Sie eine Einführung in dieses Konzept.)

Wenn ein Entwickler mit der Arbeit an diesem Feature beginnt, erzeugt er aus diesem JIRA-Vorgang heraus per Klick einen Feature-Branch in der mit dem Ticketsystem verknüpften Git-Repository-Verwaltung Stash. Die Umsetzung erfolgt nach dem Gitflow-Workflow.

Dieser Workflow definiert ein striktes Branching-Modell, das auf die nahtlose Auslieferung von Releases abzielt, und bietet einen robusten Rahmen für das Management großer Software-Projekte.

Der Gitflow-Workflow sieht zwei Branches vor, die die Projekthistorie enthalten. Im master-Branch ist die offizielle Release-History des Projekts abgebildet; der development-Branch ist der Integrations-Branch für Features. Grundsätzlich interagiert kein Branch, in dem ein Entwickler an Funktionen oder Bugfixes arbeitet, mit dem zentralen master-Branch, also dem offiziellen Projekt. Feature- und Bugfix Branches zweigen immer vom development-Branch ab und werden auch nur in diesen reintegriert.

Die einzige Ausnahme bilden Hotfixes, um kritische Fehler im Produktivsystem zu patchen. Diese Änderungen in einem Hotfix-Branch überführen Entwickler direkt in den master. Aussagefähige Prefixes machen Branches für Bugfixes, Hotfixes und Features einfach unterscheidbar und lassen sich in Stash, wie in der folgenden Ansicht erkennbar, konfigurieren (Ein früherer Artikel bietet ausführlichere Infos zu diesem Workflow.)

Stash Branching model

Konfiguration des Branching-Modells in Atlassian Stash

Der Entwickler arbeitet also in seinem Feature-Branch und fügt diesem Commits nach dem gängigen Edit-Stage-Commit-Prozess hinzu.

Testausführung auf dem Integrations-Server Bamboo

Automatisierte Tests sind fester Bestandteil des Entwicklungsprozesses. Im Team kommt dafür der Continuous-Integration-Server Bamboo zum Einsatz. Die unterschiedlichen Testgattungen (siehe hierzu unseren einführenden Artikel über Software-Tests) werden in Bamboo in sukzessiven Stufen getrennt ausgeführt: Isolierte Unit-Tests sollen konkrete Funktionen testen und klammern dabei alle externen Einflüsse aus. Anschließende Integrationstests sollen Fehler aufdecken, die durch das Zusammenspiel der einzelnen Komponenten auftreten können. Über das Ergebnis der Tests werden an den letzten Änderungen beteiligte Mitarbeiter per E-Mail informiert.

Eine Historie der letzten Testergebnisse und diesbezügliche Statistiken können in Bamboo wie in der folgenden Ansicht eingesehen werden:

Bamboo Plan summary

Übersicht über die letzten Testläufe im Bamboo-Integrations-Server

Darüber hinaus sind in Bamboo automatische Merge-Tests zwischen dem Feature-Branch des Entwicklers und dem zentralen development-Branch erforderlich, also dem Integrations-Branch für Features. Auch hier versendet Bamboo im Fehlerfall automatisierte Benachrichtigungen. Treten Konflikte auf, behebt der Entwickler die Merge-Konflikte manuell in seinem Feature-Branch und durchläuft den Testzyklus erneut. Dadurch werden später komplexe Korrekturen zwischen diesen Branches vermieden und Aufwand und Risiko bleiben für den Entwickler überschaubar.

Bamboo Recent plan failures

Kein gern gesehener Gast: Ein fehlgeschlagener Testlauf in Bamboo

Qualitätssicherung und Code-Reviews mit Stash

Sind die Tests erfolgreich durchgelaufen, ist der Feature-Branch bereit für die funktionale Abnahme durch den Product Owner, der im agilen Prozess die Rolle als „Anwalt des Kunden“ einnimmt.

Nach einer Abnahme der funktionalen Anforderungen an das Feature muss die Code-Qualität sichergestellt werden. Dazu bittet der Product Owner im jeweiligen Feature-Branch andere Entwickler im Team in Stash über Pull-Requests, Code-Reviews durchzuführen. Stash unterstützt die Reviewer hier durch eine bequeme Kommentarfunktion und eine optimierte Änderungsansicht, um Modifikationen an Quelltexten schnell nachvollziehen zu können.

Für die Freigabe muss das Feature von mindestens zwei Kollegen (Approver) abgenommen worden sein – diese Muss-Anforderungen für einen Pull-Request lassen sich, wie in der folgenden Ansicht zu erkennen ist, in Stash frei konfigurieren.

Konfiguration der Freigabekriterien für einen Pull-Request im Stash-Server

Konfiguration der Freigabekriterien für einen Pull-Request im Stash-Server

Wird nun ein offener Pull-Request freigegeben, so kann der Feature-Branch in den development-Branch gemergt werden (oder bei Hotfixes auch in den master-Branch). Das Mergen lässt sich dann bequem per Knopfdruck aus Stash heraus bewerkstelligen.

Hierbei bietet Stash eine komfortable Übersicht, um auf Repository-Ebene offene, abgelehnte und bereits gemergte Pull-Requests einzusehen. So kann – auch dank der Verknüpfung zu JIRA – auch im Nachhinein noch bequem recherchiert werden, welche Änderungen in ein Release eingeflossen sind.

Übersicht über integrierte Pull-Requests eines Projekts in Stash

Übersicht über integrierte Pull-Requests eines Projekts in Stash

Continuous Deployment und Continuous Delivery auf Test-, Preview- und Produktiv-Server

Das Deployment eines Release auf den Test-Server erfolgt automatisiert durch Bamboo, sodass den Beteiligten immer ein aktueller Stand der Entwicklung zum Testen zur Verfügung steht. Das Einspielen eines Releases auf den Preview- oder den Produktiv-Server erfolgt aus Bamboo heraus auf Knopfdruck und nur dann, wenn die entsprechenden Tests vorher fehlerfrei durchlaufen wurden.

Um das gesamte Team transparent zu informieren, wird der Deployment-Status mit einem Link auf die Deployment-Übersicht in Bamboo im HipChat-Raum des Entwicklungsteams gepostet. HipChat ist der Chat- und IM-Dienst von Atlassian.

Bamboo Deployment-release

Deployment per Knopfdruck mithilfe des Bamboo-Integration-Servers

Auf dem Preview-System nimmt der Kunde das Feature ab. Ist das geschehen, erfolgt die Integration ins Live-System, und durch einen weiteren Klick in Bamboo wird das Deployment der master-Version auf das Produktivsystem durchgeführt und protokolliert. Nun ist das neue Feature in die Software integriert und für den Endnutzer verfügbar.

Nützlich ist auch hier die Übersicht über erfolgte Deployments in Bamboo, denn so ist leicht einsehbar, welches Release mit welchen Features auf welchen Server deployed worden ist und wo gegebenenfalls Fehler in einem Deployment-Vorgang protokolliert wurden:

Bamboo Related deployments

Deployment-Pipeline-Übersicht im Bamboo-Integrations-Server

Vorteile dieses Prozesses

Das beschriebene Vorgehen hat Vorteile für alle Beteiligten am Projekt:

  • Das Branch-Modell erlaubt störungsfreies Arbeiten an einem Feature in einer sicheren, isolierten Umgebung. Während der Entwicklung kommt es kaum zu Interaktionen mit der zentralen Code-Basis, und das Risiko von versehentlichen Auswirkungen auf die Code-Basis für den Produktionsstand ist damit ausgeschlossen
  • Der Workflow stellt ein hohes Maß an Qualität sicher. Jedes neue Feature muss Unit- und Integrationstests erfolgreich durchlaufen und von anderen Entwicklern reviewt werden. Ein Pull-Request kann nur gemergt werden, wenn mindestens zwei Reviewer Code-Reviews durchgeführt haben. Das gewährleistet eine hohe Code-Qualität und trägt gleichzeitig zur Wissensdistribution über das Team hinweg bei. Nur auf diese Weise verifizierte Änderungen gelangen in den development-Branch.
  • Unser Workflow integriert einen festen Trigger zur funktionalen Abnahme durch den Product Owner.
  • Die Integration von Bamboo reduziert den Aufwand für ein Deployment auf einen Mausklick. Eine Übersicht über die Deployment-Historie ist jederzeit verfügbar.
  • Im Preview-System, das direkt auf dem master-Branch basiert, kann der Kunde neue Features im tatsächlichen Kontext testen.
  • Das Team ist jederzeit über Status und Herausforderungen im Bilde: Informationen im HipChat-Raum schaffen Transparenz; zusätzlich sorgt ein Feedback-Device im Teambüro für eine schnelle Visualisierung von Build-/Test-Fehlern.
Feedback Device für den Build-Status aus Bamboo

Feedback-Device für den Build-Status aus Bamboo

Der Kunde profitiert also von hoher Qualität, größtmöglicher Sicherheit seines Projekts und einer effizienten Umsetzung neuer Funktionen. Der einzelne Entwickler kann fokussierte und produktive Programmierarbeit leisten, während ihm sinnvoll integrierte Tools möglichst viel vom verwaltungstechnischen Overhead abnehmen. Das Team steht auf einer Seite, hat immer denselben Wissensstand und kann sich durch die enge Zusammenarbeit im Test- und Review-Prozess gemeinsam und kontinuierlich fachlich weiterentwickeln.

Ihr Partner für individuelle Software-Projekte

Planen Sie bereits ein konkretes Software-Projekt? Oder gibt es bestimmte Prozesse in Ihrem Unternehmen, die Ihnen schon lange Kopfzerbrechen bereiten? Bremst ein System oder eine Schnittstelle Ihre Mitarbeiter auf der einen oder Ihre Kunden auf der anderen Seite aus? Dann sprechen Sie mit uns darüber! Wir freuen uns darauf, gemeinsam eine individuelle Lösung zu entwickeln – bei höchster Qualität und voller Kostenkontrolle.  Wir legen größten Wert auf Erweiterbarkeit, Performanz, Skalierbarkeit, Plattformunabhängigkeit und Testbarkeit und schaffen individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen.

Weiterführende Infos

Was agile Software-Projekte dem Kunden bringen
Vorgehen nach Scrum: Die beste Wahl für den Kunden, die Agentur – und das Produkt
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo im Entwicklungsprozess
Der Beginn eines Happy Ends: Initialer Anforderungs-Workshop für erfolgreiche Projekte
Darum ist eine regelmäßige Kundenpräsenz beim Entwicklungsteam so sinnvoll

Artikel teilen:Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page