git-ucs-branches-releases-commands_enSeit einigen Wochen setzen wir im Professional Services Team von Univention sehr erfolgreich git zur Versionskontrolle für unsere Projekte ein. Im Folgenden möchte ich unsere Entscheidung git einzusetzen ein bisschen weiter ausführen, von den ersten, frischen Erfahrungen berichten und einen Ausblick auf die noch offenen Baustellen geben. Vielleicht bekommen Sie für Ihre eigenen Projekte die eine oder andere Anregung oder haben Ideen für uns, wie wir Anforderungen mit git noch besser umsetzen können.

TL;DR

  • Die Migration von SVN zu git und die Nutzung von git als Werkzeug im produktiven Arbeitsablauf sind sehr gut gelaufen.
  • Die Herausforderungen bei der professionellen Einführung sind erheblich, insbesondere in der Vorbereitung des koordinierten Arbeitsablaufs.

Das Leben vor git. Wenn SVN an seine Grenzen stößt

Bisher haben wir in Projekten, genau wie in der Produktentwicklung, SVN eingesetzt und sind damit auch im Großen und Ganzen sehr zufrieden gewesen. Im vergangenen Jahr startete ein sehr großes Projekt, in dem wir auch mit externen Entwicklern zusammenarbeiten. Diese Anforderungen haben wir zum Anlass genommen, einen eigenen SVN-Server in unserer DMZ aufzubauen, um den externen Entwicklern einen einfachen Zugang zu ermöglichen. Git schien zum damaligen Zeitpunkt nicht unbedingt notwendig, inbesondere weil bereits umfangreiche Erfahrungen mit SVN bestehen. Zeitgleich mit dem Start des Projekts haben wir vor ca. 1,5 Jahren das gehostete Projektmanagementwerkzeug plan.io eingeführt, welches auf dem Open Source Projektmanagementwerkzeug Redmine beruht. Mit diesen Ressourcen haben wir erfolgreich gearbeitet und für unsere Software gut 3.000 automatisierte Testfälle entwickelt, jedoch gab es eine ganze Reihe von Problemen in der Softwareentwicklung, die uns immer wieder beschäftigt haben, bzw. demnächst beschäftigen werden:

  • Entwickler können keine halbfertigen Änderungen einchecken, ohne die automatisierten Jenkins-Tests zu stören.
  • Änderungen können nicht vollständig getestet werden, bevor sie in Software einfließen.
  • Zusammengehörige Änderungen sind kaum nachvollziehbar, da zwischenzeitlich andere Entwickler Änderungen an den gleichen Code-Teilen vornehmen.
  • Änderungen müssen zukünftig gleichzeitig für zwei unterschiedliche Softwareversionen gepflegt werden (hier kommt die schlechte Nachvollziehbarkeit wieder zum Tragen).

Zum Glück hat Linus Torvalds nicht nur Linux erschaffen, sondern auch das erstklassige Versionskontrollsystem git entwickelt, welches der allgemeinen Berichterstattung und unseren eigenen, bisherigen Erfahrungen nach all diese Probleme beheben könnte und dazu noch viele weitere nützliche Funktionen bietet. Da unser Projektmanagementwerkzeug plan.io direkte git-Unterstützung bietet, haben wir uns entschlossen, die Migration anzugehen, bevor wir zwei parallele Softwareversionen im Projekt pflegen müssen.

Es geht los! Einführung von git und SVN Migration läuft problemlos

Zur Einführung von git stand zuerst die Migration von SVN an. Im Projekt haben wir sowohl Dokumentation als auch Code in einem SVN-Repository. Da beide Teile sehr umfangreich sind, habe ich mich dazu entschieden, diese zukünftig in zwei separaten git-Repositories zu pflegen. Zur Migration wurde git-svn verwendet, welches die geplante Aufspaltung des SVN-Repositories sehr einfach macht. Bei der Migration gab es keinerlei Probleme. Die gesamte Historie wurde übernommen und auf das Niveau von git gehoben, indem die vollen Namen und E-Mailadressen aller der Personen ergänzt wurden, die jemals etwas zum Repository beigetragen haben. Die Liste der Personen inklusive Nutzernamen und E-Mailadressen konnte ich direkt aus unserem UCS LDAP beziehen und in das von git-svn benötigte Format überführen.

