Kriterienkatalog SCM

Thema: Build-Management

 

 

Inhalt:

Buildmanagement

automatisches Erzeugen

korrektes Erzeugen

minimaler Aufwand

 

 

Thementreiber:

Ulf Caspers
Wespinstr. 14
68165 Mannheim
Fax: 0621 / 40 28 38
e-mail: UCaspers@Caspers.de

 
 

Buildmanagement

Unter Buildmanagement (Build) wird diejenige Funktion verstanden, die alle Bauteile einer Konfiguration erzeugt, die nicht direkt vom Benutzer erstellt oder durch das System vorgegeben wurden. Dieses Erzeugen soll durchgeführt werden.
 

automatisches Erzeugen

Das automatische Erzeugen soll bedeuten, dass die Erzeugung nach dem Start keine weitere Benutzerinteraktion verlangt. Es müssen also alle für die Erzeugung notwendigen Informationen zu Beginn des Builds zur Verfügung gestellt werden können. Neben der Konfiguration, auf die der Build angewendet werden soll, sind das vor allen Dingen Informationen über: Diese Informationen sollten mit den Bauteilen zusammen als Attribute in den Meta-Daten gespeichert werden. Aber auch Informationen zu müssen vorhanden sein, sollten aber ein Parameter beim Build-Aufruf sein.

Die Information über die zu verwendenden editierbaren Bauteile bestimmen, welche Eingabe der Build hat. Diese können zum Beispiel durch die Regeln einer Softwarekonfiguration bestimmt werden. Es ist allerdings auch denkbar, ein einzelnes, editierbares Bauteil direkt als Parameter des Build-Prozesses einzugeben. Weitere Bemerkungen dazu werden unter Build-Umfang beschrieben.

Der damit verbundene Bauplan sollte zum einen direkt aus einem Attribut des editierbaren Bauteils abgelesen werden können, sollte aber durch die gewünschte Zielplattform beeinflussbar sein. Es ist also denkbar, verschiedene Baupläne zu einem Bauteil zur Auswahl zu haben.

Alle zugehörigen Umwandlungsprogramme müssen sich aus den gewählten Bauplänen ergeben. Der Begriff Umwandlungsprogramm sollte dabei weit gefaßt werden und insbesondere

umfassen. Die jeweiligen Umwandlungsprogrammen müssen alle im Bauplan und am Bauteil selbst gespeicherten Parameter verarbeiten können.

Unter der Ablage wird ein physischer Speicherort eines Bauteils verstanden. Die Art der Ablage wird meistens über die Art des Bauteils bestimmt. Es muss vor dem Build bestimmt werden können, wo die generierten Bauteile nach dem Build gespeichert werden sollen.

Die Wahl der gewünschten Zielplattformen zum Zeitpunkt des Builds soll es ermöglichen, die gleiche Konfiguration für verschiedene Betriebssysteme oder Hardwarekonfigurationen zu bearbeiten. Hierzu sollten auch Varianten bei den editierbaren Bauteilen benutzt werden können. Der generierte Output sollte unbedingt in verschiedenen Ablagen für verschiedene Zielplattformen gespeichert werden.

Eine Einschränkung des Build-Umfangs sollte es zumindest ermöglichen, den Build "nur zur Probe" durchzuführen. Damit kann man überprüfen, welche Bauteile erzeugt werden würden, wenn der Build tatsächlich durchgeführt wird. Weiterhin sollte eine Einschränkung bezüglich der Art der verwendeten editierten Bauteile gemacht werden können. Hier ist zum Beispiel die Einschränkung auf einen bestimmten Änderungscode sinnvoll, oder die Beschränkung auf Bauteile, die aus dem eigenen Arbeitsbereich kommen.
 
 

korrektes Erzeugen

Das korrekte Erzeugen ist eigentlich eine selbstverständliche Eigenschaft. Sie bedeutet, dass alle zu generierenden Bauteile erzeugt werden.

Tatsächliches Erzeugen bedeutet nur, dass das Bauteil nach erfolgreichem Build erstellt wurde. Es sollte also kein Bauteil "vergessen" werden. Das muss für alle zu generierenden Bauteile der Konfiguration gelten.

Die richtigen Eingaben beziehen sich nicht nur auf die editierbaren Bauteile, sondern auch auf die Systembauteile, sowie die dazu gehörigen Parameter. Eine besondere Bedeutung gewinnt dieser Aspekt in Verbindung mit der Generierung für unterschiedliche Plattformen.

Besonders wichtig wird die richtige Reihenfolge dann, wenn generierte Bauteile auch als Eingabe verwendet werden. Es müssen stets alle Eingaben, die generiert werden sollen, auch schon generiert sein, bevor eine Umwandlung startet, die diese Eingaben nutzt. Hier muss das Buildmanagement dafür Sorge tragen, dass ein Umwandlungsfehler, bei dem ein Bauteil nicht oder nicht korrekt erstellt werden konnte, nicht von weiteren Umwandlungen ignoriert wird. Von diesem Bauteil abhängige Umwandlungen dürfen nicht gestartet werden. Echte Zyklen bei Abhängigkeiten von Umwandlungen müssen erkannt werden. Das sollte sich allerdings nur auf das Verwenden von generierten Bauteilen, nicht auf das Verwenden von Konfigurationen beziehen.
 

minimaler Aufwand

Zur Minimierung des Build-Aufwands sind natürlich viele Ansätze denkbar. Besonders wichtig sind jedoch: Da das SCM-System einen Überblick darüber hat, welche Eingaben korrekter Bauteile unverändert sind, kann es auch entscheiden, für welche Bauteile kein erneuter Build notwendig ist. Es muss jedoch unbedingt jede(!) Änderung der Eingaben erkannt werden, also auch eine Änderung der zu verwendenden Systembauteile. Allerdings ist es wünschenswert und auch wirtschaftlich die Änderung von ausgewählten Bauteilen nicht vollautomatisch an das SCM-System zu geben, sondern durch Steuerung durch einen Administrator. Dieser kann dann bei einer Änderung des Bauteils entscheiden, ob diese Änderung konfigurationsrelevant ist oder nicht.

Je nach Aufwand, den es bedeutet, ein Bauteil für eine Umwandlung zur Verfügung zu stellen, kann es sinnvoll sein, dieses Bauteil zwischenzuspeichern. Das ist besonders dann wichtig, wenn Eingaben mehrfach verwendet werden (Copy-Strecken) oder generierte Bauteile in einer folgenden Umwandlung verwendet werden. Ein typischer Fall ist das Verwenden von Bauteilen, die auf entfernten System liegen oder die in einem speziellen Format gespeichert werden.

Das Festhalten von Systemkomponenten ist dem Zwischenspeichern von Bauteilen ähnlich. Allerdings sollten dabei Systemressourcen, die für verschiedene Umwandlungen während eines Builds benötigt werden, nicht nach jeder Umwandlung freigegeben werden. Allerdings wäre es wünschenswert, dass der Bedarf anderer Prozesse im gleichem SCM-System berücksichtigt bleibt, damit für alle Prozesse ausreichend Ressourcen zur Verfügung stehen.


HomePage Inhalt Kontakt "über"

© 1998 DV-Beratung Ulf Caspers, Mannheim (Stand vom 6.4.1998)