View
1
Download
0
Category
Preview:
Citation preview
Vorlesung „Softwaretechnologie“Exkurs zu Kapitel 2: Software Configuration Management R O O T Su s u ap te So t a e Co gu at o a age e t
Exkurs: Clear Case
Dieser Foliensatz enthält Details zu ClearCase. Ab WS 2009 sind die hier enthaltenen Folien nicht mehr Teil des Prüfungsstoffes sondern
lediglich Vertiefung für Interessierte.
ClearCase® Architektur
Anwendungen mit Dateizugriff
MultiversionFile System
Dateisystem von Windowns / UNIX
y
ClearCase MVFS
Cl C VOBNicht-versionierte
Dateien
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 2 R O O T S
ClearCase VOBDateien
Virtuelles Dateien System (Virtual File System) beiClearCase
foo c
src
VOBfoo.h foo.c
src
emacsmakegcc
foo c foo h
gccgrepeclipse
foo.c foo.h
Software-entwicklungs-
werkzeugeVersioned Object Base (VOB)
Virtual File System bei ClearCase
foo c
src
foo.h foo.c
VOB
src
emacsmakegcc
WINDOWS
/UNIX
MVFS
foo c foo h
gccgrepeclipse
UNIX S
foo.c foo.h
Software-Versioned Object Base (VOB)entwicklungs-
werkzeuge
ClearCase VOB (Versioned Object Base)
Sicheres Repository aufbauend auf objektorientierter
0
1Release 1
bugfix
aufbauend auf objektorientierter Datenbank
Zugriff nur mit ClearCase möglich
0
1
20
1
develop
bugfix Speichert alle versionierten Daten
Source code Directories 0
1
3
4Release 2
1
2
Directories Binaries Wer hat was, wann, warum getan?
2Release 2
4 Gemeinsamer Datenzugriff Beliebig viele VOBs im Netzwerk
mit beliebig vielen Elementenmit beliebig vielen Elementen Verteile Datenbank
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 5 R O O T S
SCM: Das Fundament des EntwicklungsprozessesEntwicklungsprozesses
Analysis Entwurf Implementierung Test Wartung
Software Configuration Management
V i C l B ild MVersion Control Build Management
Workspace Management Process Control
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 6 R O O T S
Workspace Management (1)
Einrichtung und Pflege einer persönlichen Arbeitsumgebung d h Z t ll d b öti t Obj kt d.h. Zusammenstellung der benötigten Objekte
Sources, Binaries, ... ... für die entsprechende Aufgabe
Bugfixing, Neu- / Weiterentwicklung, …
Ansätze Ansätze unconstrained:
keine wohldefinierte Arbeitsumgebung erforderlich hierarchical sub-environments:
vorgegebene Arbeitsbereiche können kopiert und lokal geändert werden change sets: change sets:
Grundversion eines Objekts + Menge von Änderungen dieses Objekts rule-based environments:
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 7 R O O T S
benötigte Objekte werden über Regeln definiert
Workspace Management: Hierarchical Sub-EnvironmentsSub Environments
Prinzip dif
Kind 4 = Vater 2
Vater 1
copy - modify - merge
Nachteile
Kind 1 Kind 2 Kind 3 Kind 5 Kind 6
zur Integration von Änderungen muß gemeinsamer "Vater" vorhanden sein; dieser wird dann unwiderruflich geändert
paarweiser Austausch zwischen "Kindern" nicht direkt möglich paarweiser Austausch zwischen Kindern nicht direkt möglich Kombination von Teilaspekten einzelner "Kinder" nicht möglich informative globale Sicht geht durch Isolation der Arbeitsumgebungen
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 8 R O O T S
verloren
Workspace Management: Change Sets
Gruppierung von aufeinander aufbauenden Versionen B B fi z.B. Bugfixes wird oft zur Organisation einer Entwicklungslinie benutzt am Ende des Entwicklungsprozesses werden die kumulativen g p
Veränderungen als neue Versionen herausgebracht (patch bundles)
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 9 R O O T S
Workspace Management: Rule-Based WorkspacesWorkspaces
Prinzip: regeldefinierte Auswahl von Objekten / Versionen
Statische Regelauswertung Auswertung der Regeln zum Zeitpunkt des Arbeitsbeginns Auswertung der Regeln zum Zeitpunkt des Arbeitsbeginns ausgewählte Versionen werden in den privaten Arbeitsbereich kopiert der Benutzer muss am Ende explizit die Synchronisation anstoßen
Dynamische Regelauswertung Auswertung der Regeln zum Zeitpunkt des Objektzugriffs Auswertung der Regeln zum Zeitpunkt des Objektzugriffs
ClearCase
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 10 R O O T S
Views in ClearCase (1)
Configuration Specification Si htd fi iti d h b t ifi h R l Sichtdefinition durch benutzerspezifische Regelmenge agieren als Filter Auswahl einer bestimmten Objektversion verhindert Zugriff auf alle j g
anderen Versionen des selben Objekts Projektion der ausgewählten Struktur und der spezifizierten Versionen als
normaler Verzeichnisbaum nur für den privaten Gebrauch gedacht
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 11 R O O T S
ClearCase Views
Transparentes Arbeiten mit verschiedenen Releases des l i h P j ktgleichen Projekts “Zeig mir Version 2.20” Eine Art Filter
View
Eine Art Filter
Arbeiten in Echtzeit
Sofortiger Zugriff auf den gesamten Datenbestandgesamten Datenbestand
Downloads finden nur statt, wenn es erforderlich ist (ein Zugriff) kein komplettes Kopieren!
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 12 R O O T S
kein komplettes Kopieren!
ClearCase Views
Alle Objekte im VOB sind schreibgeschütztCh k O t Check-Out Ein Entwickler muß ein check-out-Kommando absetzen, um ein Objekt
verändern zu können Dieses wird dann in den privaten Speicherbereich kopiert, ist aber noch
unter dem ursprünglichen Namen und Pfad ansprechbar Check-In Check-In
Das check-in-Kommando erzeugt eine neue Objektversion im VOB und löscht die private Kopie
Locking: Nur derjenige Entwickler, der das check-out-Kommando abgesetzt hat, darf die neue Objektversion auch wieder einchecken
Variante: „unreserved check-out“: „first check-in wins“; alle anderen müssen mergen
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 13 R O O T S
ClearCase Views
Schnelles und einfaches Wechseln
Einfacher Weg, viele Aufgaben zu
src
f einfaches Wechseln zwischen verschiedenen Aufgaben
Aufgaben zu managen
E l bt d i h
foo.h foo.c
u gabe
Kontrolle von öffentlichen und
Erlaubt dynamisches Teilen der Arbeit
öffentlichen und privaten Tätigkeiten
srcsrc
foo.c foo.hfoo.h
ClearCase Views: Private Storage
ViewView
Lokale Kopien ermöglichen Lokale Kopien ermöglichen das Arbeiten ohne Netzzugriff
Synchronisation mit der Datenbank erfolgt automatisch
Merging erfolgt automatisch Merging erfolgt automatisch
ClearCase: Verteile Entwicklung
Paralleles Entwickeln mit geographisch verteilten Projekt-Teams
Automatische Updates und Kopien der VOBsKopien der VOBs mit oder ohne Netzzugriff
Nur ein Team hat "Mastership“ pro branch
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 16 R O O T S
ClearCase® Workspace Management: Multi Site Parallel Development
foo c foo.c
\europe\america1
foo.c\europe\america
1
foo.c
00 200 2
11 3 11 3
3
22
3
2 2
3 3
SCM: Das Fundament des EntwicklungsprozessesEntwicklungsprozesses
Analysis Entwurf Implementierung Test Wartung
Software Configuration Management
V i C l B ild MVersion Control Build Management
Workspace Management Process Control
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 18 R O O T S
Versionskontrolle: Branching (1)
„Branching Graph Model“ Darstellung der wichtigsten arc c Darstellung der wichtigsten
Entwicklungslinien und Change Sets
symbolische Namen zum besseren
1
21
arc.c
V1_maintenanceV1
i bug=239 symbolische Namen zum besseren Verständnis und einfacheren Referenzieren
jeder Zweig (Branch) hat
31
2
3
1
2
new_gui bug 239
bug=248
bug=267V1.1
jeder Zweig (Branch) hat zusätzliche administrative Annotationen b li h N
7
134
5
bug=268
bug=301V1.2
symbolischer Name Verweis auf Abspaltungspunkt Kommentare
18V2
...
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 19 R O O T S
Versionskontrolle: Branching (2)
Uneingeschränktes branchingwird unterstützt
Release 1.0
d u te stüt t
Automatisches branching, wann
\b fi\d l
0immer es nötig ist
Jedes Mitglied hat einen
0
\bugfix
0
\development1
Jedes Mitglied hat einen isolierten Arbeitsbereich
0
1
0
1
2 Verschiedene Arbeitsbereiche für verschiedene Aktivitäten
11
Erlaubt parallele und durchgängige Entwicklung
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 20 R O O T S
g g g g
Versionskontrolle: Merging (1)
Isolierte Arbeitsbereiche werden integriertteg e t
Fördert und schafft Transparenz Release 1.0
Ein Merge Manager unterstützt automatisches Merging und hilft \b fi\d l
0automatisches Merging und hilft beim Auflösen eventueller Konflikte
0
\bugfix
0
\development1
Merging ist in alle Richtungen möglich
0
1
0
1
2
3möglich 11
4
3
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 21 R O O T S
4
Versionskontrolle: Merging (2)
Problemskizze i f l t t ti h
Basisversion
merging erfolgt automatisch, falls gemeinsamer Vorfahre der zwei Dateien bekannt ist
...x=0...
...x=0...
...x=1...
Version A Version Bx=1
Idee Änderungen übernehmen
...???...
Experimentelle Resultate In ca 90% der Fälle konnte das Zusammenführen ohne Rückfragen In ca. 90% der Fälle konnte das Zusammenführen ohne Rückfragen
durchgeführt werden. Ca. 1% der automatischen Zusammenführungen war fehlerhaft, was meist
beim Übersetzen entdeckt wurde (Syntaxfehler)
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 22 R O O T S
beim Übersetzen entdeckt wurde (Syntaxfehler)
ClearCase® Versionskontrolle: Branching & Merging& Merging
Isoliert riskante Entwicklungen und Tests
Release 1.0 Stellt sicher, dass einmal behobene Fehler
für immer verschwinden
0 Merge-Utility findet noch nicht gemergteDateien \bugfix\development
1Dateien
Änderungen an Releases werden 0
1
0
1
2g
transparent
R l f hi d Pl ttf 11
4
3 Releases auf verschiedenen Plattformen werden ermöglicht
4 Integrationsaufwand wird drastisch reduziert
Versionierung von Ordnern
/usr/src/proj /usr/src/proj
gui_src gui_doc gui
schedulesrc doc
schedule
arc.c zbuf.c plan.docp
arc c zbuf c plan doc
Obige Änderung entspricht einer neuen Version des Ordners /usr/src/proj/
arc.c zbuf.c plan.doc
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 24 R O O T S
/usr/src/proj/
Versionskontrolle (3): ErweiterungsmöglichkeitenErweiterungsmöglichkeiten
Labels b li h N arc c arc doc
(hyperlink)
symbolische Namen Attribute
zusätzliche Anmerkungen
1
2
arc.c
change_req=218(attribute)
1
2
arc.doc
RLS1
design_for
zusätzliche Anmerkungen Hyperlinks
Beziehungen
3RLS1(label)
3 RLS2
Trigger ECA-Regeln
Change Sets
7
Change Sets Annotationen (auf Code-Ebene) Namespacesa espaces ...
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 25 R O O T S
ClearCase Baselining
h c rcminicalc.dsw
hminicalc.h
cminicalc.cpp
rcminicalc.rc
Release 1 Release 1 Release 1 Release 1
0 0 0 0
Release 2
Release 21 1 1 1
Release 2
2
3
2 2
3Release 2
3
4
3
J d V i i h lb d R l k i4 Jede Version innerhalb des Release kann einglobales Label (z.B. "Release 1") erhalten
ClearCase® Übersicht
Version Control Build ManagementBuild Management
Workspace Management Process Controlp g
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 28 R O O T S
Build Management: Mit herkömmlichen Werkzeugen (make)Werkzeugen (make)
Keine automatisierte Abhängigkeitsanalyse Abhä i k it d B t ll b h i b ( k fil ) Abhängigkeiten werden vom Benutzer manuell beschrieben (makefile) Das ist aber in einer sich dynamisch ändernden Umgebung sehr aufwendig
und fehleranfällig
Kein „Bill of materials“ unklar ob zwei abgeleitete Produkte gleichen Namens (foo o) wirklich unklar ob zwei abgeleitete Produkte gleichen Namens (foo.o) wirklich
gleich sind, da nicht klar ist, ob sie auch aus den gleichen „Zutaten“ und nach der gleichen „Rezeptur“ erstellt wurden
Kein „Binary sharing“ Das "normale" Make weiß nichts darüber, dass ein Kollege evtl. ein , g
aufwendig zu erstellendes abgeleitetes Objekt schon erzeugt hat
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 29 R O O T S
Build Management: Mit ClearCase
Verwaltung von Informationen zum reproduzierbaren Erstellen von abgeleiteten Objektenabge e tete Obje te
Technische Grundlage Durch das VFS ist es möglich, die I/O-Zugriffe vom Compiler oder anderen
W k f ll b t ili t Obj kt f d t k lliWerkzeugen auf alle beteiligten Objekte erfassen und protokollieren zu lassen.
clearmake erledigt diese Aufgabe Protokollierung der benötigte Daten (Auditing) Bestandsliste (bill-of-
materials) Korrekte Versionen aller Quell Dateien und anderer beteiligter Objekte Korrekte Versionen aller Quell-Dateien und anderer beteiligter Objekte Namen und Versionen der verwendeten Werkzeuge benutzte Parametereinstellungen
Resultierende nützliche Eigenschaften Abgeleitete Objekte können von verschiedenen Benutzern genutzt werden
(binary sharing)(binary sharing) Nur die notwendigsten Operationen zum Erstellen eines abgeleiteten
Objekts müssen durchgeführt werden (minimal rebuilding)
Build Management: Lösung mit ClearCase
clearmakeaudit on audit offinvoke build script additional
f
/bin/cc -g parse.c
information
view
Config Record
parse.c@@/main/17parse.h@@/main/7lex h@@/main/93
File System I/O Audit
lex.h@@/main/93parse.o@@12-Jul----------------HP/UX 9.0.3/bin/cc -g parse.c
Bill-of-material = „Stückliste“der „Zutaten“ für die Herstellung
VOB repository
dieses abgeleiteten Objektes.
ClearCase® Build und Release ManagementManagement
Build Maintenance A t ti h E k Abhä i k it Automatisches Erkennen von Abhängigkeiten Stellt sicher, dass ein Build die richtigen Versionen einzelner Elemente
beinhaltet Konfigurationsprofile bestimmen exakt jede Version der benutzten
Elemente
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 32 R O O T S
ClearCase® Build und Release ManagementManagement
Build Auditing (Protokollierung)
bar.c foo.c
Reproduzierbarkeit von builds durch Anfertigen von “Stücklisten”
Target foo.o built on host ‘falcon’ by arthurReference Time 4-June-2001, 1:30:42View was falcon:/home/falcon/arthur/myview/usr/vob/src@@/main/12/usr/vob/src/foo.c@@/main/bugfix/4/ / / / / //usr/vob/src/foo.h@@/main/17/usr/vob/src/foo.h@@main/9Build Script:cc -g -o foo foo.c
New Build
projectproject
bin src
foo c foo.cfoo.o
VIEWfoo.c bar.cfoo.o
Private StorageUser ‘arthur’
W
ClearCase® Build und Release Management bar c foo cfoo oManagement
Build Avoidance (Vermeidung)
bar.c foo.cfoo.o
Entwickler können “abgeleitete Objekte” teilen
Target foo.o built on host ‘falcon’ by fordReference Time 5-June-2001 9:14:42Reference Time 5-June-2001, 9:14:42View was falcon:/home/falcon/ford/myview/usr/vob/src@@/main/12/usr/vob/src/foo.c@@/main/bugfix/4/usr/vob/src/foo h@@/main/17/usr/vob/src/foo.h@@/main/17/usr/vob/src/foo.h@@main/9Build Script:cc -g -o foo foo.c
New Build
project
bin src
foo.c bar cfoo ofoo.c
foo.oVIEW
Nicht erforderlich
bar.cfoo.o
Private StorageUser ‘ford’
Wfoo.c neu zu kompilieren
ClearCase® Build And Release Management
VOB Server Hosts Build Performance E ö li ht ll l d
Management
HP DEC Sun HP
Ermöglicht parallele und verteilte builds über das Netzwerk (UNIX)
Sun SGI IBM NTTeil-Builds können verteilt werden
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 35 R O O T S
ClearCase® Build und Release Management: Zusammenfassung
Build Maintenance A t ti h E k Abhä i k it Automatisches Erkennen von Abhängigkeiten
Build Auditing (Protokollierung)g ( g) Reproduzierbarkeit von builds durch Anfertigen von “Stücklisten”
Build Avoidance (Vermeidung) Ermöglicht das Teilen von “abgeleiteten Objekten" zwischen Entwicklern
Build Performance Ermöglicht parallele und verteilte builds
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 36 R O O T S
ClearCase® Übersicht
Version Control Build Management
Workspace Management Process ControlProcess Controlp g
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 37 R O O T S
Process Control
Entwicklungsprozeß umfaßt Analyse, Design, Implementierung und Wartung des Software-ProduktsWartung des Software Produkts
SCM ist nur ein Teil in diesem Prozeß neben der Eingrenzung von Problemen, der Definition von Maßnahmen, dem Erstellen von Zeitplänen,p , dem (automatischen) Testen, dem Messen von Software-Eigenschaften und anderen Aufgaben und anderen Aufgaben.
Geeignete Werkzeuge zur Automatisierung von Entwicklungs-P i d "W kfl MProzessen sind sog. "Workflow Manager„.
Deren grundlegendes Konzept ist Action-Response, d.h. die Bearbeitung von Teilaufgaben kann andere Teilaufgaben beeinflussen
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 38 R O O T S
oder anstoßen.
Die Lösung: Unified Change Management
Akti ität Aktivitäten - werden Aktivitäten
Activity
definiert um das Projekt voranzubringenActivity
ActivityActivity
voranzubringen
Artefakte
Artefakte - Dateien die äh d d P j kt während des Projekts
angelegt/verändert werden
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 39 R O O T S
werden
Die Lösung: Unified Change Management
E t i klEntwickler IntegratorProjekt Manager
Anmelden am Projekt erzeugen
Baseline definieren
Integration
B li
Anmelden am Projekt
Arbeiten an Baseline definieren
Richtlinien
Baseline erzeugen
Baselinegüte
Arbeiten an Aktivitäten
Richtlinien festlegen Baselinegüte
vergeben Arbeitsumgebung
aktualisieren
Aktivitäten abliefern
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 40 R O O T S
UCM: Verbindung zwischen Aktivitäten und Artefakten
ClearQuest: Aktivitäten
und Artefakten
Verwaltung der Aktivitäten
Request Priority OwnerSpecial Promo 1 TerryBug 527 2 Sandy
Ch S t
Aktivitäten
Cl C A t f kt
Bug 527 2 SandyAdd GUI button 2 Kim
Change SetSpecial Promo
a html V5
ClearCase: Artefakte
V lt d a.html V5c.xml V3b.jpg V8
Verwaltung der Artefakte
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 41 R O O T S
ClearCase® Zusammenfassung
Version Control Build ManagementVersion ControlFull Branching & LabelingAll File System ElementsDirectories
Build Managementmakefile compatibleAutomatic Dependency MgmtBuild Auditing - Config RecordsDirectories
Graphical Merge & CompareConversion Utilities
Build Auditing Config RecordsParallel, Distributed BuildingBinary Sharing
W k M t P C t lWorkspace ManagementRule-based ConfigurationsDynamic EvaluationTransparent Access
Process ControlAttributesHyperlinksPre Event Post Event TriggersTransparent Access
ScalableFully Distributed
Pre-Event, Post-Event TriggersLocks & PermissionsCompletely Customizable
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 42 R O O T S
ClearCase Summary
ClearCase Pros ClearCase Cons
Industrial strength Excellent merge tools
Very expensive Heavyweight server and client
Proven reliability Scales up well Good GUI on Windows
Very steep learning curve High administration burden Server communication over a Good GUI on Windows Server communication over a
high latency link is SLOW All merges are server based
You can't merge or diff withoutconnectivity to the servers
Merges over high latency links are SLOWare SLOW
You need to do many thingsthe ClearCase way
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 43 R O O T S
Weak GUI on Unix platforms
Zusammenfassung: SCM De Luxe
Virtuelles Dateisystem T d D t h lt Transparenz der Datenhaltung
Regelbasierte Konfiguration des Arbeitsbereiches Flexibilität Flexibilität
Dynamische Regelauswertung Aktualität
Automatisches Merging Geringer Integrationsaufwand
Build Management Build Management Reproduzierbare „build“-Ergebnisse, Effizienz durch „minimal rebuilding“
ECA-Regelng Workflow-Management
Verteilung, automatische Spielelung, verteiltes Building
© 2000-2009 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Exkurs „ClearCase“, Seite 44 R O O T S
Unterstützung für internationale Unternehmen
Recommended