Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Atlassian Stash - Erste Schritte

Atlassian StashVor eini­gen Wochen kam in der Atlassian-Abteilung bei Communardo, aus nahe lie­gen­den Gründen ;), die Idee auf, Atlassian Stash aus­zu­pro­bie­ren. Erste Eindrücke zum Tool hat mein Kollege Niels schon vor eini­ger Zeit gepos­tet. Dieser Beitrag bezog sich vor allem auf das Tool und seine Features und lässt damit einen wesent­li­chen Aspekt aus: Man fängt halt nicht ein­fach mal an Stash zu nut­zen. Vor allem, wenn man wie wir bis dato aus­schließ­lich mit zen­tra­ler Versionsverwaltung gear­bei­tet hat, der Zweck von Stash aber darin besteht Verwaltung und Arbeit mit Git, einem System zur dezen­tra­len Versionsverwaltung (DVCS), zu erleich­tern.
In die­sem Beitrag soll es also darum gehen, wel­chen Einfluss die Verwendung von Stash auf unsere Arbeit hatte.

 

Jetzt also Git

Wir hat­ten uns ent­schie­den Stash (und Git) zunächst an neuen klei­nen Projekten aus­zu­pro­bie­ren. Das erste Team bestand aus 3 Personen und sollte ein klei­nes Plugin zur Anpassung von Confluence schrei­ben. Unsere Erfahrungen mit Git beschränk­ten sich auf "Git? Ja klar, benutze ich bei mei­nem Toy-Projekt auf Bitbucket – für mich allein." Da es uns zunächst vor allem um die Evaluation von Stash ging, haben wir ver­sucht den Faktor Git wei­test­ge­hend zu igno­rie­ren. Deshalb sollte Git ein­fach wie ein zen­tra­les Versionsverwaltungstool ver­wen­det wer­den; es gibt einen Master und alle "comit­ten" auf die­sen. Und um die umständ­li­che Konsolenakrobatik zu umge­hen, gibt es ja inzwi­schen genü­gend gra­fi­sche Clients und Plugins für diverse IDEs. Dachten wir. Allerdings muss­ten wir ziem­lich schnell fest­stel­len, das Git sich doch ein gan­zes Stück anders ver­hält als bei­spiels­weise Subversion.
Zum Glück gab es bei Communardo einen Kollegen der sich bes­tens mit Git aus­kennt und uns eine super Einführung gege­ben hat. Nochmal vie­len Dank Jan!
Hier hät­ten wir also eine wich­tige Lesson Learnt: DVCS führt sich nicht von selbst ein. Und dabei haben wir durch unsere Wahl der Projekte einige kri­ti­sche Punkte, wie zum Beispiel den Umgang mit Code in den bestehen­den Repositories der abzu­lö­sen­den Versionsverwaltung, noch gar nicht betrach­tet. Eine Umstellung auf DVCS sollte also defi­ni­tiv geplant statt­fin­den. Das betrifft zum einen die Migration bestehen­der Daten. Aber auch die Umstellung auf die neuen Konzepte und das unbe­kannte Vokabular soll­ten berück­sich­tigt wer­den. Dafür bie­tet es sich an min­des­tens einen erfah­re­nen Mitarbeiter zu haben, der die Einführung von DVCS beglei­tet und an den man sich bei Problemen im Umgang mit dem neuen System wen­den kann.

 

Stash

Nachdem wir Git also bezwun­gen (oder zumin­dest gezähmt) hat­ten, konn­ten wir uns Stash zuwen­den. Die Features kön­nen im bereits erwähn­ten Artikel von Niels nach­ge­le­sen wer­den. Mit der Funktion Repositories in Projekten zu grup­pie­ren und der Möglichkeit ein neues Repository schnell über die Weboberfläche anzu­le­gen, hat sich unser Ansatz zur Strukturierung von Repositories geän­dert: Haben wir frü­her häu­fig meh­rere Projekte in einem Repository ver­wal­tet (es gab also meh­rere Hauptentwicklungslinien pro Repository) gehen wir nun dazu über ein neues Repository pro Projekt anzu­le­gen.

Diskussion am Code

Erklärtes Lieblingsfeature der Entwickler sind die mit Release 1.3 ein­ge­führ­ten Pull Requests. Diese unter­stüt­zen die Integration von Code-Reviews in den Entwicklungsprozess. Die Umsetzung eines Features erfolgt dazu in sog. Feature Branches. Bevor diese in die Hauptentwicklungslinie (den Master Branch) über­nom­men (gemergt) wer­den wird ein Pull Request erstellt. Über die­sen las­sen sich schnell die Abweichungen vom Master Branch fest­stel­len und es kann direkt über die Weboberfläche am Code dis­ku­tiert wer­den. Der Workflow ist dabei recht intui­tiv gestal­tet und passt sich sehr gut in den Entwicklungsprozess ein. Möchte man die­ses Vorgehen erzwin­gen, kann man die mit Release 2.0 ein­ge­führ­ten Branch-Permissions ver­wen­den. Damit kön­nen die Berechtigungen für den Master Branch so ein­ge­schränkt wer­den, dass z.B. nur Lead-Entwickler auf die­sen comit­ten kön­nen und somit immer min­des­tens ein erfah­re­ner Entwickler an einem Review betei­ligt ist.

 

Wie weiter

Ich bin gespannt wie sich zum einen der DVCS-Ansatz und zum ande­ren damit auch das Produkt Stash wei­ter­ent­wi­ckeln. Sollte sich DVCS bei uns durch­set­zen, steht als nächs­ter Task die Umstellung unse­rer alten Subversion-Repositories auf Git (oder Mercurial, oder …) an. Erste Versuche haben gezeigt, dass die dazu nötige Restrukturierung unse­rer alten mono­li­thi­schen Repositories und die Übernahme aller alten Revisions recht zeit­auf­wän­dig sein dürf­ten, da die Tool-Unterstützung hier (noch?) sehr rudi­men­tär ist. Immerhin gibt es hier im Web schon eini­ges an doku­men­tier­ten Erfahrungen, so hat z.B. Jonathon Creenaune von Atlassian den Umstieg von SVN auf Git in einer Artikelserie beschrie­ben.

Natürlich sind wir immer an den Erfahrungen ande­rer Nutzer inter­es­siert. Wenn also jemand Tipps oder Feedback hat, wür­den wir uns über einen ent­spre­chen­den Kommentar sehr freuen.

 

 

Unsere Leistung für Sie

Platinum Expert LogoCommunardo ist Atlassian Platinum Expert und berät Sie gern zu Fragen rund um die Atlassian Produkte. Zudem kön­nen Sie über uns direkt Lizenzen erwer­ben.

Related Posts

Pin It on Pinterest