Sei kein Depp! GIT oder Subversion? Titelthema. Git oder Subversion

Transkript

1 Titelthema GIT oder Subversion? Sei kein Depp! Kennen Sie Bob? Nein? Bob ist Entwicklungsleiter in einem IT-Unternehmen. Die Entwicklungsabteilung erstellt die Software für die Geschäftsprozesse des Unternehmens und ist somit der inhouse IT-Dienstleister. Leider ist es so, dass der Entwicklungsprozess etwas schleppend verläuft. Das macht sich vor allem an häufig verschobenen und nicht eingehaltenen Releaseterminen bemerkbar. Die Geschäftsführung ist davon nicht sonderlich begeistert und möchte diesen Umstand gerne ändern. Und hiermit beginnt unsere kleine Geschichte... von Thorsten Kamann Neben vielen anderen Gründen die allerdings nicht Teil dieser Geschichte werden sollen wurde das verwendete Versionierungssystem als Problem erkannt. Bisher war dies ein kommerzielles Produkt, das im Laufe der Zeit immer träger und unflexibler wurde. Die Anforderungen an Anpassbarkeit, Flexibilität und Parallelentwicklung sind heute anders als noch vor ein paar Jahren. Mit der Zeit hat sich auch die Denkweise über Open Source geändert. Auch in Bobs Unternehmen. Es wird zuerst nach einem passenden Open-Source-Produkt gesucht. Versionierungssysteme als Open-Source-Produkte zu finden, ist keine besondere Herausforderung. Allein Wikipedia listet bereits acht verfügbare Systeme auf. Bob möchte natürlich nur ein System mit einer weiten Verbreitung und einer großen Community einführen. Herausragend sind dabei Subversion [2] und Git [3]. Der große Unterschied beider Systeme ist der Kernansatz: Subversion ist zentralisiert Git ist dezentral Das bedeutet, dass Subversion auf einem zentralen Server installiert werden muss und jeder Entwickler Zugriff auf diesen Server benötigt, wenn er bestimmte Aktionen, z. B. einen Vergleich verschiedener Sourcecode-Stände, durchführen will. Will man Sourcecode-Änderungen nicht direkt in den zentralen Server committen, weil z. B. die Änderungen noch nicht stabil sind, bietet Subversion keine Lösung an. Bei einem dezentralen System wie Git ist das anders. Jeder Entwickler hat die Historie des 8 eclipse magazin

