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.
Anfang des Jahres hat Atlassian für die Data-Center-Version seines Git-Repository-Managementsystem Bitbucket das Feature Smart Mirroring ausgeliefert, das Entwicklungsteams hilft, die Zeiten beim Kopieren von Repos deutlich zu reduzieren. Mit Smart Mirroring wurde auch der Large File Storage (LFS) hinzugefügt, der Teams unterstützt, die mit Bilder, Videos und anderen großen Objekten arbeiten. Beide sind für sich prima. Was könnten verteilte Teams aber tun, wenn beide Funktionen kombiniert wären? Das können diese Teams nun testen, denn die aktuelle Version 4.5 von Bitbucket Data Center bietet Unterstützung für Git LFS mit Smart Mirroring.
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.
Ich arbeite mittlerweile seit über 14 Jahren als Entwickler bei //SEIBERT/MEIDA. In dieser Zeit hat sich das Unternehmen (stark) verändert. Während in vielen anderen Unternehmen Design/Konzeption und Entwicklung immer noch getrennte Prozesse sind, hat bei uns der Schritt weg von fachbezogenen und hin zu interdisziplinären Teams die Unternehmenskultur maßgeblich geprägt. Immer häufiger arbeiten Entwickler und Designer direkt zusammen und betreiben Pair Programming im weiteren Sinne. Warum wir das tun, beschreibe ich in diesem Artikel.
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.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenKontakt
Produkte
News
Auszeichnungen