Der erste, sofort sichtbare Effekt der Migration ist die Integration von git-Commits und plan.io-Tickets. Neben den Kommentaren zum Ticket steht die Commit-Historie zu diesem Ticket. Die Qualitätsprüfung kann direkt am Ticket mit dem Review der Code-Änderungen beginnen — dies funktioniert sogar über mehrere Repositories hinweg:

Plan.io und git funktionieren gemeinsam

 

Dieser Teil der Migration verlief völlig unkompliziert und war innerhalb kurzer Zeit abgeschlossen. Im Anschluss wurde unser internes Buildsystem für UCS-Pakete erweitert, sodass aus git-Repositories Pakete importiert werden können.

Herausforderungen bei der Umstellung auf git. Der Mensch ist ein Gewohnheitstier, oder nicht?

Die eigentliche Herausforderung der git-Migration liegt meiner Beobachtung nach darin, das Arbeiten mit git anzunehmen, welches sich deutlich von SVN unterscheidet. Hier ein Auszug aus der linearen SVN-Historie, mit der wir gestartet sind:

svn

 

Gits größte Stärke liegt darin, Versionszweige zu erstellen UND diese wieder mit dem Stamm zusammenzuführen. Dies klingt einfach, bedeutet aber eine deutliche Umstellung im Arbeitsablauf. Eine andere Lösung als die Arbeit mit Zweigen/Branches hat bisher noch niemand aufgezeigt, um die oben beschriebenen Probleme in den Griff zu bekommen. Gleichzeitig, um bei der Gärtneranalogie zu bleiben, können viele Zweige auch ein ordentliches Dickicht schaffen, das nicht mehr zu durchdringen ist. Die Hauptaufgabe bei der Umstellung auf git lag in unserem Fall somit darin, die Produktivität bei der Arbeit trotz Umstellung hoch zu halten und zu definieren, wie mit git-Branches flexibel gearbeitet wird, ohne dass der Überblick verloren geht.

Wir sind mit dem folgenden, einfachen Branch-Modell gestartet:

  • Jedes Release hat seinen eigenen Haupt-Branch: ucs-VERSION/KUNDENRELEASE_X/master.
  • Jedes Feature zweigt vom Haupt-Branch ab und bekommt einen eigenen Feature-Branch: ucs-VERSION/KUNDENRELEASE_X/TICKETID-FEATURE_Y/master
  • Nach Abschluss der Entwicklung wird das Feature in den Haupt-Branch integriert (merge).
  • Nach erfolgreichem Abschluss der Qualitätssicherung wird der Feature-Branch gelöscht.

Hier die grafische Darstellung mit den zugehörigen git-Befehlen:

git-ucs-branches-releases-commands_en

Das Modell hat bisher einen guten Eindruck hinterlassen. Für den Umstieg wurde mit allen Entwicklern ein Workshop durchgeführt, um die Grundbefehle durchzugehen und das Branch-Modell praktisch auszuprobieren. Außerdem wurde eine Dokumentation erstellt, die die einzelnen Schritte mit Kommandozeilenbefehlen beschreibt. Dies war sehr wichtig, um sicherzustellen, dass die Produktivität durch die Umstellung nicht gefährdet wird. Alle Entwickler haben in der vergangenen Woche erfolgreich Änderungen mit dem neuen Ablauf vorgenommen. Probleme gab es bisher gar keine. Normalerweise knirscht es bei Umstellungen am Anfang immer ordentlich. Davon war hier keine Spur zu sehen und das, obwohl die Branch-Bezeichnungen auch als sichere Passwörter akzeptiert wurden. 🙂 Dies hat mich sehr positiv überrascht und unterstreicht, dass alle an einem Strang gezogen haben! Hier ist ein Ausschnitt aus der aktuellen Entwicklung, gut sind die einzelnen Branches und die Merges zu sehen:git

 

