Mit der Zunahme der Virtualisierung und durch Anforderungen an ein stets verfügbares System haben Teams im IT Betrieb oftmals das Ziel, die Verfügbarkeit bei 99.999% zu halten. Ingenieure, die für die Verlässlichkeit einer Seite zuständig sind, halten es für sinnvoll, immer vorbereitet zu sein. Da ein zuverlässiges Git für betriebsinterne Prozesse extrem wichtig ist, bleibt die Frage, wie sich das in Angesicht unvorhersehbarer Ereignisse realisieren lässt.

Setzt man verteilte Versionskontrolle wie Git ein, so ist man bereits durch das Design des Werkzeugs gegen Desaster bzw. Totalausfälle abgesichert. Wenn ein “Upstream Host” nicht mehr verfügbar ist, können Entwickler lokal weiterarbeiten, allerdings ohne die Möglichkeit, Änderungen zu verfolgen. Das senkt die Kosten der verlorenen Produktivität zwar deutlich, gänzlich vermeiden lassen sich diese aber nicht. Zwar ist es nicht mehr möglich, Software mittels CI/CD Werkzeugen zu bauen oder zu veröffentlichen – allerdings ist ein Vorankommen durch lokales Arbeiten möglich.

Je größer das Unternehmen, desto mehr Teams sind abhängig von der Zuverlässigkeit eines robusten Prozesses rund um die Handhabung von Komplettausfällen. Die Funktionalität der in Bitbucket Data Center mitgelieferten Disaster Recovery multipliziert die Vorteile von Git für Software Teams.

Smart Mirrors, Data Integrity Health Checks und die beständige Weiterentwicklung von Bitbucket Data Center helfen, die Kosten durch den Ausfall klein zu halten und eine schnelle Wiederaufnahme des Systems zu ermöglichen.

Smart Mirrors

Die geographische Verteilung der Teams und der physischen Infrastruktur spielt eine große Rolle in der Software-Entwicklung. Smart Mirrors in Bitbucket Data Center reduzieren die Latenz bei Clone- und Fetch-Operationen, indem CI/CD-Werkzeuge ihr hohes Volumen an Anfragen an einen Smart-Mirror absetzen und nicht die primäre Instanz belasten.

Bei einem Ausfall bieten Smart Mirrors einen entscheidenden aber nicht direkt offensichtlichen Vorteil. Während Git es Entwicklern ermöglicht, die Arbeit lokal fortzuführen, erlauben es Smart Mirrors weiterhin Clone- und Fetch-Operationen durchzuführen, selbst wenn die primäre Instanz nicht verfügbar sein sollte. Sind Entwickler in einen Smart Mirror eingeloggt, so können sie diesen nutzen, bis der User-Cache abgelaufen ist und der Login nicht mehr funktioniert. Solange die primäre Instanz nicht verfügbar ist, funktioniert kein git push. Demnach müssen Änderungen lokal vorgehalten werden.

Durch Smart Mirrors ist es möglich, an unternehmenskritischer Software weiterzuarbeiten – auch falls ein Totalausfall passieren sollte. Hierdurch werden die Produktivitätseinbußen reduziert.

Integrity Health Checks

Auf einer Bitbucket-Instanz, die viele Benutzer hat und in der sehr viel passiert, ändern sich Daten konstant. Pull Requests werden geöffnet, geschriebener Code wird eingespielt und Jira-Vorgänge werden erledigt.

AppLinks zwischen Bitbucket, Jira oder anderen Apps bieten unzählige Vorteile, machen einen Ausfall dadurch allerdings auch umso folgenreicher.

Hinweise auf ein mögliches Fehlverhalten durch den Verlust von Datenintegrität kann vor schlimmeren Konsequenzen bewahren. Unstimmige Daten nach einem Disaster Recovery-Prozess sorgen für eine Inkonsistenz zwischen Informationen und Kommunikation. Pull Requests könnten sich möglicherweise wieder öffnen und eine Änderung im Vorgangsstatus in Jira hervorrufen, falls Sie mit Workflow-Triggern arbeiten. Plötzlich werden Sie mit Anfragen überhäuft, weil Nutzer nicht verstehen, was passiert.

Die Anwendungsinstallation und die Integrität der Daten durch Akzeptanztests zu verifizieren, ist elementar, um auf Disaster-Recovery-Prozesse vorbereitet zu sein. Wenn Sie Bitbucket Data Center im Wiederherstellungsmodus ausführen, korrigiert die Integritätsprüfung fehlerhafte Pull Requests, den Jira Ticket-Status und mehr, falls das System nicht mehr synchron ist. Falls ein Integritätsproblem auftritt, wird eine Nachricht im Anwendungslog (für Administratoren) und im Aktivitätstab in Bitbucket (für Entwickler) hinterlegt. Für Firmen in hochregulierten Geschäftsbereichen (z. B. Finanz- oder Versicherungswesen) sind Datenqualität und -haltung nicht nur Best Practice – sondern oft genug auch Vorgaben durch externe Compliance-Richtlinien.

Git als wichtiger Disaster Recovery Bestandteil

Ein klar festgelegter Disaster Recovery Plan ist ein Muss, wenn man mit einem für den Erfolg unabdingbaren System wie Bitbucket arbeitet. Im Falle einer Störung müssen Code, Pull Requests und Zugriffslogs geschützt sein und gleichzeitig sichergestellt werden, dass Arbeitsprozesse ungestört weiterlaufen können. Allerdings sind die meisten Desaster-Pläne reine Theorie – bis dann der Ernstfall eintritt. Sie sollten nicht so lange warten um herauszufinden, ob ihr Plan funktioniert oder nicht.

Mit genügend Übung ist es möglich, sich als Team für den Ernstfall zu wappnen. Deshalb ist es sinnvoll, sich alle 4 bis 6 Monate oder in einem Rhythmus, der zu Ihrem Team passt, mit dem Bitbucket-Failover-Prozess zu befassen.

Zu einem Pull Request vom Commit aus gelangen

Es gibt immer einen Grund für eine Code-Änderung, aber manchmal ist es schwer herauszufinden, was dieser Grund war. Arbeiten Sie mit Quelltext innerhalb Ihrer IDE (Integrated Development Environment), können Sie meist nachverfolgen, welcher Commit welche Codezeile gebracht hat – aber ein Commit erzählt nicht die ganze Geschichte. Die meisten Konversationen und Diskussionen spielen sich im Rahmen eines Pull Requests ab, wo der gesamte Umfang einer Änderung offensichtlich ist.

Bisher war es schwierig herauszufinden, welcher Commit zu welchem Pull Request in Bitbucket passt. Mit der vorliegenden, neuen Version von Bitbucket Server und Bitbucket Data Center hat Atlassian Pull Requests Links auf Commit-Ebene eingeführt. So ist es möglich, direkt aus dem Commit heraus zum dazugehörigen Pull Request zu springen, um den gesamten Kontext zu verstehen.

JIT (Just-In-Time) Fetching

Eine Clone– oder Fetch-Operation über einen Smart Mirror kann nicht mehr aktuell sein, sollte der Smart Mirror nicht mehr mit der primären Instanz synchron sein (z. B. durch Neustart oder Sync-Prozess). Mit Bitbucket Server und Data Center 5.11 verbessert Atlassian dieses Verhalten. Falls ein Client eine Clone– oder Fetch-Operation ausführt und der Smart Mirror feststellt, dass die lokale Kopie veraltet ist, so versucht der Smart Mirror bevor die Daten an den Client ausgeliefert werden, die Daten mit dem primären Mirror zu synchronisieren.

Quellen und Links:

Das interessiert Sie?

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