Bitbucket Server (vormals Stash) ist Atlassians Git-Repository-Managementsystem für den professionellen Einsatz im Unternehmen. Für die gerade ausgelieferte neue Version hat Atlassian einige der meistgewünschten Features umgesetzt, die wir hier kurz vorstellen. (Sie sind auch in Bitbucket Data Center verfügbar.)
Wachstum ist die Lieblingsherausforderung, die Unternehmen haben. Mit der Skalierung von Continuous Integration können jedoch begrenzte Ressourcen, fehlendes Tracking von Prozessen, ineffiziente Zusammenarbeit, Sicherheitsrisiken und Probleme beim Nutzermanagement einhergehen. Die neue Version von Atlassians CI-Server Bamboo unterstützt skalierende Entwicklungsteams durch bis zu 250 Build-Agents und weitere nützliche Enterprise-Features nun noch besser.
Pull-Requests in Bitbucket Server (vormals Stash) bieten einen schlanken Weg, um Code-Reviews zum Teil eines Branch-basierten Entwicklungs-Workflows zu machen. Diese Pull-Requests helfen Entwicklern, nun noch schneller zusammenzuarbeiten. Außerdem hat Atlassian den Branch-Berechtigungen eine hilfreiche Funktion spendiert, um Ausnahmen festzulegen.
Jeder Entwickler wird die Situation kennen: Er sieht eine Fehlermeldung und ist sich nicht sicher, von welchem Teil des Codes sie kommt. Oder er kennt den Funktionsnamen, weiß aber nicht, welches Repository den Code dafür enthält. Jedenfalls ist es lästig und ineffizient, das nun herauszufinden. Auf vielfachen Kundenwunsch hat Atlassian dem nun ein Ende bereitet und seinem Git-Repository-Managementsystem Bitbucket Server (vormals Stash) eine Code-Suche spendiert.
In zwei vorangehenden Artikeln zum Thema haben wir zuletzt besprochen, wie sich der Continuous-Delivery-Workflow im Rahmen des Branch-per-Issue-Vorgehens gestaltet. In Teil 1 wurde der Basisablauf vorgestellt, ehe wir in Teil 2 auf die Besonderheiten bei der Entwicklung von SaaS-Produkten auf der einen und installierten Produkten auf der anderen Seite eingegangen sind. Nun kommen wir zum CD-Workflow für Gitflow-Projekte.
Im ersten Artikel zum Continuous-Delivery-Workflow im Rahmen des Branch-per-Issue-Modells haben wir uns den Ablauf in seiner allgemeinen Form angesehen. Nun sollen Besonderheiten diskutiert werden, die bei der Entwicklung von SaaS- und von Installationsprodukten zu berücksichtigen sind.
Vor allem in großen Software-Unternehmen mit großen Projekten und großen Repositories (die die beteiligten Teams womöglich noch quer durch die Welt miteinander teilen) werden die Entwicklungs-Tools oft bis an ihre Grenzen ausgereizt. Bei massiver Skalierung kann auch Git an seine Grenzen stoßen und so ineffizient werden, dass es die Produktivität im Projekt signifikant beeinträchtigt. Um dem entgegenzuwirken, hat Atlassian für Bitbucket das Feature Smart Mirroring ausgeliefert, das nun in Bitbucket Data Center verfügbar ist.
Ein Branch-per-Issue-Workflow lässt sich exzellent in die Systemlandschaft von Atlassian-Tools integrieren und wird so zu einer mächtigen und zudem einfachen Praxis. Der Name sagt es bereits: Für jedes Stück Arbeit, also jeden Vorgang oder auch jede einzelne Code-Änderung, wird ein Entwicklungs-Branch erstellt – und mit JIRA Software ist das auch lückenlos und einfach nachvollziehbar. Dann erfolgt die ganze Implementierungs- und Testarbeit am Branch. Wenn wir fertig sind, setzen wir einen Pull-Request ab, mergen und releasen. Sehen wir uns diesen Prozess mit Unterstützung von Atlassian-Werkzeugen Schritt für Schritt an.
Atlassian entwickelt Bitbucket nach wie vor schnell und intensiv weiter. Mit kürzlich ausgelieferten Features deckt das Git-Repository-Managementsystem die Anforderungen professioneller Software-Teams noch besser ab: Smart Mirroring, Git Large File Storage und Projekte.
Im ersten Teil des Tutorials haben wir uns angesehen, was serverseitige von lokalen Git-Hooks unterscheidet und uns mit pre-receive das erste gebräuchliche serverseitige Skript näher angesehen. Daran knüpfen wir nun an und diskutieren zwei weitere Hooks.