Unser Fazit. Das Drumherum muss auch an git angepasst werden!

Ganz perfekt ist die beschriebene git-Nutzung nicht. Es gibt noch vieles, das wir gerne umsetzen würden und das noch runder laufen könnte. Insbesondere werden im aktuellen Ablauf leider weiterhin die Feature-Branches in den Haupt-Branch integriert, ohne dass die Änderungen jemals vollständig getestet wurden. Damit haben wir die hohe Fehlerrate in den Jenkins-Tests noch nicht im Griff. Unsere Idee ist es, im Jenkins dynamisch einen Test-Job für jeden Branch zu generieren, alle Pakete aus dem Branch automatisiert zu bauen und anschließend die Tests auszuführen. Inzwischen wurde diese Funktionalität nachgerüstet und läuft seit einigen Tagen produktiv. Ich erwarte, dass die Entwicklung von Features damit noch besser abgeschottet werden kann. Dafür heißt es aber erstmal, die bestehenden Fehler in den Jenkins-Tests nahe null zu bringen, um wirklich zu sehen, welche Fehler durch die Entwicklung eines Features entstehen.

Welche Erfahrungen haben Sie mit der Migration zu git gesammelt? Ich freue mich auf Ihr Feedback!

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich

Jan Christoph arbeitet seit Juli 2008 bei Univention. Nachdem er zunächst als Softwareentwickler tätig war, ist er seit 2009 Teil des Professional Services Teams. Hier ist er sowohl in größeren als auch kleineren UCS Projekten involviert, sowie in Trainings und im Wissenstransfer. Seine persönlichen Interessen liegen im Bereich des Projektmanagements nach Scrum, Versionierungskontroll-Systemen, dem vim Texteditor und der Integration von Open Source Softwarekomponenten in Systemen. Derzeit ist Jan Christoph als Product Manager Education für UCS@school tätig.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Kommentare

  1. Hallo Jan Christoph,

    ein super Schritt.
    Mit git.

    Herzlichen Glückwunsch zu der Entscheidung und der erfolgreichen Durchführung.

    Ich liebe vor allem die Möglichkeit, lokal zu arbeiten. Nach Herzenswunsch eigene lokale Branches zu erstellen. Änderungen einzuchecken, zu mergen.
    Und irgendwann kommt dann eben der Push.

    So kann man auch wunderbar offline arbeiten.
    Ich habe mich so sehr daran gewöhnt, dass es mich bisweilen stört, dass einige Dinge wie issues und todos nicht auch offline sind.

    Schönen Gruß
    Cornelius

    Antworten
  2. Jan Christoph Ebersbach

    Hallo Cornelius,

    ja, alles dezentral wäre wirklich super. Dazu gibt’s ja auch ein paar Projekte wie Fossil oder Veracity (discontinued). Mein Eindruck ist, dass es etwas Zeit braucht bis wirklich die Essenz des dezentralen Arbeitens in den Arbeitsablauf übergegangen ist. So wie Du es beschreibst, soll es sein 🙂

    Wir arbeiten hier von Zeit zu Zeit auch mit persönlichen Branches, um bei der Entwicklungs eines Features auszuhelfen. Da zeigt sich wirklich die Einfachheit und Power des Systems.

    Viele Grüße,

    Jan Christoph

    Antworten
  3. Für die Migration von SVN nach git empfehle ich ESR’s reposurgeon. Damit kann man auch multi-project-Repos in einzelne Projekte aufsplitten – auch wenn das früher ein single-project-reop war, völlig verkorkste Repos bereinigen oder generell aufräumen. Ich habe damit schon mehre Projekte erfolgreich migriert. Unter anderen eben auch ein völlig verkorkstes.

    Antworten

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert