Mit Custom-Merge-Checks für Bitbucket individuelle Compliance- und Qualitätsanforderungen im Merge-Prozess abbilden

In das Produktivsystem eines Software-Teams soll ausschließlich hochqualitativer Code eingeführt werden. Um das zu gewährleisten, bieten moderne Quellcode-Management-Systeme und CI/CD-Pipelines wie Bitbucket diverse Mechanismen, die den Teams manuelle Arbeit abnehmen – beispielsweise die, Pull-Requests mit Blick auf bestimmte Qualitäts- und Operationalisierungskriterien zu prüfen, ehe sie in die Haupt-Codebasis gemergt werden. Zu diesen Automatisierungen gehören sogenannte Merge-Checks.

Merge-Checks in Bitbucket – Vorteile und Grenzen

Falls Bitbucket in deinem Team bereits Teil der täglichen Entwicklungsarbeit ist, bis du sicherlich mit den bestehenden Merge-Checks vertraut, die durchlaufen werden müssen, bevor ein Pull-Request gemergt werden kann.

Bei Merge-Checks handelt es sich quasi um Testfälle für Pull-Requests: Sie prüfen, ob ein Pull-Request die für das entsprechende Repository vorgesehenen Anforderungen erfüllt hat. Diese Merge-Checks lassen sich auf Repo-Ebene oder auf Projekt-Level konfigurieren.

Je nach Team, haben Merge-Checks mehrere Funktionen. Häufig dienen sie als Mechanismus, um Compliance-Anforderungen bezüglich der Codebasis bzw. der Services durchzusetzen. Außerdem nutzen manche Teams, in denen es spezifische Regeln und Prozesse gibt, Merge-Checks, um die Einhaltung dieser Abläufe zu gewährleisten. Diese Compliance-Anforderungen und Teamprozesse sind allerdings so vielfältig wie die Organisationen und Teams. Deshalb gibt es leider keine vorgefertigte Lösung der Marke One Size Fits All.

Das galt bisher auch für die Merge-Check-Implementierung in Bitbucket Cloud. Die Liste vordefinierter Checks ist nicht erweiterbar. Das Team kann lediglich per Basiskonfiguration anpassen, auf welche Kriterien hin ein Merge-Check testen soll (beispielsweise die Anzahl der erforderlichen Builds oder die Anzahl erforderlicher Freigaben).

Custom-Merge-Checks auf Basis von Forge

Nun hat Atlassian ein Feature vorgestellt, das es deinem Team erlaubt, seine ganz eigenen Merge-Checks zu erstellen, um seine unikalen Testfälle abzubilden: die Custom-Merge-Checks. Auch hier gilt: Diese Checks werden im Verlauf des Pull-Request-Lebenszyklus ausgelöst; bevor sie nicht durchgelaufen sind, kann ein Pull-Request nicht gemergt werden. Doch im Unterschied zu den Standard-Merge-Checks in Bitbucket kannst du frei definieren, welche konkreten Prüfungen sie durchführen.

Als Basis dieser neuen Möglichkeiten dient Atlassians Erweiterungsplattform Forge. Sie bietet zahllose nützliche Features, aus denen sich individuelle Merge-Checks aufbauen lassen: Oberflächenkomponenten, den Forge-Storage, die einfache, aber sichere Authentifizierung für Bitbucket-APIs.

Ein weiterer Vorteil von Forge besteht in der positiven Developer Experience, also dem Nutzungserlebnis deines Entwicklungsteams. Forge ermöglicht schnelle Iterationen und die nahtlose Integration von Bitbucket-Cloud-APIs. Und da es sich bei Forge um eine Function-as-a-service-Plattform handelt, müssen App-Entwicklungsteams keinerlei Infrastruktur aufsetzen und pflegen, um Funktionalitäten wie die individuellen Merge-Checks zu erschaffen.

In Bitbucket Cloud sind Forge-Apps in Workspaces installiert. Alle Repositories, die in diesem Workspace enthalten sind, haben Zugriff auf die Custom-Merge-Checks, die durch die App bereitgestellt werden. Ihre Durchsetzung wird jedoch auf Repo-Ebene in den Repository-Einstellungen konfiguriert.

Die Notwendigkeit individueller Merge-Checks

Wenn Software-Tools wachsen und eine immer komplexer werdende Organisation unterstützen müssen, ergibt sich ein fundamentales Problem: Es entstehen immer umfangreichere und teils sehr spezifische Anforderungen, die eine Software selten aus der Standardfunktionalität heraus erfüllen kann.

Das führt wiederum dazu, dass fürchterlich komplizierte, schwerfällige, unübersichtliche Enterprise-Software entsteht, wie wir sie alle kennen: Systeme mit 1.000 Features, wobei 990 davon nur bei einer Hand voll Kunden je zum Einsatz kommen. Solche Kolosse sind kaum zu warten, erfordern einen riesigen Schulungsaufwand und ersticken Innovationen, denn jedes neue Feature, das der Codebasis hinzugefügt wird, erhöht die Komplexität zusätzlich.