2 Titelthema Sourcecode-Stands oder Auszüge davon lokal zur Verfügung. Um eine Implementierungsaufgabe zu erledigen, kann er beliebig viele lokale Commits machen und erst den fertigen Stand in einen zentralen Git-Server übertragen (Abb. 1). Git erlaubt es sogar, die vielen einzelnen Commits zu einem oder mehreren großen Commits zusammenzufassen, um die Historie des zentralen Git- Servers nicht unnötig aufzublähen. Der Vorteil dabei ist, dass er seine Arbeit fortwährend versionieren und im Bedarfsfall auf eine ältere Version zurückgehen kann. In Bobs Abteilung wurde bisher sehr spät committet. Das bedeutet ein hohes Risiko, da Änderungen sehr lange ungesichert und unversioniert auf den Workstations der Entwickler verbleiben. Neben den harten Anforderungen (Tagging, Branching, Performance, Usability...) für die ausreichende Unterstützung beider Systeme gibt es auch einige weiche Anforderungen, die in der To-do-Liste in Abbildung 2 zu sehen sind. Das erste To-do ist für Bob erledigt. Er wird evaluieren, ob nun sämtliche weichen Anforderungen mit Git zu erfüllen sind. Explorers ein und bietet an dieser Stelle die meistbenutzten Befehle an (Abb. 3). Darüber hinaus dekoriert er die Dateien anhand des Git-Status (Unversioned, Modified, Added...) mit eigenen Icons. Abb. 1: Arbeiten mit Git Tools für die Workstation Unter einer Workstation versteht Bob sowohl die Arbeitsplatzrechner als auch Laptops. Zu Beginn macht sich Bob Gedanken über die Art und Weise, wie ein Entwickler ein Versionierungssystem verwendet. Dabei berücksichtigt er natürlich auch die verschiedenen Typen von Mitarbeitern, die er in seiner Abteilung hat. Es gibt welche, die können ohne Maus nicht überleben, und wiederum andere, die für jede noch so kleine Funktion einen Shortcut parat haben. Diese gegensätzlichen Typen müssen natürlich bei der Toolauswahl abgeholt werden. Somit ergeben sich drei verschiedene Arbeitsweisen mit einem Versionierungssystem für Bob: Arbeiten auf der Konsole Arbeiten mit dem Windows Explorer Arbeiten direkt in Eclipse Arbeiten auf der Konsole Git ist ursprünglich von Linus Torvald entwickelt worden, um den Linux Kernel weiter zu entwickeln. Somit ist es keine Überraschung, dass sämtliche Funktionen von Git über den Kommandozeilenclient verfügbar sind. Eine ganze Zeit war es nur möglich, Git mit Cygwin zu betreiben. Das war merklich langsamer, da viele Befehle von Git als Shell-Skripte implementiert wurden. Einen Performanceschub brachte dann die Reimplementierung dieser Skripte in C. Es gibt allerdings für Windows eine etwas komfortablere Lösung: MSysGit [4]. MSysGit ist eine native Win32-Anwendung und somit etwas performanter als die Lösung mit Cygwin. Arbeiten mit dem Windows Explorer Mit TortoiseGit [5] gibt es eine ähnliche Unterstützung für Git wie für Subversion mit TortoiseSVN [6]. TortoiseGit klinkt sich in das Kontextmenü des Windows Arbeiten direkt mit Eclipse Für die meisten Entwickler ist es am effektivsten, wenn sie Sourcecode-Änderungen direkt aus Eclipse in Git committen können. Eclipse bietet zudem einen integrierten Diff-Editor, mit dem man gut arbeiten kann. Auf eclipse.org gibt es das EGit-Projekt [7], das eine Integration in Eclipse bietet. EGit will ebenfalls auf den Helios Release Train springen und ist offizieller Teil der nächsten Eclipse-Version. Da eclipse.org den Projekten Git als Versionierungssystem anbietet, ist hinter der Weiterentwicklung dieses Plug-ins auch deutlich Bewegung zu verspüren (Abb. 4). Tools für die Workstations gibt es also im ausreichenden Maß. Natürlich hat Bob diese Tools genauer evaluiert. Alle diese Tools sind schon praxistauglich, auch wenn sie teilweise noch sehr neu sind, z. B. EGit, das erst in Version vorliegt. Integration in die bestehende Infrastruktur Nachdem der zweite Punkt der To-do-Liste abgehakt werden konnte, geht Bob direkt zu Punkt 3 über. Ein neues Versionierungssystem allein bringt nichts. Außerdem werden noch ein Ticketing-System Abb. 2: To-do-Liste der weichen Anforderungen Abb. 3: Erweitertes Kontextmenü des Windows Explorer eclipse magazin

