Wie wir Software entwickeln Teil 1: Ver­si­ons­ver­wal­tung

Wir arbeiten schon viele Jahre im und mit dem Internet und gestalten dieses auch schon fast ebenso lange mit. Vieles von dem, was heute für uns selbstverständlich ist, war es vor gar nicht so langer Zeit noch nicht - und geht man mehr als nur ein paar Jahre zurück, stellt man fest, dass sich der Entstehungsprozess einer Website massiv gewandelt hat.

Nun hat sicherlich jede Agentur ihren Weg gefunden, mit diesem Thema umzugehen, und glücklicherweise haben sich auch Industriestandards entwickelt. Mit diese Artikelserie möchte ich unseren Weg vorstellen und zudem versuchen, das Verständnis zwischen allen Projektbeteiligten zu stärken - denn nur gemeinsam kann etwas wirklich gutes entstehen. 

Zunächst einmal möchte ich einige Voraussetzungen postulieren, auf die wir uns bei jedem größeren Projekt vermutlich leicht einigen können: 

• Wir möchten die Website jederzeit in einem Zustand haben, dass wir Updates schnell und sicher einspielen können. 
• Funktionalitäten, die auf der Website im Einsatz sind, gehen durch eine Änderung an anderer Stelle nicht kaputt.
• Wir stellen sicher, dass wir einen vorherigen Zustand der Website jederzeit wieder herstellen können. 
• Änderungen an der Website stellen wir isoliert zur Abnahme bereit, ohne die Integrität der LIVE-Instanz zu gefährden
• Wir können einzelne Änderungen zurückhalten, und andere ausspielen. Zu keiner Zeit darf die Website durch nicht freigegebene Änderungen blockiert sein. 

Das klingt ziemlich einfach und selbstverständlich; leider ist es weder das eine noch das andere. Für all diese Anforderungen gibt es Lösungen. Diese Artikelserie beleuchtet unseren Weg, damit umzugehen. 

Wie auch bei der Entwicklung selbst, müssen dabei mehrere Teile ineinandergreifen. Um den Rahmen unserer Blog-Beiträge nicht zu sprengen, teilen wir diese in einzelne Themengebiete auf. Im ersten Beitrag dieser kleinen Serie beginne ich mit der aus meiner Sicht völlig unverzichtbaren Grundvoraussetzung für jedes Softwareprojekt: Die Nutzung einer Versionsverwaltung!

Grund­vor­aus­set­zung: Wir ver­sio­nie­ren unseren Code

Das sollte in der Tat seit vielen Jahren Standard sein; aus Erfahrung bei dem ein oder anderen Projekt, das wir übernommen haben, müssen wir leider sagen: ist es nicht. Und ich möchte allen den dringenden Rat mit auf den Weg geben: Achten Sie darauf, dass die ausführende Agentur solche grundsätzlichen Tools der Softwareverwaltung verwendet; wenn es schon hieran scheitert, ist oft meist noch viel mehr im Argen. 

Unser Versionsverwaltungssystem erlaubt es uns, Änderungen im Projektverlauf nachvollziehbar zu halten. Damit behalten wir leicht den Überblick, wer wann und aus welchem Grund Code hinzugefügt oder geändert hat. Und wir können jeden beliebigen vorherigen Stand wiederherstellen. 

In unserer Versionsverwaltung haben wir immer mehrere sog. Branches. Im live-Branch ist der Stand der Website, die aktuell auf der Produktionsumgebung deployed ist. In sog. Issue-Branches entwickeln wir die Website weiter oder beheben einen Fehler. Für jedes Ticket, das Kunden in unserem System anlegen, erstellt ein Entwickler einen entsprechenden Branch. Ist die Arbeit getan, durch die interne QA gegangen und vom Kunden schließlich abgenommen, wird der issue-Branch wieder integriert. 

Das Arbeiten mit den issue-Branches erlaubt es uns, die Abhängigkeiten von Änderungen aufzulösen. Oftmals hängt ein Änderungswunsch beim Kunden im Freigabeprozess fest und soll von anderen überholt werden - das alles ist für uns kein Problem. 

Nur mit einem gut gepflegten Versionsverwaltungssystem ist es überhaupt möglich, unproblematisch mit mehreren Entwicklern am selben Projekt zu arbeiten. Und im Rahmen der internen QA gehört insbesondere bei tiefgreiferenden Codeänderungen eine zweite Meinung in Form eines Code-Review dazu; das Versionsverwaltungssystem zeigt exakt an, welcher Code in den Hauptbranch übermittelt werden soll. Ein zweiter Entwickler kann hier wertvolle Hinweise geben, die vorgestellte Lösung zu optimieren. Hiervon profitieren der Entwickler, weil er direkte Rückmeldung und Verbesserungsvorschläge für seinen Code bekommt; der Reviewer, weil er natürlich auch von der vorgestellten Lösung etwas lernen kann, und das Produkt selbst, weil nur geprüfter Code hinzugefügt wird. Das Entwickeln von Code und der Review desselben folgt übrigens keiner Hierarchie: es ist nicht unüblich, dass Junior-Entwickler Code von Senior-Kollegen reviewen und Anmerkungen dazu haben. Für uns ist das in ein wertvoller Beitrag zum internen Wissenstransfer, in alle Richtungen.

Wir nutzen bei uns übrigens git als Versionsverwaltungssystem, und Gitlab als Werkzeug für unsere Reviews (und für unsere Build-Chains, die wir in Teil 3 dieser Reihe beleuchten werden).

Im nächsten Teil dieser Artikelserie nutzen wir die eben geschaffenen Voraussetzungen, um Projekte auf unseren Entwicklungsrechnern schnell an den Start zu bekommen.