Dozenten: Dr. Klaus Quibeldey-Cirkel,

Georg Odenthal

Richard Schuller

Matr.Nr.:461649

Tannenweg 1

35606 Solms- Niederbiel

Tel.: 06442/22778

Konfigurationsmanagement bezeichnet die Disziplin, die sich mit der Organisation und Kontrolle großer Software-Systeme befaßt. Sie ist entstanden durch die Notwendigkeit der Entwicklung und Wartung fortlaufend komplexer und größer werdender Systeme. Software-Systeme existieren in vielfältigen Variationen, aufgrund unterschiedlicher System- und Umgebungsanforderungen. Große Systeme sind in Komponenten strukturiert. Entwicklung und Wartung eines Systems erfolgt im Allgemeinen durch Entwicklung und Wartung der einzelnen Komponenten. Das führt zu einer kombinatorischen Vielfalt von Variationen [Rose 92].

Um diese Vielzahl der unterschiedlichen geänderten Komponenten zu verwalten und dem richtigen System zuordnen zu können sind Konfigurationsmanagement Werkzeuge entwickelt worden, um diese Verwaltung zu automatisieren.
 
 

Konfigurationsmanagement erlaubt es Entwicklerteams den Änderungsprozeß von Source- Code und Dokumenten und die Verwaltung von Produkten zu kontrollieren. Im Folgenden werden die Aufgaben betrachtet, mit denen Entwicklerteams konfrontiert werden und wie ein Konfigurationsmanagement Werkzeug die Umgebung schaffen kann diese Aufgaben leichter zu bewältigen.

Das Konfigurationsmanagement Werkzeug muß im stande sein in existierende Projekte integriert zu werden, sowohl bei sehr einfachen Verzeichnis Hierarchien, als auch als auch bei sehr komplexen und stark verschachtelten Verzeichnis Strukturen.

Wenn die Daten in das Konfigurationsmanagement Werkzeug geladen worden sind, muß das Tool es erlauben, auf einfache Weise eine Basis- Struktur zu schaffen, damit die Entwickler schnellstmöglichst mit der Arbeit am Source- Code beginnen können, ohne unnötig vom Konfigurationsmanagement Werkzeug daran gehindert zu werden.

Am besten sollte das Konfigurationsmanagement Werkzeug transparent sein; es sollte den Entwicklern erlauben, genauso wie bisher an Code- Files zu arbeiten, diese aber von abgespalteten Änderungen trennen. Diese Änderungen sollten aber zu einem beliebigen Zeitpunkt weiterverwendet werden können, so daß Teammitglieder die Änderungen jederzeit in ihr Projekt mit einbeziehen können. Konfigurationsmanagement Werkzeuge sollten Entwicklern gekapselte Bereiche bieten, in denen diese arbeiten können, aber sie sollten es erlauben, daß Entwickler als Team zusammenarbeiten und den geänderten Code untereinander austauschen.

Das Konfigurationsmanagement Werkzeug soll einem Team erlauben verschiedene Entwicklungsebenen zu erreichen, wo mit jedem höheren Entwicklungslevel ein immer größerer Grad an Stabilität erreicht wird. Außerdem sollte das Tool diese verschiedenen Ebenen verwalten und die Möglichkeit bieten den Code, der das Erreichen der nächsthöheren Ebene verhindert, zu markieren.

Reproduzierbarkeit ist ein anderes wichtiges Gebiet, das ein Konfigurationsmanagement Werkzeug beherrschen muß. Oft arbeiten Entwickler parallel an einer defekten und einer weiterentwickelten Version. Einige arbeiten an der defekten Version und ihre Arbeit hat andere Voraussetzungen als die Arbeit des Teams, das an der neuen Version arbeitet. Nachdem die defekte Version korrigiert worden ist, sollen die Änderungen in die neue Version übernommen werden.

Wenn gleichzeitig mehrere Produkte erstellt werden, muß das Support- Team im Stande sein größere Versionen wiederherstellen zu können, um die ausgelieferten Versionen warten zu können. Wenn die Anzahl gleichzeitiger Versionen, die von einem Team fertiggestellt werden steigt, so steigt auch der Bedarf, jede einzelne Version wiederherstellen zu können.
 

3. Continuus

3.1.1 Die Firma

Mit diesen Produkten und Serviceleistungen ist Continuus der Branchenführer, was die Bedienerfreundlichkeit, Flexibilität und Skalierbarkeit angeht, die zur Steigerung der Teamproduktivität, Verbesserung der Produktqualität und Beschleunigung der Erstellungs-, Upgrade- und Neu-Release-Prozesse in der Softwareentwicklung erforderlich sind.

Continuus ist eine in Privathänden befindliche Firma, die mit Venture-Kapital arbeitet. Die Produkte werden in Nordamerika, Frankreich, Deutschland und im Vereinigten Königreich direkt vertrieben und in anderen Ländern über Distributoren verkauft. Zu den Kunden zählen: BMW, Bell Atlantic, British Telecom, Dresdner Bank, Novell, Lehman Brothers, Motorola, Texas Instruments, Rockwell, Lockheed und Tandem Computers. [cont 1]
 

 3.1.2 Die Produkte

Zur nahtlosen Unterstützung der Arbeit eines Entwicklerteams integriert das Programm vier eigenständige, jedoch miteinander verknüpfte Aspekte der Anwendungsentwicklung:

•  Version Control/ Object Management zur Verwaltung der Objektversionen wie Verzeichnisse, Quelldateien, Bibliotheken, Executables, Designs, Dokumente, Terminpläne, Test-Cases, Testergebnisse, Makefiles und anderer Komponenten von Softwareentwicklungsprojekten.

• Parallel Development Support, so daß mehrere Teams mit ein und derselben Code-Basis arbeiten können, während gleichzeitig Patches, Maintenance Releases, Neu-Releases und mehrere Varianten für verschiedene Hardware- und Softwareplattformen produziert werden.

• Work Area Management schirmt die Entwickler gegen Änderungen durch andere Teammitglieder ab, die ihren Arbeitsbereich beeinträchtigen könnten. Das System isoliert die Entwickler jedoch nicht - sie werden über alle Änderungen durch andere Teammitglieder informiert, die sich auf ihre laufende Arbeit auswirken.

• Workflow Management zur automatischen Koordinierung der effizienten Performance zusammengehöriger Task-Ketten durch Mitarbeiter in den verschiedensten Funktionen wie Entwickler, Build-Manager, Test/Qualitätskontrolle und Projektmanager.

 Wann kann DCM den Änderungs- und Herstellungsprozeß von Software erleichtern? :

• Wenn ein Produkt erstellt wird, das Files enthält, die in mehr als einer Datenbank enthalten sind.
• Bei der Erstellung von Softwarekomponenten, die in anderen Datenbanken verwendet werden.
• Die Datenbank des Produktes, an dem man arbeitet, befindet sich nicht lokal an Ort und Stelle, sondern z. B. auf einem anderen Kontinent.
• Man will eine große Datenbank in mehrere kleinere aufteilen.

Continuus Object Make (Continuus/OM): Object Make, die objektorientierte Make-Komponente von Continuus, zur Reproduzierung ausführbarer Komponenten aus vorhergehenden Konfigurationen, zur Verteilung von Builds über mehrere Rechner in einem Netzwerk, um die Kompilierung zu beschleunigen, und zur Erzeugung einer Stückliste für die Problemlösung. Außerdem übernimmt Object Make das Auschecken eines Produktes (das Auschecken aller Daten und Files, die dieses Produkt/ diese Produktversion enthält).

Object Make bietet uneingeschränkte Funktionskontrolle für den Build-Prozeß und ist kompatibel zu gängigen MakeFile-Formaten.
 

Continuus Problem Tracking (Continuus/PT): PT bietet von der ersten Release bis zu mehreren Varianten nachfolgender Releases eine komplette Verknüpfung zwischen Änderungsanweisungen, zugewiesenen Tasks und den daraus resultierenden Change-Sets und dient zur Aufzeichnung und Mitverfolgung von Fehlerberichten und Verbesserungsanweisungen. Mit Hilfe einer Grafischen Benutzeroberfläche können Projektmanager und Leiter von Entwicklerteams die Änderungen nach Entwickler, Datum, Projekt oder Datei überwachen, ohne den Arbeitsablauf zu stören. Interaktive Dialoge ermöglichen flexible Online-Abfragen und Erstellung von Berichten , die für aussagekräftige Metriken und Statistiken erforderlich sind.

3.2 Vorteile von Continuus

