BLOGS
Codebeamer Streams: Was sie sind und wann Sie sie benötigen
Ein einzelnes Produkt in einer einzigen Version zu verwalten, ist vergleichsweise einfach. Mehrere Varianten desselben Produkts zu steuern – jede in einer anderen Entwicklungsphase, mit eigenen Anforderungen, Testfällen und Risiken – ist der Punkt, an dem viele ALM-Setups an ihre Grenzen stoßen. Codebeamer Streams wurden genau für diese Herausforderung eingeführt. Dieser Artikel erklärt, was Streams sind, wie sie funktionieren und wann ihr Einsatz für Ihr Team sinnvoll ist.
Das Problem, das Streams lösen sollen
Stellen Sie sich vor, Sie entwickeln ein eingebettetes Steuerungssystem für einen Automobilzulieferer. Es gibt eine produktionsreife Version, die für bestehende Kunden gewartet wird, eine neue Plattformversion in aktiver Entwicklung und eine frühe regionale Variante, die für einen anderen Markt vorbereitet wird. Jede dieser Konfigurationen hat eigene Anforderungsdokumente, Testspezifikationen und Risikoanalysen – gleichzeitig teilen sie aber eine große Menge gemeinsamer Artefakte, die über alle drei Varianten hinweg konsistent bleiben müssen.
Ohne einen geeigneten Mechanismus greifen Teams häufig auf das Kopieren von Projekten, das Duplizieren von Trackern oder parallele Arbeitsstände zurück, die sich mit der Zeit auseinanderentwickeln. Nachzuvollziehen, welche Version einer Anforderung für welches Produkt gilt, wird dann zu einer manuellen Koordinationsaufgabe. In regulierten Branchen führt genau diese Unschärfe schnell zu erheblichen Compliance-Risiken.
Codebeamer Streams begegnen diesem Problem, indem sie Teams eine strukturierte Möglichkeit bieten, mehrere Releases und Varianten innerhalb einer gemeinsamen Umgebung parallel zu entwickeln und zu verwalten – ohne Daten unnötig zu duplizieren.
PRAXISBEISPIEL: Ein Automobilzulieferer, der Codebeamer einsetzt, verwaltet drei aktive Konfigurationen desselben Produkts: ein produktives Release in Wartung, eine Next-Generation-Plattform in Entwicklung und eine frühe Variante für einen neuen Markt. Ohne Streams müssten Anforderungen, Testfälle und Risikoartefakte entweder in vollständige Projektkopien übertragen oder manuell zwischen den Konfigurationen abgestimmt werden. In beiden Fällen wird es schwierig, einem Auditor eindeutig zu zeigen, welche Version einer Anforderung für welches Produkt gilt.
Was ein Stream eigentlich ist
Ein Stream in Codebeamer ist eine projektübergreifende Konfigurationsebene. Er wählt eine Gruppe von Projekten aus und legt innerhalb dieser Projekte fest, welche Version jedes einzelnen Items sichtbar und aktiv ist. Wenn Sie in einem Stream arbeiten, sehen Sie den Produktstand, der durch diesen Stream definiert ist – nicht als Kopie der Daten, sondern als kontrollierte Sicht auf dieselben Daten.
Jede Codebeamer-Instanz verfügt über einen vordefinierten Stream, den sogenannten Initial Stream. Er enthält alle Projekte und alle Versionen sämtlicher Items. Der Initial Stream bildet die Ausgangsbasis, von der weitere Streams abgeleitet werden. Wenn Sie einen neuen Stream erstellen, definieren Sie im Grunde eine Sichtweise, durch die eine bestimmte Produktkonfiguration sichtbar und bearbeitbar wird.
Das ist wichtig, weil Änderungen in einem Stream nicht automatisch Auswirkungen auf andere Streams haben. Eine Anforderung, die im Stream für ein Wartungsrelease aktualisiert wird, bleibt unabhängig von derselben Anforderung im Stream für die Plattformentwicklung – bis Änderungen bewusst zusammengeführt werden.
Wenn Sie bereits mit Working Sets aus früheren Codebeamer-Versionen vertraut sind: Streams sind deren direkter Nachfolger. Die Grundlogik ist ähnlich, allerdings arbeiten Streams projektübergreifend und kommen ohne Datenduplikation aus. Dadurch sind sie deutlich besser für größere und komplexere Umgebungen skalierbar.
Branched und Shared Trackers
Nicht jeder Tracker innerhalb eines Streams muss sich gleich verhalten. Codebeamer unterscheidet hier zwischen zwei Typen.
Branched Trackers
Branched Trackers verwalten unabhängige Versionen ihrer Items pro Stream. Eine Anforderung in einem Stream kann sich also anders weiterentwickeln als dieselbe Anforderung in einem anderen Stream. Dieses Verhalten ist sinnvoll für Artefakte, bei denen eine bewusste Abweichung erwartet wird. Requirements, Test Cases, Test Sets und Risk Items sind daher standardmäßig branched – aus gutem Grund.
Shared Trackers
Shared Trackers enthalten Items, deren Inhalte in allen Streams identisch sind, in denen sie enthalten sind. Wird ein Item in einem Shared Tracker geändert, ist diese Änderung überall sichtbar. Dieses Verhalten eignet sich für Artefakte, die als gemeinsame Referenz für eine gesamte Produktfamilie dienen – zum Beispiel Plattformkonfigurationen oder gemeinsame Komponenten.
Die richtige Entscheidung zwischen Branched und Shared Trackers zu Beginn eines Projekts ist eine der wichtigsten Konfigurationsentscheidungen für Ihr Team. Sie bestimmt, wie unabhängig die einzelnen Streams voneinander arbeiten können und wie viel Abstimmung erforderlich ist, wenn Änderungen zwischen Streams übertragen werden sollen.
Wann Streams sinnvoll sind – und wann nicht
Streams sind besonders hilfreich, wenn Ihr Team mehrere der folgenden Szenarien parallel verwalten muss: unterschiedliche Entwicklungsphasen desselben Produkts, mehrere Produktvarianten oder regionale Versionen, ein gewartetes Legacy-Release neben aktiver Neuentwicklung oder Feature Branches, die vor der Integration isoliert bleiben sollen.
In solchen Szenarien schaffen Streams eine saubere Trennung zwischen Konfigurationen, ohne dass vollständige separate Projekte gepflegt werden müssen. Gleichzeitig bleibt die Traceability über Varianten hinweg erhalten – ein entscheidender Faktor für Standards wie ISO 26262 oder IEC 62304.
Streams sind jedoch nicht für jede Situation das richtige Werkzeug. Wenn Ihr Team ein einzelnes Produkt mit einer linearen Entwicklungshistorie und ohne aktive Varianten verwaltet, dürfte der zusätzliche Konfigurationsaufwand kaum gerechtfertigt sein. In diesem Fall reicht der Initial Stream häufig aus. Zusätzliche Streams ohne klaren Anwendungsfall erhöhen eher die Komplexität, als dass sie echten Mehrwert schaffen.
Die richtige Frage lautet daher nicht: „Sollten wir Streams verwenden?“, sondern: „Haben wir mehrere parallele Konfigurationen, die unabhängig bleiben müssen, aber auf einer gemeinsamen Grundlage aufbauen?“ Wenn die Antwort ja lautet, sind Streams der passende Mechanismus.
Was als Nächstes wichtig wird
Das Verständnis des Stream-Konzepts ist die Grundlage. Der nächste Schritt besteht darin, zu wissen, wie Streams praktisch eingesetzt werden: für welche Use Cases sie besonders geeignet sind, wie phasenbasierte Entwicklung und Variantenmanagement in der Praxis aussehen und an welchen Stellen Teams typischerweise auf Schwierigkeiten stoßen.
Wenn Sie bewerten möchten, wie Streams in Ihre bestehende Codebeamer-Umgebung passen, oder wenn Sie eine Migration von einer älteren Codebeamer-Version planen, unterstützt Sie das Arorian-Team gerne bei der Einordnung.
FAQ
Ein Stream in Codebeamer ist eine projektübergreifende Konfigurationsebene, die festlegt, welche Version jedes Items sichtbar und aktiv ist. So können Teams mit einer spezifischen Produktkonfiguration arbeiten, ohne ganze Projekte duplizieren zu müssen.
Streams sind der Nachfolger der Working Sets in Codebeamer. Sie unterstützen einen ähnlichen Anwendungsfall – die Verwaltung paralleler Produktkonfigurationen –, sind jedoch projektübergreifend ausgelegt und besser für größere Umgebungen skalierbar.
Der Initial Stream ist der vordefinierte Stream, der in jeder Codebeamer-Instanz vorhanden ist. Er ist der Standard-Stream, in dem Benutzer arbeiten, solange keine zusätzlichen Streams erstellt werden.
Branched Trackers können sich in verschiedenen Streams unabhängig voneinander weiterentwickeln. Änderungen in einem Stream wirken sich also nicht automatisch auf andere Streams aus. Shared Trackers bleiben dagegen über alle Streams hinweg identisch, sodass Aktualisierungen überall sichtbar sind.
Nicht unbedingt. Wenn Sie ein einzelnes Produkt mit einer linearen Entwicklungshistorie und ohne aktive Varianten, parallele Releases oder Wartungszweige verwalten, kann der Initial Stream ausreichend sein.
Streams sollten in Betracht gezogen werden, wenn Sie mehrere Produktvarianten, Release-Zweige, Wartungsversionen oder Entwicklungsphasen parallel verwalten. Sie sind besonders nützlich, wenn Konfigurationen getrennt bleiben sollen, aber dennoch auf einer gemeinsamen Grundlage basieren.
