Atlassian behält den hohen Release-Takt bei der Enterpise Git Hosting-Lösung Bitbucket Server und Data Center bei und hat Version 5.5 veröffentlicht. Credo der Entwicklung von Software heute: noch ein wenig schneller sein. Umso eher Features, Bugfixes oder Performance-Verbesserungen zum Kunden ausgeliefert werden können, umso größer der Marktvorteil gegenüber der Konkurrenz.

Es gibt viele Möglichkeiten, wie man die Geschwindigkeit insgesamt verbessern kann. Der sicherste Ansatz ist erst einmal, sich selbst produktiver zu machen. Bitbucket Server und Data Center 5.5 möchten genau dies tun: Entwickler dank Verbesserungen wie Personal Access Tokens und Rebase-Workflows produktiver machen.

Sichere Integrationen dank Personal Access Tokens

Der schnelle und einfache Zugang zu Informationen über die Entwicklung ist wichtig. Dies erfordert meistens den Zugriff auf die REST API von Bitbucket Server – egal ob Sie Ihr Wallboard mit Statistiken versorgen oder Daten an die Werkzeuge innerhalb Ihrer Infrastruktur schicken möchten.

Vor Bitbucket Server und Data Center 5.5 musste man auf Basic-Auth setzen, was entweder die eigenen Zugangsdaten oder technische Accounts für das Absetzen der entsprechenden Anfragen an die API erforderte. Das sorgt nicht gerade für Begeisterungsstürme bei den Sysadmins in der IT und regt auch nicht dazu an, mehr Integrationen zu schaffen.

Mit Bitbucket Server 5.5 werden Personal Access Tokens unterstützt, mit welchen anstelle von Basic Auth-Passwörter in Git oder der REST API gearbeitet werden kann. Diese Access Tokens werden von Nutzern erstellt und erben die gleichen Zugriffsrechte des Benutzers exklusive Zugang zum Bitbucket User Interface. Tokens können weiter eingeschränkt werden, zum Beispiel kann lediglich Lesezugriff gegeben werden.

Ein Personal Access Token kann also eingesetzt werden…:

  • … für die Integration mit einer Dritt-Anwendung
  • … als ein Authentifizierungsmechanismus anstelle von Basic Auth
  • … als ein Bearer Token (OAuth2)

Damit müssen Nutzername und Passwort nicht länger in Skripts oder Dritt-Anwendungen. Personal Access Tokens machen Integrationen für alle Nutzer zugänglich, sparen Entwicklern Zeit und reduzieren das Risiko indem die LDAP-Zugänge weniger oft im Klartext abgelegt werden.

Mit Rebase-Workflows die Commit-Historie sauber halten

Ein bei Entwicklern beliebtes Mittel, um Änderungen in die Codebasis zu integrieren: Rebasing. Rebasing beschreibt den Prozess, eine Sequenz aus Commits an einen gemeinsamen Basis-Commit zu hängen und Verzweigungen aufzulösen. So bleibt die Komplexität des Repository-Graphs gering und macht die Commit-Historie einfacher nachvollziehbar. Bis dato war es notwendig, Rebasing manuell auf clientseite durchzuführen, während Merges im Bitbucket Server-User Interface bewerkstelligt werden konnten. Das stellt einen Bruch im Arbeitsablauf dar und ist generell umständlich.

Mit Bitbucket Server 5.5 können Entwickler jetzt direkt im Interface mittels Rebases einen Pull Request-Branch aktuell halten oder Pull Requests generell durchführen. Falls ein Rebase-Workflow ein Mittel ist, auf welches Ihr Team setzen möchte, können Sie Rebasing als Option ganz einfach als Pull Request-Mergestrategie in den Projekt- oder Repository-Einstellungen auswählen.

Atlassian hat auch ein detailliertes Video über das Handling von Rebases in Bitbucket Server Rebases von Principal Product Manager Roger Barnes veröffentlicht:

Zusammenfassend: Rebasing wurde von Atlassian in drei Bereichen eingeführt:

  • Zwei neue Merge-Strategien: Rebase Fast-Forward und Rebase, Merge
  • Pull Requests: Es gibt nun eine Rebase-Aktion, um den Zweig des Pull Requests zu aktualisieren
  • Forks die mit dem Ursprungs-Repo synchronisiert werden sollten, aber nicht aktuell sind, können mit Rebase aktualisiert werden.

Hinweis: Da nicht jeder auf Rebase-Workflows setzen möchte, gibt es in den bitbucket.properties ein Flag, mit dem das Feature global deaktiviert werden kann.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da.