Wenn Software verbessert oder ein Softwarefehler korrigiert wird, müssen in der Regel mehrere Quelldateien erstellt, respektive geändert, Test-Cases eingebaut und Dokumentationsdateien modifiziert werden. Traditionelle Systeme erfassen aber nur Änderungen an einzelnen Dateien, können aber die Beziehungen und Abhängigkeiten zwischen diesen Dateien nicht mitverfolgen. Daher sind die Mitarbeiter im Entwicklerteam gezwungen, die logischen Beziehungen selbst zu protokollieren, was häufig zu Kommunikations-, Build- und Softwarequalitätsproblemen führt.

Das task-basierte Change-Management von Continuus übernimmt die Mitverfolgung und Bearbeitung von zugehörigen Change-Sets. Das bedeutet:

• Die Entwickler müssen keine Listen mehr über die Dateien führen, die sie zwecks Verbesserung oder Fehlerkorrektur editiert haben.

• Die Entwickler müssen keine Dateien mehr einzeln einchecken. Außerdem gibt es keine fehlgeschlagenen Kompilierungen mehr, wie sie häufig in dateibasierten CM-Systemen vorkommen, wenn die Programmierer vergessen, alle Dateien einzuchecken, die sie für eine bestimmte Task editiert haben.

• Änderungen im Zusammenhang mit einer Verbesserung oder Fehlerkorrektur in einem Softwarerelease können per Mausklick rückgängig gemacht werden, wenn noch unvollständige Tasks die Auslieferung der Software blockieren.

• Erhöhung der Softwarequalität durch Erkennung von unvollständigen oder inkonsistenten Sets geänderter Dateien. Dieses sichere und intelligente SCM-System beseitigt Probleme wie beispielsweise das Wiederauftreten von Fehlern, die bereits in einer Vorgängerversion korrigiert wurden.

4. Continuus/CM verstehen lernen

 
4.1   Objects and Relationships
       Object Versions and the Object Pool
       Attributes and Types

 
Continuus/CM arbeitet mit Objekten. Ein Objekt ist ein Sammelsurium von Daten, so wie ein Verzeichnis oder ein Projekt. Objekte können sein, Source Code, Ausführbare Programme, Bibliotheken, Verzeichnisse und Dokumente. Continuus/CM verwaltet auch die Beziehungen zwischen den Objekten. Zur Veranschaulichung dient folgendes Bild.

In diesem Beispiel sieht man zwei Objekte mit dem Namen main.c. Das linke Objekt ist die erste Version und das rechte die zweite. Um ein Objekt in einer Datenbank anzugeben benutzt man den Namen des Objektes und die Version, z.B. die erste Version von main.c sieht folgendermaßen aus: main.c-1.

Diese zwei Objekte haben eine Beziehung, die zweite Version ist aus der ersten ausgecheckt, deshalb ist main.c-1 der predecessor von main.c-2 und main.c-2 ist der successor von main.c-1.

Jede Objekt-Version hat eine Fülle von Atributen. Ein Atribut ist eine Beschreibung der Objekt-Version, z.B. die Entstehungszeit, den Besitzer und den Status.

Der Objekt-Pool beinhaltet alle Versionen aller Files aller Objekt-Versionen. Egal wieviele Entwickler gerade eine Objekt-Version benutzen, in dem Objekt-Pool ist immer nur eine Kopie dieser Version.

Jedes Objekt hat einen Typ, dem es angehört, welcher die Art des Inhaltes des Objektes beschreibt, z.B. csrc (für C - Code), library, directory und executable. Continuus/CM hat schon vordefinierte Typen, die man aber in einem Dialogfenster beliebig ergänzen kann.

 
4.2 Lifecycle, States and Transitions
      Roles and Owners
      The Base Model

Jeder Objekt Typ hat einen Entwicklungszyklus (Lifecycle). Der Entwicklungszyklus ist zurückzuführen auf die möglichen Zustände (States) eines Objektes und in welchen Zustand ein Objekt aus seinem aktuellen Zustand übergehen kann (Übergänge (Transitions)). Zum Beispiel als definierte Zustände kann eine Objekt-Version folgende Zustände haben: working, integrate, test, sqa und released. Die folgende Grafik verdeutlicht die möglichen vordefinierten Zustände eines Objektes.

Die verschiedenen Zustände werden folgendermaßen benutzt:

• working: Code ist noch in der Entwicklung. Ein Objekt in dem working Zustand ist ausgecheckt und veränderbar.

• integrate: Wird vom Entwicklungsmanagement benutzt um die Integration zu testen.

• test: Erlaubt es Entwicklern Objekte anderer Entwickler zu nutzen, die den integrate Zustand passiert haben

• sqa: Hier wird auf System-Ebene getestet.

• released: Zum generellen Gebrauch freigegeben.

Jeder Entwickler arbeitet in Continuus/CM in einer bestimmten Rolle, die er aber zu jeder Zeit wechseln kann. Die Benutzer-Rolle definiert die Möglichkeiten, die ein Benutzer hat und zu welchen Objekten er Zugang hat. Typische Rollen sind developer, tester, build_mgr und type_developer. Jeder Continuus/CM Benutzer kann eine oder mehrere Rollen nutzen, die in seinen Benutzerrechten einzustellen sind.

Das Modell bezeichnet einen eigenen CM Prozeß. Das Modell beinhaltet die Typdefinitionen (z.B.: csrc, binary, projekt), die Rollen (z.B.:developer, build_mgr), die Sicherheitsbestimmungen, die Entwicklungszyklen und spezielle Zustände. Jede Continuus/CM Datenbank besitzt ein Basis-Modell. Das Basis-Modell kann dazu verwendet werden um den eigenen Entwicklungsprozeß genauer zu beschreiben. Wenn zum Beispiel eine Datenbank nur für Testzwecke verwendet wird, kann man die Typdefinitionen von working, integrate, test, sqa und released ändern in Beispielsweise test, repair, stable, build und released.
 
 

4.3 Projects and Project Versions
 

Eine sehr nützliche Art eines Objekts ist das Projekt. Ein Projekt-Objekt ist die Basis-Form einer Konfiguration und beinhaltet eine Kollektion von Objekt-Versionen und den Zusammenhang, in welchem die verschiedenen Versionen entstanden sind. Die Kollektion ist das Set von Objekt-Versionen, aus denen das Projekt besteht (Files, Directories) und der Zusammenhang ist die Umgebung in der diese Objekte entstanden sind (Plattform und Release).

Ein Projekt ist sehr nützlich, weil man in ihm mehrere Objekte verwalten kann, die es einem erlauben in mehreren Umgebungen zu arbeiten. Um das ganz zu verstehen muß man die verschiedenen Arten von Projekten in Continuus/CM verstehen. Es gibt drei Arten von Objekten:

• Das working- Projekt wird von developers (Entwicklern) benutzt, um einen oder mehrere gekapselte Arbeitsbereiche zu haben, um dort Code zu entwickeln und diesen zu testen.

• Das prep- Projekt wird von Build Managern benutzt um Softwarebestandteile zusammenzufügen und zu testen, sowohl auf Programm- als auch auf Systemebene und um eine Release fertigzustellen.

• Das released- Projekt wird benutzt, wenn eine Release getestet und ausgeliefert wurde.

Projekte werden genauso wie jede andere Art von Objekten versioniert. Eine bestimmte Version eines Projektes wird Projekt-Version genannt, z.B.: editor-1 oder editor-sqa.
 

 
4.4 Check In and Check Out, Use and Create
 

Um ein existierendes Objekt zu ändern, muß eine änderbare Version dieses Objektes existieren. Dieses wird mit der Check Out Operation erreicht, was eine neue, änderbare Version von der existierenden Version ableitet.

Die Check Out Funktion ist gleichbedeutend mit dem get -l Befehl in PVCS. In Continuus muß man ein Objekt nur auschecken, wenn man es ändern will, wenn man es nur betrachten oder benutzen will, muß man es nicht auschecken. Stattdessen kann man die Objekt-Version benutzen, die man braucht. Wenn man ein Objekt benutzt, integriert man ein bestehendes File, Verzeichnis oder Projekt in ein anderes Verzeichnis oder Projekt. Man kann alle Arten von Projekten auschecken, (z.B.: Files, Verzeichnisse, Ausführbare Programme oder Projekte).

Die Check In Funktion führt eine Version in einen anderen Zustand im Entwicklungszyklus über, sie ist gleichbedeutend mit dem put -n Befehl in PVCS. Man kann ein File mehrmals einchecken und es jedesmal in einen anderen Zustand führen.

Wenn man lieber ein komplett neues Objekt erzeugen will, als eine neue Version eines existierenden Objektes, dann muß man dafür die create Funktion benutzen, gleichbedeutend mit dem vcs -I Befehl in PVCS. Eine Objekt-Version muß erst created werden, bevor man sie einchecken kann.
 