3 Titelthema und eine Continuous Integration benötigt. Es wäre optimal (im Fall der Continuous Integration ein Must Have), wenn beide Systeme mit Git kommunizieren könnten. Bei einem Ticketing-System könnten die Commits zu einem Ticket angezeigt und ein Changelog für jedes Ticket erzeugt werden. Das Continuous-Integration-System benötigt auch Zugriff auf das Versionierungssystem, da dieses System in regelmäßigen Abständen auf Veränderungen abgefragt wird. Bei Änderungen wird dann ein Build ausgeführt. Bob hat als Ticketing-System Atlassian Jira [10] und als Continuous Integration Hudson [11] ausgewählt. Jira kann konfigurierte Git Repositories auf Änderungen prüfen. Dabei wird ein Changelog von Git abgefragt und die Commit Messages nach Issue Keys (in Jira heißen die Tickets Issues) durchsucht. Findet sich einer, wird diese Änderung dem Issue zugeordnet. Auf diese Weise kann man zu jeder Zeit alle Sourcecode-Änderungen nachvollziehen, die für die Bearbeitung eines Issues notwendig waren. Hudson als Continuous Integration muss natürlich direkt auf ein Git Repository zugreifen können, um auf Sourcecode-Änderungen mit einem neuen Build reagieren zu können. Zusätzliche Aufgaben sind das Taggen und Branchen, was ebenfalls über Hudson konfiguriert werden kann. Da Hudson mit Jira eine bidirektionale Kommunikation pflegen kann (Hudson spricht mit Jira und vice versa), kennt jedes System den Status des anderen. Als zugrunde liegendes System dient Git, das den Sourcecode verwaltet. Git selbst kennt den Status einer Source-Datei nicht. Um diesen zu ermitteln, benötigt man das Ticketsystem, das den Status anzeigt, z. B. Open, Resolved, Closed. Hudson gibt seinen Status über mehrere Sourcen an. Er versucht regelmäßig, Änderungen an einer oder mehreren Source-Dateien miteinander zu integrieren. Da er auch in der Lage ist, Tests auszuführen, kann man aus dem Hudson-Status lesen, wie stabil und qualitativ hochwertig ein Sourcecode-Stand ist. Eine solche Infrastruktur finden Sie unter [12] detaillierter beschrieben. Abb. 4: Git-Integration in Eclipse Abb. 5: Der zentralisierte Ansatz Installation von Git als Server Git auf den Workstations ist eine lokale Angelegenheit. Zwar kann dieses Git Repository über eine Netzwerkfreigabe anderen Entwicklern zur Verfügung gestellt werden, aber bei verteilten Teams, die nicht mehr am gleichen Ort sitzen, ist das mit sehr vielen Problemen behaftet, z. B. Firewall-Regeln und instabile VPNs. Die bessere Lösung ist die Verbindung des Apache Webservers mit aktiviertem Webdav und Git auf einem Server [9]. Vom Konzept ist dies das Gleiche wie eine Subversion-Installation. Geeignete Commit-Strategie auswählen Das ist wohl der interessanteste Punkt auf Bobs Todo-Liste. Da bei Git der zentrale Server keine so wesentliche Rolle spielt wie bei Subversion, muss man sich im Vorfeld darüber im Klaren sein, wie die Änderungen der einzelnen Entwickler zusammengeführt werden können. Bis zu einem gewissen Punkt kann jeder für sich arbeiten. Git erlaubt es, Änderungen in das lokale Repository zu committen. Ab einem bestimmten Zeitpunkt nämlich dann, wenn z. B. die Implementierung abgeschlossen ist, sollen auch andere Entwickler in den Genuss der Änderungen kommen. Der zentralisierte Ansatz Das ist der Ansatz, der von herkömmlichen Versionierungssystemen bekannt ist (Abb. 5). Jeder Entwickler committet seine 10 eclipse magazin

4 Titelthema Änderung in ein zentrales Repository. Bob weiß natürlich, dass dieser Ansatz die höchste Akzeptanz bei den Entwicklern hätte. Der große Vorteil eines solchen Vorgehens ist, dass der Aufwand des Zusammenführens verschiedener Source-Stände relativ gering ist, wenn alle Entwickler in den gleichen Server und zeitnah committen. Diese Strategie ist von Subversion bekannt und erprobt. Die Probleme kommen spätestens dann, wenn fehlerhafte Änderungen den Build-Prozess lahmlegen und manuelle Eingriffe nötig sind. Integration Manager Auch in diesem Szenario gibt es einen zentralen Server. Im Gegensatz zum vorherigen Ansatz gibt es hier zusätzlich den Integration Manager. Dieser hat als einziger die Berechtigung, in das zentrale Repository zu committen. Die Entwickler klonen das zentrale, committen aber in ein eigenes privates Repository. Um den Verwaltungsaufwand zu minimieren, benutzen mehrere Entwickler dasselbe Repository. Eine Zuordnung kann pro Team erfolgen. Zu einem bestimmten Zeitpunkt bittet das Abb. 6: Integration Manager Abb. 7: Leutnant und Diktator eclipse magazin

