Source Code Verwaltung modernisieren - ein Erfahrungsbericht

Teil 1: Warum wir uns zu diesem Schritt entschlossen haben

Hintergrund:
Sicherheitskritische Embedded Systeme setzen immer eine Real-time Umgebung voraus, damit die Anwendungen auf einem Microcontroller lauffähig sind. Anwender von IBM Rhapsody nutzen dafür in der Regel das Real-time Execution Framework für C oder CPP (RXF) von SodiusWillert, mit den Ergänzungen für sicherheitskritische Embedded Systeme, dem RXF-Cert. Da das RXF-Cert zum Bestandteil des sicherheitskritischen Systems unserer Kunden wird, stehen diese regelmäßig vor der Aufgabe, das RXF-Cert im Kontext ihrer eigenen Software entsprechend den einschlägigen Regularien zertifizieren zu lassen. Um den Anforderungen einer solchen Zertifizierung standzuhalten muss das RXF-Cert bestimmte Auflagen erfüllen. Sollte eigentlich eine machbare Aufgabe sein. Ist es auch, erforderte aber regelmäßig großen manuellen Aufwand, da die Anforderungen, Artefakte und Source-Dateien aus historischen Gründen über verschiedene Versionskontrollsysteme verteilt waren. Das kommt Ihnen bekannt vor? Hier erfahren Sie, wie wir das Problem in den Griff bekommen haben.

Ziele und Motivation
Ohne zuverlässig funktionierende Traceability über Toolgrenzen hinweg wird der Nachweis, wie sicherheitskritische Anforderungen durch das entstandene System erfüllt werden, zu einem mühsamen Puzzle. In unserer seinerzeit genutzten Umgebung musste die Implementierungskette von der Anforderung über Design und Implementierung jeweils manuell zusammengestellt werden, um dem Zertifizierungsgremium den lückenlosen Nachweis vorlegen zu können. Die Speicherorte waren in unserer Umgebung heterogen: ein Teil der Artefakte (Anforderungen, einige Modellelemente) lagen in IBM Engineering Workflow Management (IBM EWM) und waren daher individuell über OSLC Links adressierbar. Der Rest lag in Apache Subversion (SVN Repositories) verteilt und war daher nur auf Dateiebene adressierbar. Jede Zertifizierung geriet zu einer Fleißaufgabe, um die erforderlichen Nachweise zu erstellen.

… und dann war da noch
Neben dem wichtigsten Ziel der automatisierten Traceability-Nachweise gab es weitere Punkte, die regelmäßig zu “hick-ups” in unseren Entwicklungsprozessen führten:

• Parallele Bearbeitung von Modulen, die in SVN verwaltet wurden, durch mehrere Mitglieder im Team war nicht möglich.
• Module in SVN können nicht getestet werden, bevor sie in die Continuous Integration (CI) Umgebung eingecheckt und dort im Kontext getestet werden. Andere Teammitglieder arbeiten mit den potenziell fehlerhaften Modulen weiter, was regelmäßig zu Komplikationen bei der Beseitigung des ursprünglichen Fehlers inklusive aller möglichen Folgefehler führte.
• Wenn Fehler in einer ausgelieferten älteren Version auftraten, konnte diese Version nur mit großem Aufwand reproduziert werden, da die nötigen Baselines über mehrere Config Management Systeme verteilt waren.
• Unterschiedliche Streams werden in SVN nur rudimentär unterstützt. Das dafür vorgesehene Konzept der “branches” war für uns in der Praxis nicht sinnvoll nutzbar, sodass wir in SVN immer nur eine einzige freigegebene Version hatten. 

In a perfect world …
Nachdem einer systematischen Analyse der Ausgangssituation und der resultierenden Issues definierten wir, welche Eigenschaften unsere Zielumgebung mitbringen muss, um die zertifizierungsrelevanten Module RXF_C und RXF_CPP in Zukunft effizienter entwickeln und dokumentieren zu können:

• Es soll ein einziges SCM System für alle Daten genutzt werden, in dem durchgängige Verlinkung auf Artefakt-Ebene möglich ist. 
• Es muss möglich sein, in unterschiedlichen Streams parallel zu entwickeln und zu testen mit kontrollierter Veröffentlichung nach Test.
• Die Unterschiedliche Produktversionen mit unterschiedlichen Release-Zyklen - in unserem Fall RXF_C und RXF_CPP - müssen unabhängig voneinander verwaltet werden können.

Wir haben uns ausführlich mit dem Vergleich der beiden Tools SVN und EWM befasst und unsere Sicht in dieser Tabelle dargestellt:

Unser Fazit
Unsere Wahl fiel auf das Source Control Management (SCM) System von IBM EWM, da dieses Tool alle unsere Anforderungen abdeckt, und wir die Traceability Reports dank der Unterstützung von OSLC-Links in allen benötigten Perspektiven automatisch generieren können. Zudem können wir in verschiedenen Streams parallel arbeiten und ältere Versionen problemlos reproduzieren.

Ausblick
In den folgenden Artikeln dieser Serie berichten wir darüber, wie wir die konkrete Migration von Apache SVN nach IBM EWM SCM durchgeführt haben und teilen unsere Erfahrungen und was wir daraus gelernt haben.