4.5 The Directory, Directory Entries
      Candidate List and Selecton Rules
      Reconfigure
 

Ein Directory-Objekt enthält eine Liste von Objekten, Diese Objekte werden Verzeichnis- Einträge genannt. Man kann sich ein Projekt als ein Gefäß vorstellen, in dem die versionierten Verzeichnisse und Files enthalten sind. Dagegen ist das directory (Verzeichnis) wie ein Inhaltsverzeichnis in dem die Objekte aufgelistet sind, die dieses Verzeichnis enthält.

Das bedeutet, daß das Verzeichnis nicht die aktuellen Fileversionen enthält, sondern es enthält nur eine Liste dieser Files. Das ist sehr vorteilhaft, weil man so nicht das ganze Verzeichnis auschecken muß, um ein File aus diesem Verzeichnis auszuchecken. Man muß nur ein Verzeichnis auschecken, wenn man ein File dem Verzeichnis hinzufügen (use, create, add objekt) oder ein bestehendes löschen will (unuse).

Wenn ein Directory nicht ausgecheckt ist, es aber sein müßte, übernimmt Continuus dies selbstständig.

Ein Verzeichnis speichert die Liste der Objektbeschreibungen seines Inhaltes. Jedes Objekt besitzt eine candidate list. Die candidate list beinhaltet alle Versionen eines Objektes.

Die reconfigure Operation bestimmt den Inhalt eines Projektes oder Verzeichnisses, indem sie die Auswahlvorschrift auf jedes Projekt oder Verzeichnis anwendet. Das geschieht normalerweise um ein Objekt mit den wichtigsten Änderungen der anderen Teammitglieder abzudaten. Für jedes Objekt im Projekt oder im Verzeichnis wird die candidate list berechnet und die Auswahlvorschrift gibt an, welche der Versionen aus dieser Liste bei der Rekonfiguration benutzt wird.

Die Auswahlvorschriften (selection rules) speichern die Objekt-Versionen indem sie die Objekt-Versionen mit eines Liste von Vorschriften vergleichen. Diese Vorschriften vergleichen Attribute der Objekt-Versionen mit Attributen des rekonfigurierten Projektes. Normalerweise ist diese vorschriften-basierte Vorgehensweise der effizienteste Weg bei großen Projekten die "beste" Version unter einer großen Anzahl von möglichen Versionen in der CCM Datenbank herauszusuchen.

Die selection rules sind so voreingestellt, daß jeder Entwickler mit seinem eigenen Arbeitsplatz ausgestattet ist, isoliert von Versionen anderer Entwickler, die noch in der working-Phase sind. Eine Rekonfiguration bringt die letzten Änderungen anderer Teammitglieder, die die Testphase durchlaufen haben.

 
4.6 Products
      The Bill-of-Materials
      ObjectMake and Makefiles
 

Files, die bei der Erstellung anderer Files entstehen, werden Produkte genannt. Jeder Objekt-Typ ist ein potentielles Produkt. Die normalen Produkte sind: Ausführbare Programme, Bibliotheken und relokalisierbare Objekt-Files (.obj). Projekte können eine beliebige Anzahl von Makefiles enthalten, welche die Anweisungen zur Erstellung der Projekte enthalten. Allgemein spricht man von einem Produkt, wenn man Continuus/CM meint, aber in Continuus/CM Spezifikation ist jedes ausführbare Programmteil von Continuus/CM ein Produkt.

Es gibt kontrollierte und unkontrollierte Produkte.

Kontrollierte Produkte:

Kontrollierte Produkte sind Produkte, die in Continuus/CM als Objekt-Versionen kontrolliert werden. Das geschieht, wenn man die Make-Komponente von Continuus benutzt, oder per Hand die Objekt-Version als Produkt markiert.

ObjektMake ist die Make-Komponente, sie ist zu vielen gängigen Makefile-Formaten kompatibel. ObjektMake kann in das Objekt-System von Continuus/CM integriert werden. Wenn man ObjektMake benutzt, um ein kontrolliertes Produkt zu erstellen, speichert es Informationen über die Abhängigkeiten des Produktes und der Build-Umgebung. Diese Informationen werden zum erstellen eines Berichts verwendet, der in dem bom-Attribut jedes kontrollierten Produktes gespeichert wird. Dieser Bericht wird Bill-of-Material (BOM) genannt.

Nicht alle kontrollierten Objekte sind Produkte. Projekte und Verzeichnisse können keine Produkte sein, weil sie nicht als Ziel in Makefiles benutzt werden. Alle anderen Arten von Objekten können Produkte sein.

Wenn eine Objekt-Version als kontrolliertes Produkt markiert ist, erfolgt ein neuer Entwicklungszyklus, der Produkt-Entwicklungszyklus. Das nächste Bild veranschaulicht den Produkt-Lifecycle.

4.7 The Work Area
      Synchronize
 

Continuus speichert Objekte aus der Continuus/CM Datenbank an eine vorgegebene Stelle des Rechners. Wenn die Daten in der Work Area (Arbeitsumgebung) gespeichert sind, kann man über die Kommandozeile (Windows NT und 95) an den Files arbeiten. Die Work Area ist eine Projektion einer oder mehrerer CCM Datenbank-Projekt-Versionen in das lokale File-System. Die Work Area beinhaltet die File und Verzeichnis-Struktur und sie kann überall in der Netzwerk-Umgebung sein.

Jede Work Area beinhaltet jeweils eine Kopie jedes Files, wenn eine Objekt-Version in mehreren Projekten benutzt wird, ist in der Work Area von jedem dieser Projekte eine lokale Kopie angelegt.

In dem Objekt Pool ist aber nur eine Kopie dieses Files enthalten und man muß den Objekt Pool mit den Änderungen, die man gemacht hat updaten. Dies geschieht automatisch, wenn man eine Objekt-Version eincheckt oder man updatet die Änderungen zu einem beliebigen Zeitpunkt.

In dem Objekt Pool ist jedes File jeweils nur einmal enthalten, egal in wievielen Work Areas es gerade benutzt oder geändert wird.

Wenn man außerhalb der Continuus Datenbank an einem File arbeiten will, kann man eine Kopie des Files in seiner Work Area anlegen. Man kann das File ändern, ob die zugehörige Objekt-Version ausgecheckt wird oder nicht. Dann kann man die Datenbank wieder mit dem File updaten. Wenn die zugehörige Objekt-Version nicht ausgecheckt ist, übernimmt Continuus dies selbständig, wenn man einen Abgleich der Datenbank mit der Work Area vornimmt.

4.8 Instances
      Object Spec

Die instance ist ein numerisches Attribut, was automatisch für jedes Objekt, was in Continuus erzeugt wird, vergeben wird. Es wird vergeben um zwischen Objekten mit dem selben Namen und Typ zu unterscheiden, die aber nicht verschiedene Versionen eines Objekts sind. Zum Beispiel kann ein Projekt viele verschieden C-Source Files enthalten, alle in verschiedenen Verzeichnissen und jedes mit vielen Versionen. Wenn man nun main.c-4 benutzen möchte, liefert eine Anfrage diesbezüglich vier Objekte mit dem Namen main.c-4. In diesem Fall bestimmt man durch das instance Attribut, welches main.c-4 Objekt man benutzten möchte.

Jede Objekt-Version, die in Continuus/CM verwaltet wird kann mit den folgenden Attributen genau identifiziert werden: Name, Version, Typ und instance. Diese Identifizierung nennt man das object spec.

Den Namen und den Typ eines Objekts kann man selbst bestimmen, nur die instance wird von Continuus berechnet, indem die gespeicherten Informationen aus dem Objekt Pool dazu benutzt werden.

Vordefiniert wird das object spec folgendermaßen geschrieben: Name-Version: Typ: instance, zum Beispiel: main.c-3:csrc:2 oder draw.c-beta:csrc:7.

Wenn man ein File in einem Projekt oder zwischen Projekten verschiebt, bleibt das object spec dasselbe, es ist nicht vom Ort des Objekts abhängig.
 
 

4.9 Sessions
      Interface, Engine and the Database
 

Wenn man Continuus/CM benutzen möchte, muß man eine Session starten. Eine Session besteht aus zwei Prozessen: dem Interface und der Engine. Das Interface ist der Client Prozeß welcher startet und dann mit dem Engine Prozeß Verbindung aufnimmt, der der Server Prozeß ist. Die Engine nimmt dann Verbindung mit dem Datenbank Server auf. Jeder dieser Prozesse kann über das Netzwerk auf unterschiedlichen Rechnern laufen.