5 Titelthema Team den Integration Manager die Änderungen in das zentrale Repository zu integrieren (git pull). Das zentrale Repository ist meistens in einem sauberen Stand, da die Änderungen bereits durch einen Testprozess in den Team-Repositories verifiziert wurden (Abb. 6). Leutnant und Diktator Einen Schritt weiter geht diese Strategie. Hier kann der Integration Manager nicht direkt in das zentrale Repository committen. Er bittet den Diktator, dies für ihn zu tun. Die Rolle Integration Manager nennt sich in diesem Szenario Leutnant. Jedes Team stellt dabei so einen Leutnant. Dieses Szenario bietet die höchste Sicherheit, da der Diktator vor dem Commit ins zentrale Repository noch Integrationstests durchführen kann. Somit ist es fast ausgeschlossen, dass der geänderte Sourcecode den Build behindern kann. Man muss allerdings anmerken, dass dieses Vorgehen recht langsam ist, da es einige Zeit dauert, bis Änderungen im zentralen Repository ankommen. Der Vorteil ist die hohe Sicherheit, denn bis ins zentrale Repository gibt es bereits drei Teststufen: Test beim Commit ins Repository des Teams Tests beim git pull des Leutnants Integrationstests vor dem Commit ins zentrale Repository Diese Strategie wird oft in großen Projekten angewandt, so auch bei der Entwicklung des Linux Kernels. Etwas beschleunigen kann man diesen Prozess, indem man den Leutnant automatisiert. Das könnte eine Aufgabe des Continuous-Integration-Systems sein. Nur muss im Hintergrund auch immer eine reale Person verfügbar sein, die im Problemfall eingreifen kann (Abb. 7). Bob hat nun die Qual der Wahl. Alle drei Verfahren haben ihre Vor- und Nachteile. Entscheidet er sich für das einfache zentralisierte Verfahren, nutzt er die Möglichkeiten von Git nicht voll aus nämlich den Pull aus verschiedenen Repositories. Allerdings ist dieses Verfahren allen Entwicklern geläufig. Es wären also nicht allzu viele Schulungen nötig. Die Integration-Manager-Variante hat ihren Reiz. Die Teams können ziemlich autark arbeiten. Sie besitzen eine eigene Continuous Integration, und falls ein Build nicht mehr läuft, ist es nicht so dramatisch, da es teamintern ist und nicht die ganze Entwicklungsabteilung betrifft. Die dritte Variante mit den Leutnants und dem Diktator ist wohl doch eher für große Projekte geeignet und kommt für Bob nicht in Frage. Die Entscheidung fällt zugunsten der Integrationsmanagerstrategie, da sie eine höhere Sicherheit für die Integrität des Repositories bei gleichzeitig hoher Flexibilität in der Anpassung an die Gegebenheiten bietet, die in Bobs Unternehmen herrschen. Anbindung von Git an Subversion Bob hat noch ein Problem. Es gibt noch eine Abteilung, die vor einigen Jahren ausgelagert wurde. Sie ist mit ihrer Infrastruktur schon deutlich weiter, denn dort wird als Versionierungssystem Subversion verwendet. Nun wäre es schön, wenn beide Systeme nahtlos miteinander verknüpft werden könnten. Auch das kann Git. Mit Git-SVN kann als Remote Repository ein Subversion Repository verwendet werden. Man kann ein Subversion Repository (oder einen Teil davon) klonen und hat wie gewohnt die komplette Historie zur Verfügung. Bei großen Repositories bietet es sich an, eine Revision mitzugeben, von der an sämtliche Commits geklont werden. Der Entwickler kann ganz normal mit Git arbeiten. Erst wenn etwas in das Subversion Repository committet werden soll, muss ein entsprechender Befehl abgesetzt werden (git-svn dcommit). Man hat jederzeit die Möglichkeit, verschiedene Sourcecode-Stände zu mergen und seine lokale Arbeitskopie mit der Version in Subversion zu vergleichen. Schluss Bob konnte seine To-do-Liste komplett abhaken. Für alle geforderten Features gab es etwas für Git. Natürlich bedeutet eine Umstellung der Versionierung viel Arbeit und birgt hohe Risiken. Aber es bietet auch gleichzeitig die Chance, Prozesse zu verbessern, da es wie hier mit Git neue Konzepte gibt, die in die täglichen Arbeitsabläufe integriert werden müssen. Bob auf jeden Fall ist guten Mutes, die Umstellung durchführen zu können und dadurch einige der Probleme in seiner Abteilung beheben zu können. Thorsten Kamann ist als Projektmanager, Softwarearchitekt und Coach bei itemis tätig. Seine Schwerpunkte sind Scrum, webbasierte Technologien, MDSD, leichtgewichtige und flexible Architekturen, Open Source und Infrastrukturen für agile Entwicklungsteams. Darüber hinaus schreibt er Bücher, veröffentlicht regelmäßig Artikel in Fachmagazinen und hält Vorträge auf Fachkonferenzen zu obigen Themen. Bob D. Veloper ist bei einem Unternehmen als Entwicklungsleiter angestellt. Seine Schwerpunkte sind neben seinen Teamleitungsfunktionen Qualitätsmanagement und Evaluierung von Software und Tools. Links & Literatur [1] [2 [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] 12 eclipse magazin

6 Jetzt anmelden und attraktive Frühbucher- Rabatte sichern! Europas Nr.-1-Konferenz für Enterprise-Technologien & Strategien Mai 2011 Rheingoldhalle, Mainz Java Enterprise-Architektur Eclipse Web OSGi SOA & BPM Groovy, Scala & Co. Agile Methoden & Toolchains Android 2-IN-1-KONFERENZPAKET! JAX buchen & das Programm der Business Technology Days gratis nutzen! Media-Sponsoren: Präsentiert von: Veranstalter: