In der ersten Folge dieser Artikelserie haben wir darüber berichtet, warum wir uns dazu entschlossen haben, unsere Source Code Verwaltung von Subversion nach IBM Engineering Workflow Management zu migrieren, und was wir damit erreichen wollten. Wesentliche Gründe waren die Reduzierung des Aufwandes für den Nachweis sicherheitskritischer Eigenschaften bei unserem Produkt RXF-Cert. Zudem wollten wir für RXF und RXF-Cert eine durchgehende Traceability herstellen über Toolgrenzen, Projekte und Versionen hinweg. Falls Sie noch einmal nachlesen möchten, den ganzen Artikel finden Sie hier.
Im zweiten Teil berichteten wir über die Planung und Durchführung der Migration. Hier finden Sie Teil 2 dieser Artikelserie.
Dank sorgfältiger Planung konnten wir die SVN Repositories vollständig in unsere IBM EWM Umgebung migrieren. Abbildung 1 zeigt, wie wir die gemeinsamen und geteilten Module organisiert und verknüpft haben. In IBM DOORS Next haben wir je einen variantenspezifischen Stream (“Variant 1”, “Variant 2”), sowie zwei Streams, die gemeinsam von beiden Varianten genutzt werden.
In der Configuration und Change Management (CCM) Umgebung sind die Streams für jede Variante mit ihren spezifischen und geteilten Modulen definiert. Aus diesen Streams werden die Workspaces der Entwickler abgeleitet, die an der Implementierung neuer Features, Updates oder Beseitigung von Fehlern arbeiten, und dann zu gegebener Zeit ihre Ergebnisse wieder in den Stream zu speichern.
Alle relevanten Requirement Streams einer Variante aus IBM DOORS Next und der Stream der Variante aus EWM (CCM) sind in einer Global Configuration zusammen gefasst (dargestellt in der blauen Ebene in Abbildung 1).
Abbildung 2 zeigt schematisch, wie die spezifischen und die gemeinsamen Komponenten zum fertigen Produkt zusammengeführt werden. Die spezifischen Komponenten für das Produkt RXF_CPP sind RXF_Variant1, Test_Variant1, und Only_Variant1 (in der Abbildung grün dargestellt), die mit den gemeinsamen Komponenten Shared und DevEnvironment zum RXF_CPP Development Stream gebündelt werden. Für den RXF_C Development Stream werden die gemeinsamen Komponenten Shared und DevEnvironment ergänzt mit den spezifischen Komponenten RXF_Variant2 und Test_Variant2.
Die Struktur in den Sandboxes für Variante 1 (RXF_CPP) und Variante 2 (RXF_C) ist ebenfalls in Abbildung 2 dargestellt.
Eine wesentliche Motivation für den Umstieg von SVN nach IBM EWM war die Aussicht, die Umsetzung von Anforderungen über den ganzen Entwicklungsprozess einschließlich Test besser und eindeutig verfolgen zu können, und zwar in beide Richtungen. Dank der umfassenden Traceability Funktionen in der EWM Umgebung profitiert das gesamte Team von der Umstellung. Die Zusammenarbeit der Teams gestaltet sich einfacher und besser dank der Nutzung der Global Configurations Funktionen, welche es ermöglichen, Varianten mit gemeinsamen und spezifischen Komponenten ohne Duplizierung von Elementen und manuelle Synchronisation zu pflegen. Die Wiederverwendung von Komponenten wird dadurch deutlich vereinfacht.
Auch wenn die Planung und die Durchführung der Migration nicht trivial waren und sorgsam vorbereitet werden musste, hat sich der Aufwand für unsere Entwicklungsteams definitiv gelohnt.
Es klingt wie eine Binsenweisheit, aber die wichtigste Voraussetzung für das Gelingen einer solchen Migration ist die frühzeitige und kontinuierliche Einbeziehung der Teams, die in der neuen Umgebung arbeiten sollen. So lässt sich eine latent oder offen ablehnende Haltung leichter vermeiden, und aus den Teams gibt es die notwendigen Anregungen aus der Praxis, die für die Planung und Durchführung der Migration eine wichtige Rolle spielen.
Außerdem empfiehlt es sich, die Migration in behutsamen Schritten anzugehen, um einen kompletten Stillstand laufender Projekte zu vermeiden. So kann immer wieder feinjustiert und nachgesteuert werden, falls sich bei kleinen Migrationsschritten herausstellt, dass Annahmen vielleicht nicht 100%ig korrekt waren, oder nicht bedachte Seiteneffekte vermieden werden sollten. Für den Erfolg eines solchen Projektes entscheidend ist auch die Bewahrung eines gewissen Grades an Flexibilität, um auf unerwartete Ereignisse zeitnah reagieren zu können.
Für unsere Entwicklungsteams war die Migration von Subversion nach IBM EWM definitiv der richtige Schritt, um unsere Projekte zukünftig effizienter durchführen zu können dank besserer Traceability und Zusammenarbeit im Team.