Eine Continuus/CM Datenbank enthält alle Objekt-Versionen, Typ-Definitionen und das Modell für ein oder mehrere Projekte. Eine CCM Datenbank besteht aus File-System-Daten als auch aus Meta-Daten, die in einer großen RDBMS gespeichert sind. Jede Session ist nur auf einer Datenbank aktiv. Die File-System-Daten können über das Netzwerk File-System verteilt sein.

4.10 Task
        Task/Object Relationship
        Default Task
 

Ein Task steht für eine Änderung die in dem Software Programm gemacht werden muß. Ein Task schließt alle Objekte zusammen, die geändert werden werden müssen, um die gewünschten Änderungen im dem Programm machen zu können, die der Task repräsentiert.

Zum Beispiel findet ein Benutzer einen Fehler in der GUI Komponente des Programms, er sendet eine Mail, indem er den Fehler beschreibt und der GUI-Gruppenleiter leitet es weiter an einen Entwickler. Dieser erstellt einen Task mit dem Namen Fix scrolling in Snap dialog. Immer wenn er ein File auscheckt, was dieses Problem beheben soll, assoziiert er das File mit diesem Task. Das folgende Bild verdeutlicht das.

Der Task und die Objekte haben eine Beziehung. Objekte die durch einen Task zusammengeschlossen sind nennt man auch mit dem Task verbunden. Verbunden heißt, daß alle Objekte, die zur Beseitigung eines Fehlers benötigt werden zu einer logischen Gruppe zusammengeschossen werden und diese Gruppe wird mit dem Namen des Tasks beschreiben. Die Objekte werden gruppiert, weil sie die Bestandteile sind, die zur Behebung des Fehlers benötigt werden, der durch den Task beschreiben wird. In dem Beispiel (siehe Bild oben) sind alle Objekte der Rechten Seite mit dem Task Fix scrolling in Snap dialog verbunden. Der Taskname beschreibt seine Aufgabe.

Zusätzlich, wenn ein Task erstellt wird, vergibt Continuus/CM eine Nummer für den Task. Außer dem Namen und der Nummer beinhaltet ein Task auch noch andere Informationen über die Änderungen, z.B.: der Name "Behebers". Dieser Name ist immer in den Informationen eines Tasks vorhanden, weil, wenn ein Task einem User zugeordnet wird, der Name des "Behebers" automatisch auf den Namen des Users gesetzt wird.

Man kann folgende Werte setzen, wenn man einen Task kreiert:

• release Dieser Wert bestimmt die Release, bei welcher die Änderungen durchgeführt werden sollen.Mögliche Werte bestehen aus dem Namen der Release, wie 2.0. Die Release-Namen werden in dem Release-Auswahldialog angezeigt.

• platform Dieser Wert gibt die Hardware-Plattform an, bei welcher der Task durchgeführt werden soll. Die möglichen Plattformen bestehen aus aus denjenigen, für welche die Software erstellt wurde. Die Plattform-Namen werden in der Plattform-Auswahldialog angezeigt.

• subsystem Dieser Wert bestimmt das Subsystem für den Task. Zum Beispiel, wenn man eine Cient- Server Applikation entwickelt, kann das Subsystem "Client", "Server" oder "Kommunikation" sein. Der CM-Atministrator kann spezielle Subsystem-Werte für die Applikation setzen.

Man kann zuerst den Task erstellen oder zuerst die Objekte auschecken und daran Änderungen vornehen und den Task erst später erstellen. Continuus unterstützt beide Vorgehensweisen, aber Continuus empfiehlt, falls möglich, erst den Task zu erstellen und dann die Objekte auszuchecken.

Tasks befinden sich in der Continuus Datenbank bei den Objekten, die verändert werden sollen. Tasks haben keine Versionen, aber sie durchlaufen einen Entwicklungszyklus (siehe Bild unten). Tasks können nicht andere Tasks enthalten.

Ein default Task ist ein Task, der gerade in Arbeit ist. Wenn man einen default Task bestimmt, teilt man Continuus/CM mit, daß immer wenn ein Objekt ausgecheckt wird, dieses Objekt automatisch dem Task zugeordnet wird. Jedesmal, wenn ein Verzeichnis ausgecheckt wird, wird das komplette Verzeichnis dem Task zugeordnet. Darauf folgt, daß, wenn man ein Objekt löscht, erstellt, verschiebt, hinzufügt, oder wegnimmt, also alles, was zu einer Änderung des Verzeichnisinhaltes führt, Continuus/CM nicht nur das Verzeichnis automatisch auscheckt, sondern das Objekt (wenn eins erstellt oder hinzugefügt wurde) und das Verzeichnis dem default Task zuordnet.

Benutzen der Tasks erlaubt es jede Änderung als eine Einheit durch den CCM Entwicklungszyklus zu führen. Mit der Taskinformaton kann man ein Projekt konfigurieren, indem man die logischen Änderungen , die man will, spezifizieren kann. Wenn man Tasks benutzt, um Änderungen nachvollziehen zu können, verdeutlicht man, daß Objekte, die einem Task zugeordnet sind auch zusammen benutzt werden sollen und daß das Benutzen mancher dieser Versionen in einem Projekt ohne die anderen nicht funktioniert. Mit diesen Informationen kann Continuus einem helfen Konfigurationsplobleme früher in dem Entwicklungszyklus zu finden

4.11 Lifecycle, States and Transitions
        Roles
 

Alle Tasks haben einen Entwicklungszyklus. Der Entwicklungszyklus führt zu den möglichen Zuständen eines Tasks und in welche Zustände ein Task gelangen kann (transition) ausgehend vom aktuellen Zustand des Tasks. Zum Beispiel laut Voreinstellung kann ein Task folgende Zustände haben: registered, task_assigned, completed. Das folgende Bild zeigt die möglichen Zustände eines Tasks.

Die Zustände werden forgendermaßen benutzt:

• Der registered Zustand wird für Tasks benutzt, die erstellt, aber noch nicht zugewiesen wurden. Ein Task in dem registered Zustand kann noch verändert werden und wartet darauf zugewiesen zu werden.

• Der task_assigned Zustand wird von Tasks benutzt, die zugewiesen wurden. In diesem Zustand kann der Task geändert und und von dem benutzt werden, dem er zugewiesen wurde.

• Der completed Zustand wird bei Tasks benutzt, die abgeschlossen wurden. In diesem Zustand ist der Task eingecheckt und nicht mehr veränderbar, außer vom CM Administrator. Alle Objekt-Versionen, die dem Task zugeordnet sind, müssen eingecheckt sein, bevor der Task aufgehoben werden kann. Nur derjenige, dem der Task zugeordnet ist, kann diesen fertigstellen.

• Der Task in dem mittleren Zustand seines Entwicklungszyklus und ist jemandem zugeordnet.

• Der Task kann geändert werden (z.B.: es können Objekt-Versionen dem Task zugeordnet oder entfernt werden).

4.12 Task Folder
        Task Folder/Project Relationship
 

Ein Task Folder (Verzeichnis) ist eine Gruppe von Tasks. Man kann ein Verzeichnis benutzen, um alle Tasks zusammenzufassen, die zusammengehören, z.B.: gleicher Zustand, Release, Besitzer oder mögliche Kombinationen. Beispiele für Task-Verzeichnis Namen sind: All tasks assigned to Hannah oder All completed tasks for release 2.0.

Man kann Tasks in Verzeichnisse hinzufügen, indem man manuell alle Tasks selektiert, die man hinzufügen will. Wenn man das so macht, enthält das Verzeichnis nur diese Tasks, bis man ihn erneut manuell ändert.

Eine andere Möglichkeit Tasks Verzeichnissen hinzuzufügen ist, ist eine Anfrage (query) zu erstellen. Zum Beispiel kann man eine Anfrage erstellen, die alle Tasks für Release 2.0 heraussucht. Immer wenn das Verzeichnis geöffnet wird, sucht CCM nach neuen Tasks, die das Kriterium erfüllen und fügt sie dem Verzeichnis hinzu. Der Vorteil dieser Vorgehensweise ist, daß man nicht mehr manuell das Verzeichnis updaten muß, wenn man einen neuen Task erstellt; wenn der Task das Kriterum erfüllt, fügt CCM den Task automatisch dem Verzeichnis hinzu.

Das folgende Bild zeigt, wie ein Entwickler Task folders benutzen kann.

Entwickler und Build Manager benutzen Verzeichnisse auf folgende Arten:

• Entwickler Im Beispiel (Bild oben) fügt Hannah ihr Verzeichnis Hannah's tasks for release 2.0 ihrem working Projekt bei, so daß die Objekt-Versionen die sie gerade ändert ausgewählt werden. Wenn sie ihr Projekt rekonfiguriert, macht die Verzeichnis-Anfrage folgendes:

• Alle Tasks von Hannah durchsuchen
• Die Objekt-Versionen benutzen, die diesen Tasks zugeordnet sind, um das Projekt upzudaten.

• Build Manager Der Build Manager will alle Tasks heraussuchen, die für Release 2.0 fertiggestellt worden sind, um sie für den integraton-Test fertigzustellen. Er erstellt ein Verzeichnis, das alle fertiggestellten Tasks für Release 2.0 enthält. Er nennt das Verzeichnis z.B. Completed tasks for release 2.0 und erstellt die Anfrage (Query) des Verzeichnisses, alle fertiggestellten Tasks für Release 2.0 herauszusuchen. Er fügt das Verzeichnis seinen Einstellungen zur Rekonfiguration des Projektes bei. Wenn er das Projekt rekonfiguriert, sucht das Verzeichnis alle Tasks heraus, die für Release 2.0 fertiggestellt sind und integriert sie in den nächsten Entwicklungsprozeß.

 

Die Rekonfiguration ist der Prozeß, bei dem Objekt-Versionen in einem Projekt upgedatet werden, indem mehrere Regeln darauf angewendet werden. Diese Regeln bestimmen die Versionen, die am besten auf die Eigenschaften des Projektes passen.

In der task-basierten Vorgehensweise wird ein Projekt konfiguriert, indem man sie auf der vorherigen Version des Projektes ableitet und Veränderungen daran vornimmt. Zum Beispiel, man will das toolkit Projekt für Release 2.0 konfigurieren, dabei baut man es auf Release 1.0 auf und fügt alle Änderungen für Release 2.0 hinzu.

Die Projekt-Version auf welche das neue Projekt aufbaut wird Baseline genannt. Die Baseline kann ein released- oder ein prep- Projekt sein. Man sollte mit dem Build Manager abstimmen, welche Version des Projektes als Baseline genommen werden sollte.

Man kann die Änderungen, die man vornehmen möchte festhalten, indem man eine Liste von Tasks erstellt. Genauso kann man eine List von Verzeichnissen anlegen, die Continuus dazu verwenden kann die Liste der Tasks zu finden. Jedem Task aus der Liste können eine oder mehrere Objekt-Versionen zugeordnet werden, die den Fehler beheben.

Daraus folgt, daß ein Projekt aus einer Baseline, einer List von Tasks und / oder einer Liste von Verzeichnissen bestehen kann. Diese Informationen werden die Rekonfigurations- Eigenschaften des Projekts genannt. Wenn man eine Rekonfiguration durchführt, benutzt CCM diese Informationen zum updaten des Projekts aus folgende Weise:

• Als erstes bestimmt CCM, welche Tasks benutzt werden. CCM erstellt eine Liste aller Tasks, die in den Verzeichnissen enthalten sind und alle, die in den Eigenschaften direkt stehen.

• Als nächstes errechnet CCM eine List von Objekt-Versionen, indem jeder Task aus der Liste durchsucht wird. Die Objekte dieser Liste und diejenigen aus dem Baseline-Projekt werden in die candidate list der Rekonfiguration aufgenommen.

• Als letztes bestimmt CCM die Kandidaten indem einfache Regeln darauf angewendet werden. Die Regeln vergleichen die Eigenschaften der einzelnen Objekt-Versionen mit den Eigenschaften des Projekts, um die geeignetsten Versionen herauszusuchen.

4.14 Personal Tasks
 

Immer wenn man ein working Projekt oder Produkt erstellt, das man mit Änderungsanweisungen benutzen möchte, erstellt CCM automatisch einen Task, dieser Task wird personal Task genannt. Der personal Task Name wird standartmäßig folgendermaßen generiert:

• Der personal Task Name lautet standartmäßig user's working projects. Wenn es schon eine Release des Projekts gibt, dann lautet der Name user's working projects for release release.

• Der personal Task für die working Produkte heißt user's working products. Wenn das Produkt einen Release Wert hat, dann lautet der Name user's working products for release release.

Nur Produkte und Projekte werden personal Tasks zugewiesen. Daraus folgt, daß man den default Task nicht auf einen personal Task setzen kann. und sie werden nicht im Task Auswahldialog unter den zugewiesenen Tasks angezeigt.
 
 
 

4.15 Build Management Tasks
 

Immer wenn man ein prep Projekt oder Produkt erzeugt, was man unter Task basiertem CM benutzen möchte, wird automatisch ein Task erzeugt, er wird Build Management Task genannt.

Der Name des Tasks ist abhängig von den Eigenschaften des Projekts, die bei der Erstellung des prep Projekts bestimmt wurden. Der Name wird folgendermaßen erzeugt:

• Wenn das Projekt zum Integrationstest erzeugt wurde, lautet der Name Integration testing projects.

• Wenn das Projekt zum Systemtest erzeugt wurde, lautet der Name System testing projects.

• Wenn das Projekt einen Release Wert besitzt, lautet der Name integration testing projekts for release release. oder system testing projects for release release.

Der Build Manager kann einen Build Management Task fertigstellen, wenn alle Projekte und Produkte einchecken kann die dem Task zugeordnet sind. Das ermöglicht es den Entwicklern, den Task in ihre Projektrekonfigurationseigenschaften einzugliedern. So teilen sich die Entwickler die Projekte und Produkte die dem Task zugeordnet sind.

Wenn ein Build Management Task beendet wurde, wird automatisch ein neuer erstellt, sobalt ein neues Produkt oder Projekt erstellt wird. Der neue Task kann die gleichen Eigenschaften haben, wie der alte, oder man verändert seine Eigenschaften, um ihn zu spezialisieren. Zum Beispiel man will die Eigenschaften eines Task spezialisieren von Integration testing products for release 2.0 zu Interation testing products for release 2.0 build 3, bevor man ihn eincheckt und ihm Produkte zuordnet.
 
 
 

5. Was kann Continuus/CM

Man kann existierende Verzeichnisse und Files aus dem File-System in die Datenbank von Continuus/CM hereinladen, indem man den migrate -Befehl benutzt.
Man kann ein komplettes Produkt hereinladen oder, wenn man nur einen Teil des Produktes benötigt, diesen Teil. Im folgenden wird erstmal das Laden eines kompletten Projektes beschrieben.

Project Migration:

Ein Projekt besteht aus einzelnen Verzeichnissen, Files und Subprojekten. Normalerweise enthält ein Projekt den Source-Code und die Makefiles, um ein oder mehrere Produkte zu erstellen. Das Projekt kann eine einfache oder eine sehr verschachtelte und große Verzeichnisstruktur haben.
Einige Projekte zeigen die gleiche Verzeichnisstruktur, in der auch die Verzeichnisse und Files erstellt wurden, andere gruppieren Objekte, um das Installationsverzeichnis zu repräsentieren oder um Verzeichnisse, Files und Objekte zusammenzufassen, an denen ein Entwickler normalerweise arbeitet.

Man kann den migrate -Befehl immer dann benutzen, wenn man ein Verzeichnis oder Files nach CCM laden möchte. Abhängig von der Größe und Menge der Verzeichnisse und Files, die in CCM geladen werden, muß man die folgenden Punkte beachten, um die optimale Projekt Einteilung zu erreichen:
 

Projektgröße

• Projektteam

• variante Projekte

• Wiederverwendbare Objekte

Projektgröße

Bevor man ein Projekt in CCM lädt, muß man die Größe des Projektes beachten, wenn es nur aus einigen hundert Files mittlerer Größe besteht, kann man es mit gleicher Struktur aus dem Filesystem laden, wenn es aber aus mehr als 2500 Objekten besteht, muß man es in Subprojekte unterteilen. Die migrate- Funktion erlaubt es, sich die File- Struktur schon vor dem Laden der Daten anzusehen. Man kann einzelne Dateien auswählen, die nicht mit eingecheckt werden sollen. In diesem Dialogfeld kann man noch die Filetypen und Regeln zum Einchecken der Verzeichnisse und Files einstellen. Das folgende Bild zeigt das Dialogfeld, wo die Datenstruktur vor dem Laden angezeigt wird.
 

Wenn das Projekt, was man laden möchte mehr 2500 Objekte hat, dann gibt CCM eine Warnung aus. So hat man die Möglichkeit, die Projekt-Struktur nochmal zu überdenken.
 

Projektteam