Bitbucket verfolgt hingegen das Ziel, eine leistungsstarke, jedoch einfach zu nutzende Lösung bereitzustellen, die den Vorteil hat, dass dein Team seine eigenen, spezifischen Logiken direkt in die Kern-Workflows des Produkts einbinden kann. Das versetzt dich in die Lage, auch komplexe oder sehr branchenspezifische Anforderungen und Use-Cases in Form spezifischer Prozess- und Richtlinienkontrollen nahtlos in deine Bitbucket-Prozesse zu implementieren. Gleichzeitig vermeidest du das Risiko des Komplexitäts-Overkills, indem du Bitbucket erlaubst, sich auf die SCM- und CI/CD-Kernfunktionen und -Workflows zu fokussieren.

Außerdem entsteht durch diesen Ansatz ein leistungsfähiges Framework, das Marketplace-Partner dabei unterstützt, Apps für spezifische Kundenprobleme zu entwickeln, die das Basisprodukt nicht nativ abbildet.

Was können die individuellen Merge-Checks?

Die Custom-Merge-Checks bieten ein Gerüst, das spezifische Teams und ganze Organisationen in die Lage versetzt, Lösungen für ihre unikalen Herausforderungen zu bauen – direkt auf der Basis namens Bitbucket. Es gibt eine endlos lange Liste von Use-Cases und Testfällen, die sich mit individuellen Merge-Checks abdecken lassen. Hier nur ein paar Beispiele:

Die Titel aller Commits/Pull-Requests beinhalten Jira-Vorgänge.
Pull-Requests können nicht außerhalb der Präsenzzeiten des Teams gemergt werden.
Pull-Requests können nicht gemergt werden, während ein Release-Blocker oder ein Incident vorliegt.
Es gibt Code-Owner und damit obligatorische Freigaben von Standard-Reviewern, je nachdem, welche Dateien im Pull-Request geändert wurden.
Security-Scans wurden durchgeführt.
Ein Pull-Request darf nicht zu groß oder komplex sein.
Ein Pull-Request kann nicht gemergt werden, wenn Abhängigkeiten zu anderen Pull-Requests bestehen.
Ein Pull-Request kann nicht gemergt werden, wenn zu viel Zeit seit der letzten Aktualisierung vergangen ist.
Es müssen bestimmte Standards für die Pull-Request-Beschreibung erfüllt sein.
Feature-Flags müssen verlinkt sein.
Ein Minimum an Unit-Testabdeckung ist gegeben.

Checks für Pull-Requests werden als Reaktion auf "Trigger" ausgeführt, die die Check-App überwacht. Aktuell sind zwei Trigger implementiert; weitere sollen in absehbarer Zeit folgen.

on-code-pushed – Wird getriggert, wenn der Source-Branch eines Pull-Requests aktualisiert wird. Es handelt sich um einen asynchronen Merge-Check. Ein Pull-Request kann nicht gemergt werden, ehe nicht alle durch on-code-pushed getriggerten Checks absolviert sind.

on-merge – Wird während des Merge-Prozesses ausgelöst. Die getriggerten Checks werden unmittelbar vor dem tatsächlichen Git-Merge synchron aufgerufen. Fallen sie negativ aus, wird der Merge abgebrochen.

Der Pull-Request-Workflow mit individuellen Merge-Checks

In diesem kurzen Demovideo sind für das Repository zwei individuelle Merge-Checks aktiviert. Der erste stellt sicher, dass alle Commit-Nachrichten im Pull-Request einen Jira-Vorgang enthalten. Er wird durchgeführt, wenn der Pull-Request initial erstellt wird und wann immer neue Commits zum Source-Branch gepusht werden.

Ist der Check erfolgreich absolviert, kann der Pull-Request gemergt werden. Der Merge-Dialog zeigt die on-merge-Checks, die als Teil des Merge-Prozesses durchgeführt werden. So wird gewährleistet, dass der Pull-Request-Titel einen Jira-Vorgang enthält.

Ein Klick auf den Merge-Button löst die Ausführung des zweiten Checks aus; nachdem er absolviert ist, beginnt der Git-Merge-Prozess und der Pull-Request wird geschlossen.

(An dieser Stelle ist es wichtig, hervorzuheben, dass die individuellen Checks neben den Original-Merge-Checks laufen. Wenn die neue Funktionalität aktiviert ist, empfiehlt es sich, vor dem Mergen sowohl die ursprünglichen als auch die Custom-Merge-Checks zu absolvieren.)

Die moderne DevOps-Automatisierungsplattform

Die Custom-Merge-Checks sind offiziell ausgerollt – du kannst sie also direkt einsetzen! Damit macht Bitbucket Cloud einen wichtigen und nützlichen Schritt hin zu einer rundum individualisierbaren DevOps-Automatisierungsplattform und stellt Entwicklungsteams ein Feature zur Verfügung, das hilft, im Rahmen des Merge-Prozesses eine Vielzahl von Compliance- und Qualitätsanforderungen abzubilden.

Hast du Fragen? Willst du mehr über Atlassians SCM-System Bitbucket erfahren? Würdest du die Lösung gerne unverbindlich testen? Melde dich bei uns: Unsere Atlassian-Fachleute freuen sich darauf, mit dir ins Gespräch zu kommen!