Exkurs: Clear Case - sewiki.iai.uni-bonn.de · ClearCase VOB (Versioned Object Base) Sicheres...

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


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


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:


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


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)


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


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


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!


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


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


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


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

...


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


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


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)


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


/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 ...


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


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


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


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


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


ClearCase® Übersicht

Version Control Build Management

Workspace Management Process ControlProcess Controlp g


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


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


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


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


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


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


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


Unterstützung für internationale Unternehmen

Exkurs: Clear Case - sewiki.iai.uni-bonn.de · ClearCase VOB (Versioned Object Base) Sicheres...

Documents

Transcript of Exkurs: Clear Case - sewiki.iai.uni-bonn.de · ClearCase VOB (Versioned Object Base) Sicheres...