Die Größe und die Organisation des Teams ist wichtig.
Wenn viele Entwickler an einem großen PRogramm arbeiten und wenn eine Unterteilung möglich ist, kann man das Projekt in mehrere Unterprojekte unterteilen, so daß jeder Entwickler nur mit den Daten zu tun hat, die er wirklich benötigt und an denen er arbeitet, so daß die Anzahl der Objekte, die er verwalten muß möglichst klein ist. Das ist auch für die Verwaltung von Dokumentation eine sinnvolle Unterteilung.
Das Unterteilen des Programms in mehrere Komponenten als Subprojekte verringert den Zeitaufwand und den Speicherplatz, die gebraucht werden, um das Projekt zu entwickeln.

Variante Projekte

Ein variantes Projekt ist eine unterschiedliche Variante des selben Produkts, so wie ein Programm, was für UNIX und WINDOWS erhältlich ist.
Normalterweise werden die Variant Project- Einstellungen für jede Plattform vorgenommen, auf die das Projekt portiert wird.
Die Einstellungen unterscheiden sich in den Projekt-Objekten, dort wird in dem Dialogfeld die Plattform angegeben, auf der das fertige Projekt laufen soll.

Wiederverwendbare Projekte

CCM erlaubt es, das Projekt oder das zu erstellende Programm, in kleinere Teile zu unterteilen und man kann diese Projekte dann in anderen Produkten wiederverwenden. Das folgende Bild veranschaulicht dieses anhand eines Beispiels.

Incremental Migration:

Wenn man Software aus dem File-System in ein existierendes Projekt in CCM laden möchte, führt man eine incremental migration durch, d.h. es wird ein Teil/Bereich neu in das Projekt geladen. Man kann dies auf zwei Arten machen:
Nur die Files und Verzeichnisse laden, wo man weiß, daß sie noch nicht im Projekt enthalten sind, oder ein ganzes Projekt laden, wo einige oder viele der Objekte bereits in dem CCM Projekt enthalten sind.
 
 

5.2 Betrachtungsweisen der Daten

Es gibt zwei Hauptsichtarten, sich die Daten anzusehen: die Project View und die History View.

Project View

Die Project View zeigt alle Projekte, die in der CCM Datenbank enthalten sind. Normalerweise, aber nicht immer, arbeitet man an einer Datenbank. Wenn mehr als eine Datenbank aktiv ist, wird in der Kopfzeile des Project View Fensters die Datenbank angezeigt.
Das nächste Bild zeigt die Project View und erklärt die wichtigsten Optionen die Daten zu betrachten.

History View

Die History View erlaubt es, die verschiedenen Versionen eines Objekts zu bestrachten, die "History". Alle Versionen vor der aktuellen Version werden "predecessors" genannt und alle Versionen nach der aktuellen werden "successors" genannt.
Das nächste Bild zeigt die grafische Darstellung der History View.

In der History View kann man auch feststellen, ob es parallele Versionen eines Objekts gibt. Wenn laura an der Objekt-Version gui.c-final arbeitet, kann sie in der History View feststellen, daß tomf eine parallele Version von gui.c ausgecheckt hat.
 
 

5.3 Funktionen der Work Area

Continuus/CM erzeugt die gleiche Struktur in dem File-System der Work Area, wie sie auch in der Datenbank vorhanden ist. Diese Projektion ist eine lokale Kopie der Object Pool Files.

Synchronisation der Work Area:

Continuus/CM updated die Work Area automatisch und transparent, wenn ein Projekt erzeugt oder geändert wird. Dies wird gemacht, um sicherzustellen, daß die Files in der Work Area und im Object Pool identisch sind. Sie müssen gleich sein, damit man Zugang zu den Source Files hat, die es einem erlauben viele Operationen auszuführen, wie z.B.: erstellen und ändern.

Nachdem man ein Projekt erstellt hat, kann man die Session beenden und neu starten, ohne einen synchronisations Befehl durchzuführen.

Work Area Projektionen:

Jede Projekt-Version hat einen einzelnen Work Area Bereich. Man kann den Ort dieses Bereichs in dem Work Area Dialog ändern, aber der Bereich existiert nur einmal. Wenn man das gleiche Projekt in mehreren Bereichen gleichzeitig haben möchte, muß man für jeden Bereich eine andere Version auschecken. Wenn man verschiedene Versionen eines Projekts auscheckt, sieht man alle, wenn man ein dir in der Work Area macht. Das sieht folgendermaßen aus:
 

> dir

Volume in drive C is MS-DOS6
Volume Serial Number is 1F49-8A37

Directory of C:\users\laura\ccm_wa\ccmb219

02/01/96   03:04p <DIR>  .
02/01/96   03:04p <DIR>  ..
02/01/96   03:04p <DIR>  demo-1
02/07/96   01:23p <DIR>  demo-2
02/21/96   09:15a <DIR>  demo-3
 

Eine Konsequenz dieses einzelnen Work Area Bereiches ist, daß eine Work Area unter Windows nicht unter UNIX betrachtet werden kann und umgekehrt. Continuus erwartet, daß unterschiedliche Versionen eines Projekts für unterschiedliche Plattformen verwendet werden.
 
 

5.4 Objekt- und Projekt- Versionierung

Objekte in einer CCM Datenbank können linear oder parallel sein. Ein lineares Objekt ist ein Objekt, daß nacheinander aus- und eingecheckt wurde. Ein paralleles Objekt entsteht, wenn zwei oder mehr Objekte von einem einzigen Objekt ausgechekct wurden. Jede Art eines nicht- Projekt und nicht- Produkt Objekts folgt unterschiedlichen Versionierungsregeln.

Projekte und Produkte werden nach der Benutzerrolle und der eingestellten Filenamenslänge versioniert.

Versionierung linearer Objekte:

Continuus/CM erzeugt Versionen von Objekten, davon ausgehend, ob es Projekt, Produkt, nicht- Projekt oder nicht- Produkt Objekte sind.

Nicht- Projekt, nicht- Produkt Objekte:

CCM erzeugt automatisch Versionsnummern beginnend mit 1, für jedes nicht- Projekt, nicht- Produkt Objekt, welches in CCM erzeugt wird, unabhängig von der Benutzerrolle, die man hat. Jedes Mal, wenn das Objekt ausgecheckt wird, wird die Versionsnummer um eins erhöht.

Projekt und Produkt Objekte:

Wenn ein developer ein Projekt oder Produkt Objekt erzeugt, ist dies seine persönliche Version, sie ist nicht für den allgemeinen Gebrauch bestimmt. Wenn ein Build Manager ein Projekt oder Produkt Objekt erzeugt, so soll diese vom kompletten Team benutzt werden können. Deshalb erzeugt CCM abhängig von der Benutzerrolle und dem Benutzernamen Projekt und Produkt Objekt-Versionen.

Wenn man in der tester, build_mgr, type_developer oder ccm_admin Rolle ist, erzeugt CCM automatisch Versionsnummern beginnend bei 1, sie wird dann jeweils um eins erhöht.

Wenn man in der developer Rolle ist, erzeugt CCM Objekt-Versionen mit dem Benutzernamen. Bei Bedarf wird dann an den Namen eine 1 gehängt, diese wird dann auch um eins erhöht.

Zum Beispiel: draw.obj-jeff => draw.obj-jeff1

Versionierung paralleler Objekte:

CCM erzeugt auch automatisch Versionen für parallele Objekte. Die Nummerierung einer parallelen Version beginnt bei n.1.1 (n ist die Version, von der das Objekt ausgecheckt wurde). Man kann parallele Objekte genauso verändern und modifizieren wie lineare Versionen.

Das folgende Versionierungsschema garantiert eindeutige Versionsnummern, die immer in der gleichen Versionsebene sind. CCM benutzt dieses Versionierungsschema für eine neue Version, wenn man eine parallele Version auscheckt:
 

Man kann die Version zu einem aussagekräftigen Word oder Buchstabenkombination abändern. CCM benutzt dieses Word oder Buchstabenkombination weiter und hängt die nächste logische Nummer an die ausgecheckte Version. Zum Beispiel wenn man zwei Versionen des Objekts main.c hat, kann man diese in main.c-win und main.c-unix ändern. Wenn man diese Versionen nun auscheckt wird daraus main.c-win1 und main.c-unix1. So kann man auf einfachste Weise verdeutlichen, welche Version zu welcher Plattform o.ä. gehört.
 
 

5.5 Verschmelzung mehrerer Datensätze und Verzeichnisse
 

