Wenn wir bei der Renuo neue Software entwickeln, folgen wir einem ganz bestimmten Arbeitsablauf. Wir nennen ihn den «Renuo Flow». Der Renuo Flow besteht aus Regeln und Konventionen für «Rapid Development». Ich werde nun Werkzeuge und Prozesse beschreiben, die aufzeigen, wann wir eine Programmierung als «fertig» definieren. Ursprünglich haben wir uns vom Git Flow inspirieren lassen, ihn aber im Laufe der Zeit angepasst und vereinfacht, um ihn genau an unsere Bedürfnisse und die unserer Kundschaft anzupassen.
Unser Basiszweig heisst immer «develop». Wir arbeiten an «feature/ branches». Je nach Komplexität eines neuen Features erstellen wir mehrere Branches.
👉 Wir halten unsere Feature-Branches so klein wie möglich. Bei komplexen Funktionen wird erwartet, dass wir sie auf mehrere Branches aufteilen.
Continuous Integration / Continuous Deployment
Sowohl der Haupt- als auch der Entwicklungsbranches sind über CI/CD mit einer Umgebung (main vs. develop) verbunden.
Dies garantiert unserem Entwicklungsteam, dass die neueste Version des Codes in jedem Branch auch die Version des Codes ist, die in der entsprechenden Umgebung läuft.
🔥 Wir arbeiten derzeit an der Zulassung von Review Apps.
Unser primäres und beliebtes Tool für CI/CD ist SemaphoreCI. Nichts kann veröffentlicht werden, wenn das CI nicht grün ist.
Zusammenführen auf Develop
Da Develop unser Basis-Branch ist, stellt sich die Frage: «Wie bringen wir Features auf den Develop?» Was ist nötig, damit wir unseren Code aus einem Feature-Branch in den Basis-Branch bringen können? Denn sobald der Code auf Develop ist, wird er automatisch für eine Develop-Umgebung (auch bekannt als Integrations- oder Vorproduktionsumgebung) freigegeben und ist bereit, live getestet zu werden.
Dazu befolgen wir eine entscheidende Regel: «Du kannst einen Feature-Branch in die Entwicklungsumgebung einbringen, wenn die Schaltfläche grün ist». Mit anderen Worten: «Wenn die Schaltfläche grün ist, kannst du dein Feature für den Develop freigeben».
Die grüne Schaltfläche
Von welcher grünen Schaltfläche ist hier genau die Rede? Wir sprechen von der GitHub-Schaltfläche «merge» (engl. für zusammenführen).
Sobald der Merge-Button grün ist, klicken wir ihn an und führen unser Feature in die Develop-Umgebung ein. Das bedeutet, dass jeder Branch einen Pull Request benötigt. Jeder Pull Request muss, bevor er zusammengeführt wird, unsere Qualitätsbarriere durchlaufen.
Die Qualitätsbarriere
Ohne unsere Qualitätsbarriere zu durchlaufen, kann nichts auf develop (und damit auf main) landen. Die Qualitätsbarriere besteht aus manuellen und automatischen Prüfungen. Hier eine Liste aller Tests:
Automatisierte Tests
Zeilenabdeckung von 100%
Code Linters
Statische Analyse für Sicherheitsschwachstellen
Alle Tests funktionieren
Manuelle Tests
Eingeführte/angepasste Systemtests
Visuelle Anpassungen
Code Reviews
Wenn auch nur eine dieser Prüfungen noch läuft, bleibt die Schaltfläche rot, und das Feature kann nicht zusammengeführt werden.
Wenn eine der Prüfungen fehlschlägt, wird die Schaltfläche automatisch rot.
☝ Alle Administrator:innen können einen Pull Request auch bei roter Schaltfläche zusammenführen. Alle unsere Mitarbeitenden sind Administrator. Alle können jederzeit die oben definierten Regeln ausser Kraft setzen, sollte dies nötig sein. Alle, die bei der Renuo arbeiten, sind verantwortungsbewusst genug, diese Entscheidung weise zu treffen. Bei uns kommen menschliche Entscheidungen immer vor maschinellen Entscheidungen.
Release (engl. für Freigabe)
Nun wissen wir, wie ein neues Feature von einem Feature Branch in den Develop gelangt. Doch wie bekommen wir es in die Hauptumgebung? Der Freigabeprozess kann von Projekt zu Projekt variieren: Er hängt von den beteiligten Personen und den Bedürfnissen der Kundschaft ab. Für jedes Projekt ist ein eigener Prozess definiert, wie die Freigabe funktioniert und wer das «Go» gibt. Dennoch gelten immer folgende Punkte:
Das Entwicklerteam hat das Feature getestet
Die Projektleitung hat es getestet
Die Kundschaft hat es getestet
Die Kundschaft/Projektleitung hat «grünes Licht» gegeben.
Auch hier handelt es sich um eine Faustregel; alle diese Schritte sind nicht zwingend erforderlich:
Das Entwicklerteam mag automatisierten Tests vertrauen
Die Projektleitung ist nicht in der Lage, das Projekt zu testen (Refactorings)
Normalerweise sagen wir unseren Kund:innen, wann ein Test notwendig ist. Das Projekt verfügt vielleicht über Continuous Deployment oder sogenannte Deployment Windows.
Redmine
Redmine – unsere Projektmanagement-Software – ist die Schnittstelle zwischen uns und unserer Kundschaft. Der Status von Tickets spiegelt den oben beschriebenen Ablauf wider.
Jedes Ticket kann in Redmine entweder von uns oder der Kundin erstellt werden. Das Ticket beginnt mit dem Status «schätzen» und wird von uns oder dem Kunden geschlossen, wenn es live ist.
Definition of done
Und damit haben wir unsere «definition of done» fertiggestellt.
✅ Ein Feature gilt als erledigt, wenn das Ticket geschlossen ist.
