Ein wenig über Synergy

Mit Synergy (vormals Continuus) besitzt IBM ein weiteres gefühltes Fossil unter den Versionskontrollsystemen. Zur Erinnerung: Vor ein paar Jahren kaufte IBM mit der Firma Rational auch gleich deren ClearCase SCM mit ein. Beide Systeme können ihre Wurzeln zumindest bis in die 1990er Jahre zurückverfolgen (was ich hier nicht tue, da beide Systeme eine bewegte Vergangenheit haben). Im Moment bin ich gezwungen, mit Synergy zu arbeiten, was mein Leben nicht eben leichter macht; ich vergleiche es hier mit ClearCase, obwohl ich mit letzterem wesentlich mehr Erfahrungen habe.

Wie bei allen anderen serverbasierten SCMs, zu denen ich auch das vielgelobte Subversion zähle, ist auch by Synergy eine wesentliche Schwäche des Systems der Aufwand, der im Vorfeld betrieben werden muß: Bevor ein Projekt aufgesetzt werden kann, muß die Projektstruktur geplant werden. Wer schon einmal die Freude hatte, ein neues Projekt in Subversion oder ClearCase aufzusetzen, weiß, daß hier viele Befindlichkeiten berücksichtigt werden wollen, inklusive der Planung der späteren Nutzung.

Synergy verwirrt hier zusätzlich, da es ein eingebautes Modell für den Lebenszyklus von Software hat. Es gibt hier Projekte und Unterprojekte (die brav mit den IDE-Projekten der Entwickler abgeglichen, aber nicht verwechselt werden wollen), Versionen, Folder, Tasks und Releases. Ein buntes Sammelsorium an Abhängigkeiten erleichtern die Arbeit, sofern man sich an die Vorstellungen eines Lebenszyklus von Synergy hält. Gewarnt seien alle, die sich damit nicht im Vorfeld beschäftigen wollen: Es kann sehr eklig werden, wenn man an diesen Vorstellungen vorbei operieren will oder muß.

Bis zu diesem Punkt ist Synergy ein gewöhnliches SCM mit einem eigenwilligen, man könnte sagen ungewöhnlich unintuitiven Interface. An dieser Stelle empfehle ich allen, die es benutzen wollen, sich mit der abweichenden Semantik von "Update" vertraut zu machen, bevor sie die Arbeit von Tagen verlieren.

Warum also sollte jemand Synergy einsetzen wollen?

Die Antwort liegt im (neuen) Namen "Synergy": Das SCM ist eng mit dem zusätzlichen Produkt "Change" (und anderen Produkten aus dem Haus Telelogic) verwoben. Change requests in diesem Tool sind bis ins SCM transparent, Tasks werden direkt CRs zugeordnet, und jede noch so kleine Quelltextänderung direkt an einen Task. Damit haben die Entscheider theoretisch jederzeit Überblick über den Stand der Arbeiten, ohne den Entwickler fragen zu müssen.

Generell spielt Synergy seine Stärken erst richtig aus, wenn die Software "fertig" ist: CRs können z.B. vom Test entdeckte Fehler sein, aber auch Anforderungen des Kunden. Im Gegensatz zu anderen Systemen lassen sich die dadurch nötigen Aufwände einfacher erfassen, und die Arbeiten bis hinunter zu den einzelnen Entwicklern zuweisen. Die Gefahr, daß hier noch etwas bei der Transition zwischen verschiedenen Systemen verloren geht, ist hier durch die Integration des SCM mit dem Change Management Tool deutlich geringer.

Ein wirklich sehr schönes Feature ist das Zusammenstellen eines Releases auf der Basis von Tasks: Man entscheidet, welche Tasks mitgenommen werden sollen, und kann so einfach problematische Änderungen ausschließen.

Warum würde ich es trotzdem lieber meiden?

Die Illusion totaler Kontrolle ist möglicherweise irreführend. Wie ein Kollege vor kurzem zitierte: Die Wahrheit liegt im Sourcecode. Und die zu extrahieren bedarf es mehr als einer Aufstellung von geänderten Dateien.

Zudem ist das unintuitive Interface (beide Interfaces sind unintuitiv: sowohl das "klassische" Interface, als auch der "Developer Client"; zudem weichen Bezeichnungen für Arbeitsschritte voneinander ab, und einige Arbeiten lassen sich im Developer Client nicht durchführen) Ursache für Frustration und verlorene Arbeit. Eine Einweisung in Synergy ist also unbedingt nötig, besonders wenn Entwickler vorher mit anderen SCMs gearbeitet haben.

Und letztlich kann auch Synergy keine Wunder vollbringen: Abhängigkeiten zwischen Quelltextänderungen in verschiedenen Tasks schlagen sich nicht automatisch in Abhängigkeiten zwischen das Tasks nieder. Damit kann das Zusammenstellen von Tasks für eine Build- oder Lieferversion keine integere Lieferung garantieren, was dieses ansonsten schöne Feature wieder etwas in Frage stellt.

Im Vergleich zwischen ClearCase und Synergy würde ich mich ob der klareren und intuitiveren Versionsverwaltung für ClearCase entscheiden. Die Lizenzkosten für beide Systeme sind mir nicht bekannt; möglicherweise entscheidet in der Praxis dieses Argument. Sobald es aber um Support per Internet-Forum und Bekanntheit bei den Entwicklern geht, verlieren sowohl ClearCase als auch Synergy klar gegen Subversion; kleine Projekte mit einem kurzen Entwicklungszyklus sollten sich eher in diese Richtung orientieren, zumal sowohl bei ClearCase als auch bei Synergy dedizierte Administratoren für die Pflege des SCM notwendig (und dann auch beschäftigt) sind.