Während des Entwicklungszyklusses kann es vorkommen, daß mehrere Leute gleichzeitig an dem selben Objekt arbeiten müssen. Es wird jeweils eine Version von der letzten Version ausgecheckt und diese Objekte sind parallele Versionen.
Aus diesem Grund muß es möglich sein, parallele Versionen zu verschmelzen. Normalerweise macht das derjenige, der die letzte parallele Version eincheckt, weil ansonsten die Unterschiede in den Versionen nicht berücksichtigt werden. Die parallelen Versionen können erst verschmolzen werden, wenn alle Versionen nicht mehr verändert werden können, aber man muß nicht erst die letzte Version einchecken, bevor man die Versionen verschmilzt, sondern CCM weißt darauf hin, das es noch parallele Versionen gibt und fragt, ob diese gleich verschmolzen werden sollen.
Die gleiche Möglichkeit gibt es auch mit Verzeichnissen.
Der File Merge Dialog ermöglicht es, zwei kontrollierte Objekte zu verschmelzen, der Name des dadurch entstandenen Objektes basiert auf dem des ersten Objektes.
Der Directory Merge Dialog ermöglicht es zwei kontrollierte Verseichnisse zu einem neuen Verzeichnis zu verschmelzen, der Name des neuen Verzeichnisses basiert auf dem des ersten Verzeichnisses.
 
 

5.6    Die Benutzung von Tasks
 

Ein Task steht für ein Problem, das in der Softwareanwendung beseitigt werden soll, oder für eine Erweiterung, die in die Softwareanwendung integriert werden soll. Weil ein Task alle Objekte, die für die Änderung bearbeitet wurden zusammenfaßt, muß man nicht jedes Objekt einzeln einchecken, sondern man checkt nur den einen Task ein, der die Objekte zusammenfaßt. Auf diese Weise nehmen Tasks den Benutztern eine Menge Arbeit ab.
Die folgenden Task Operationen müssen in der Reihenfolge angewand werden, wie sie auch vorgestellt werden:
 

• Task Registrieren: Jeder CCM oder CPT Benutzer kann einen Task registrieren. Dieser Schritt ist nicht unbedingt notwendig, weil ein Task automatisch registriert wird, wenn man ihn jemandem zuweist.
• Task Zuweisen: Man kann einen Task sich selbst zuweisen, oder man weist ihm dem Projektleiter zu oder der Build Manager weist einem einen Task zu. Wenn ein Task einem zugewiesen ist, kann man Objekte mit ihm verknüpfen.
• Task als Default Task setzen: Man kann jeden Task, der einem zugewiesen ist als Default Task setzen.
• Auschecken der Objekte, die geändert werden sollen: Bevor man Objekte auscheckt muß man einen Default Task gesetzt haben. Jetzt muß man die Objekte wählen, die man ändern möchte und diese auschecken. Jetzt sind die Objekte automatisch mit dem Task verknüpft.
• Task einchecken: Wenn man einen Task eincheckt, dann checkt CCM erst die Objekte ein, die mit diesem Task verknüpft sind, bevor der Task eingecheckt wird. Ein Task in dem completed Status ist für den Build Manager verfügbar.

5.7    Die Benutzung von Task Verzeichnissen
 

Ein Task Verzeichnis enthällt eine logische Gruppierung von Tasks. Normalerweise gibt es zwei Arten von Verzeuchnissen: ein Entwickler Verzeichnis und ein Build Manager Verzeichnis.

working Projekte und Task Verzeichnisse

Jeder Entwickler, der an einem Projekt arbeitet, hat eine persönliche Version dieses Projektes, welches working Projekt heißt. Wenn ein Entwickler einen Punkt in seiner Arbeit erreicht hat, wo er die Änderungen des Projektes in sein working Projekt einbringen möchte, so updatad er seine Work Area. Diese Aktion heißt Rekonfiguration.

Die Rekonfigurationsvoreinstellungen in einem Projekt eines Entwicklers enthalten normalerweise mehrere Verzeichnisse: ein Verzeichnis für die zugewiesenen und beendeten Tasks einer bestimmten Release, an der er gerade Arbeitet und ein Build Manager Verzeichnis für die getesteten Tasks dieser Release.

Ein Entwickler setzt die Rekonfigurationsvoreinstellungen für ein Projekt nur einmal und dann werden diese jedesmal bei der Rekonfiguration des Projekts angewendet. Bei jeder Rekonfiguration werden außerdem alle weiteren zugewiesenen Tasks, die das Projekt betreffen in das Task Verzeichnis geladen. Ein Entwickler muß die Rekonfigurationsvoreinstellungen erst dann wieder ändern, wenn er an einer neuen Release arbeitet.
 

integration Test Projekte und Task Verzeichnisse

Die prep Projekte enthalten Versionen von Files, Verzeichnissen und Produkte, die Build Manager zum Testen und zum Vorbereiten einer Release benutzen. Diese Projekte können nur von Build Managern verändert werden.

Ein prep Projekt repräsentiert die Arbeit eines Entwicklers in der Ebene des Entwicklungszykluses, für die das prep Projekt steht. Normalerwiese gibt es zwei prep Projektversionen für jedes Projekt: das integration prep Projekt zum Integrationstest und das sqa prep Projekt zum Systemtest.

Der Build Manager benutzt Task Verzeichnisse auf zwei Arten: zum Zusammenfassen was alles benötigt wird und zum zeigen, was alles schon fertiggestellt wurde.
 

Verzeichnisse, die Tasks für einen Buildprozeß zusammenfassen

Der Build Manager wird sein integrations prep Projekt jede Nacht rekonfigurieren, um die Software für den Integrationstest zu erstellen. Das integrations prep Projekt wird ein Verzeichnis haben wie Completed Tasks for Release 2.0. Wen der Build Manager sein Projekt rekonfiguriert, fragt das Verzeichnis nach Tasks, die von Entwicklern für die Release 2.0 fertiggestellt worden sind. Außerdem wird das Projekt mit den Objektversionen, die mit den Tasks verbunden sind, upgedatet. Dann kann der Build Manager die Softwareapplikation erzeugen.

Wenn der Prozeß nicht erfolgreich verläuft, kann der Build Manager entweder Tasks erstellen und sie den Entwicklern zuweisen, deren Objekte nicht fehlerfrei funktionieren, oder er sagt ihnen das und sie erzeugen ihr eigenen Tasks.
 

Verzeichnisse, die Tasks für andere zugänglich machen

Nachdem der Build Manager das Produkt erfolgreich erzeugt hat, kopiert er den Inhalt des fertiggestellten Verzeichnisses in ein Verzeichnis das Tested tasks for release 2.0 heißt. Die Entwickler können dann ihr Projekt rekonfigurieren, um die wichtigsten Änderungen einzubringen.
 

system Test Projekte und Task Verzeichnisse

Die sqa prep Projekte enthalten die Versionen der Files, Verzeichnisse und Produkte, die für den Systemtest und zur Vorbereitung der Release benutzt werden. Diese Projekte können nur von Build Managern verändert werden.

Ein sqa prep Projekt enthält die Arbeit aller Entwickler, die zum Systemtest fertig ist.

An einem bestimmten Punkt im Projekt erzeugt der Build Manager eine Softwareinstallation zum Qualitätssicherungstest. Ein Verzeichnis mit dem Namen Tasks for system test cycle enthält die Software, die erstellt werden soll. Jetzt wird die Softwareapplikation getestet und ein Team prüft, welche Änderungen noch durchgeführt werden müssen, bevor die Release erstellt werden kann. Danach ergänzt der Build Manager die Tasks der Änderungen manuell in das System test Verzeichnis, weil an diesem Punkt der Inhalt des Projektes feststeht. Manuell ergänzte Tasks isolieren die Testumgebung von den Änderungen der Entwickler.
 

5.8    Rekonfigurieren eines Projekts
 

Eine Rekonfiguration updated ein Projekt automatisch mit den wichtigsten Änderungen der enthaltenen Objekte. Wenn ein Task Verzeichnis für dieses Verzeichnis existiert, dann wird dieses zuerst durchgearbeitet, um zu den Tasks zu gelanden, danach werden die Tasks durchgearbeitet, um zu den Objekten zu gelangen. Die selection rules Prüfen, welche der Versionen eines Objektes am besten geeignet sind und wählen diese aus.
 

5.9   Fertigstellen des Produktes
 

Wenn ein Produkt fertiggestellt werden soll, müssen die Projekte in den released Status gebracht werden. Dadurch wird die neue Basis erzeugt, von der aus ein Projekt weiterentwickelt wird.

Zum Übergang in den released Status müssen alle enthaltenen Objekte bereits im released Status ein, damit sichergestellt ist, daß die Produktversion zu einem späteren Zeitpunkt wiederhergestellt werden kann.

Wenn man ein Projekt fertigstellt, dann sollte man ihm eine markante Releasenummer geben, wie 4.2 oder rel6b.
 
 
 

6. Veranschaulichung anhand eines Beispieles

