Am 20.3.2012 halte ich in Frankfurt auf dem Atlassian Unite einen Talk: “DVCS in the Enterprise: How Atlassian made the switch”. Der Vortrag handelt von unseren Migrationserfahrungen von Subversion zu Mercurial und Git.
Jeder der noch Subversion zur Versionskontrolle einsetzt wird heutzutage schief angeschaut und gefragt: ”Hast du denn noch nicht von Git oder Mercurial gehört. Das benutzt man doch heutzutage”. Ich persönlich kenne auch kein Team, dass bei einem neuen Projekt noch SVN oder sogar CVS einsetzt (Wenn es nicht schon eine SVN Server gibt, den man benutzen muss). Die Argumente der Verteidiger von zentralisierten Versionssystemen sind meist:
- wir entwickeln doch keinen Linuxkernel, bei uns sind alle Codeänderungen wichtig und müssen im Master übernommen werden
- wir arbeiten eh alle mit Netzwerkanschluss am Code. Wir brauchen kein offlinefähiges Repository
- bei uns arbeiten alle auf dem Trunk; wir brauchen die ganzen Merging-Vorteile gar nicht
DVCS – viele Vorteile
Verteilte Versionskontrollsysteme bieten die gleichen Features wie ihre zentralisierten Kollegen und darüber hinaus noch mehr:
- vollständige lokale Historie des Quellcodes (viel schneller)
- wirklich jeder Commit und Comitter wird in der Historie festgehalten – nicht nur derjenige der den Merge durchgeführt hat
- einfaches und sehr mächtiges Mergen (keine Angst vor langen Branches)
- neue Möglichkeiten für Continuous Integration / Delivery mit Code-Staging
- Die Toolunterstützung ist teilweise besser
- es geht viel schneller den Code zu mergen oder einen Branch/Fork zu erstellen
Angst vor dem Wechsel?
Die Vorteile liegen auf der Hand. Es liegt meiner Meinung nach eher an der Furcht vor einem Wechsel aus zwei Gründen:
- Angst, dass das Team das Konzept hinter DVCS nicht versteht und somit viel Zeit beim Lernprozess verliert.
- Angst vor der Migration. Der Wechsel auf ein neues System an einer so zentralen Stelle kann den Entwicklungsbetrieb für mehrere Tage lahmlegen, oder es kann gar nicht alles vollständig migriert werden.
Unsere Erfahrungen
Natürlich hatten wir bei Atlassian auch bedenken vor einem Wechsel auf ein konzeptionell neues Versionskontrollsystem. Wir haben es allerdings geschafft ohne Downtime für unsere Entwicklung den Wechsel durchzuführen. Auch haben wir vorher im Team den Wechsel im einzelnen besprochen und auf unseren Wiki-Seiten dokumentiert, so dass jeder am Ende keine Bedenken mehr vor dem Wechsel gehabt hat.
Wir haben auch erst einmal nichts an unserer Art, wie wir Code einchecken, Branches erstellen und mergen, geändert. Es hat sich allerdings schnell herausgestellt, das die Möglichkeiten, die einem Git und Mercurial bieten, die tägliche Arbeit beschleunigen und vereinfachen können… Aber: Die ersten Wochen haben wir genauso wie vorher gearbeitet (bis auf die Tatsache, dass wir nicht mehr subclipse oder ähnliches benutzen haben).
Die Migration wurde bei uns sorgfältig geplant. Wir haben zeitweise den in Subversion eingecheckten Code automatisiert in Mercurial importiert und Builds davon erstellt. Das ganze hat uns die Sicherheit gegeben, dass der Code in einem DVCS genauso gut – wenn nicht sogar besser – aufgehoben ist als in SVN.
Mein Kollege Stefan Saasen hat einen sehr detaillierten Blogeintrag für Praktiker darüber geschrieben, wie das Confluence Team zu Git gewechselt hat.
Noch mehr Erfahrungen?
Ich halte einen Vortag über genau dieses Thema auf der in Frankfurt stattfindenden Atlassian Konferenz (Atlassian Unite). Dort werde ich noch einmal genau erklären was uns der Wechsel gebracht hat, wie wir unsere Workflows ausgewählt haben und wie verschiedene Teams zu DVCS migriert sind. Außerdem finden auf dem Atlassian Unite noch weitere Talks zu JIRA, Confluence, agiler Softwareentwicklung und vieles mehr statt. Das ganze Programm gibt es hier.