Die Demo geht auf die wichtigsten Funktionen in Continuus ein und man bekommt einen Überblick, wie die Funktionen benutzt werden und wie ein Arbeitsablauf in Continuus aussieht.

Diese Demo ist auf der folgenden Seite im Internet zu sehen:

When the build is complete, Rob tests it by simply double-clicking on the GDIDEMO.EXE object in the project view.

Rob doesn't have to leave the CM project view to test the new products of the build. If he has further changes to make, he selects the code object and is back in his code editor. Continuus/CM helps increase productivity by integrating the tools developers need. Rob tests the executable and it correctly generates the new colors. With a successful build and unit test of the new code, Rob is ready to check in his changes. [part 18]

When Rob selects Check In, the system notifies him of the parallel version that was already checked in by Steve. (Remember we checked in Steve's changes from the UNIX platform.) Steve's code is now in the "integrate" state which means it is non-writable and is available for Rob to merge with his code. Since both code modules are intended for the same release, it is natural that Rob perform the merge at this point. With Continuus merges happen naturally during the development process, rather than being held until the end of the development cycle. [part 19]

The system brings up the merge screen, which provides two capabilities: automated or interactive merge. Rob chooses to let the system automatically merge the code, and bring up the interactive merge tool if there are conflicts. The merge succeeds (since there are no conflicts) and the newly merged version appears in Rob's project view. Of course the merged version is writable (since it has not been tested and checked into the "integrate" state. Rob rebuilds the executable and successfully unit tests. To let Susan know that this object resolves Rob's assigned task, Rob uses the integrated PT functions to "associate" his code to his assigned change request, as he checks in the merged code.

Since Susan knows which code objects resolve particular change requests, she can build versions of the product based on these objects and eliminate late night calls to developers to determine appropriate versions of source code for builds. If Rob wants to view the history of the merged DRAW.C module, he can select the History View from the objects drop-down menu. [part 20]

Anyone using Continuus/CM can easily look at the history of a code object by choosing "Show History" from the code object's drop-down menu. The "History View" provides a clear picture of the change history of an object. It is easy to find out who has made changes to objects and whether required merging has been performed. With Continuus/CM, you won't need to track down the trail of changes from directory to directory, from version to version. After confirming all the changes are included in the final checked-in version, Rob is done with his work. Now we can join Susan the build manager as she integrates the requested changes into the new release. [part 21]

Let's look at the benefits that build managers receive from Continuus/CM and PT. Continuus/CM project views are consistent even when you change roles. This makes it easy for team members that have multiple roles in a project. Susan can also move from project to project easily and see the new and existing code for all of the projects under her control as build manager. Susan is working on several projects, including the new demo project, bug fixes, and a one-off for a special client fix. Susan, once again, is focused on the integration version of the project. To bring in the latest code changes, Susan updates or "reconfigures" this project.

The reconfigure operation uses a set of built-in, user-configurable rules and a set of simple attributes that are set on the project. For the integration project, the attributes will cause the reconfigure to update the project with the latest object version checked into the "integrate" state. The integration project is used for integration level testing and creation of "bleeding edge" software build products for developers to share. It is not a stable test area, however, because Susan cannot separate the changes that she needs to test from other developer changes she wishes to test at a future time. Later we'll show you how Susan can configure a stable test area using the "SQA" state. [part 22]

Four new code object versions were brought into the "integrate" project area by the reconfigure process. As we pointed out earlier, whenever an object is moved to the next state in the workflow, the color of the object changes, so its easy to see what has been updated during the reconfigure operation.

Susan does not need to know in advance which code was checked in to resolve the change requests for the new release of the demo. She can use the integrated problem tracking system to determine which of the updated code modules are associated with the change requests to change the speed and colors of the demo, without interrupting individual developers. All the information she needs is right at her fingertips. [part 23]

With integrated Continuus/CM and PT, Susan can browse the change requests for the demo project, see the associated code objects, and view the entire code object history. She'll use the Associated Task View to determine which code modules are checked in for the demo project. Susan determines that the merged "henning1" version of DRAW.C contains the fixes for both change requests she wishes to include in the next release. Since the integration version of the project has a number of other developer changes that Susan does not wish to test, she will now check the merged version of DRAW.C into the next state in the workflow, the "SQA" state, to allow her to configure a stable test area. Susan could check the code in using the check-in feature that is integrated into the Associated Task View, but we wanted to show you you're able to perform all Continuus/CM operations from the command line as well. Susan opens a MS-DOS prompt to check-in the code. [part 24]

There are times when a command line interface is desirable. With Continuus/CM you have the choice of working from the visual interface or the command line. Role based security is still enforced at the command line. Susan accomplishes a command line check in of the DRAW.C code module that was created when developer Rob merged his and Steve's changes that contained all the changes requested for the new demo. Now, how does Susan use the "SQA" promoted code in a stable test area to test and create the new release? Susan simply focuses on the "SQA" version of the project and uses reconfigure to bring in the newly promoted code. [part 25]

By providing an "SQA" project area, Continuus provides a stable test area where build managers can test just the code modules they desire. In this example, it gives Susan a place to test just the new DRAW.C module, with all of the other code from the previous baseline of the demo. Having an "SQA" area also allows build managers to continue to update the "integrate" project area to allow team members to share the latest code without affecting "SQA" builds. Only team members with the build manager role can move an object from the "integrate" to the "SQA" state. The "SQA" project versions have their attributes set so that only objects in the "SQA" or released state can be brought into the project during a reconfigure operation. Therefore, this is a stable test area because developers cannot directly effect the project configuration unless a build manager moves their code to the "SQA" state. Notice also that with Continuus, freeze periods are not needed when build managers perform integrations or "SQA" testing.

Developers can continue checking in changes and sharing products from the nightly integration builds, while Susan prepares the new release in the "SQA" project. After the reconfigure updates the "SQA" area with the merged DRAW.C module, Susan can build the "SQA" version of the new demo insulated from any other code changes that developers have checked in. [part 26]

Susan uses the ObjectMake build utility to create the new executable.

Susan's build is complete and now she can test the new executable. The code changes are successful. The demo runs faster and has lots of color. If further work is required ,Susan can bring the PT system up while in the CM project view and add notations or additional change requests. When she is satisfied with the final products Susan is ready to prepare the release of the new demo. [part 27]

With the final code tested, the "SQA" area becomes the next release. With integrated project views and the Continuus project workflow, you can move through the complete project flow from a single graphical interface. Susan finalizes the new demo for shipment by editing the project level object to change the version number from "SQA" to "2.0", and then checks in the entire project configuration with a single mouse click. [part 28]

Now the project object is in the released state and the project can no longer be reconfigured. The code objects, make file, and executable are forever frozen and are available for delivery to customers, or to form a basis for new development.

To make this process repeatable, Susan simply creates a new working version of the project from the released version and configures the project attributes so that it becomes the new "SQA" version for future release preparation. With Continuus/CM and Continuus/PT you get a continuous process of repeatable practices to manage change in your software development projects. [part 29]

7. Zusammenfassung/ Ausblick

Continuus/CM ist ein Konfigurationsmanagement Tool, was aber weit über die Möglichkeiten einer Versionsverwaltung hinausgeht.

Dadurch, daß man in CCM Tasks, als Aufgaben, den einzelnen Entwicklern zuweisen kann und die Entwickler dann mit diesen Tasks arbeiten, und alle Dokumente und Verzeichnisse, an denen gearbeitet wurde mit dem Task verbunden wurden, hat man es viel einfacher die zusammengehörigen Dokumente und Verzeichnisse zu finden und für eine bestimmte Release zu verwenden, indem man einfach nur den entsprechenden Task auswählt.

Continuus/CM ist das ideale Tool für große Teams, große Anwendungen oder viele Versionen, weil damit die Koordination im Team entscheident verbessert wird.

Ein weiterer Vorteil, der für Continuus spricht ist das neue Programm,  was jetzt die Möglichkeit bietet, das das Team über das Internet miteinander arbeitet und trotzdem die Vorteile von Continuus/CM genießen kann.

Continuus/WebSynergy ist das erste Change Management Tool für Web Sides und Intranets. Continuus/WebSynergy unterstützt den gesamten Entwicklungsprozeß: Entwicklung, Management, Freigabe und Verteilung aller Art von Web-Inhalten und -Software.

Continuus/WebSynergy bietet erstmals unternehmensweite Unterstützung für das Management sowohl von Web-Inhalten als auch für die Softwareentwicklungfür das Internet. Das neue Produkt ergänzt die bewährte Change Management Lösung von Continuus und macht diese somit Web-fähig.
 
 

Literaturverzeichnis