Kapitel 2 Software Configuration Management

Transcription

Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009/10
009/ 0
ROOTS
Kapitel 2
Software Configuration Management
Stand: 15.Oktober 2009
Probleme während der
Softwareentwicklung
Viele Anforderungen
g
Viele Änderungen
g
Viele Versionen
Koordination erforderlich!
Viele Projekte
Viele Arbeitsumgebungen
Viele Entwickler
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“ (SWT)
Seite 2-2
ROOTS
Warum Software Configuration Management?
Problem
Sie möchten
 Software
Software-Entwicklung
Entwicklung ist nicht linear
 Man macht Programmierfehler
 Man trifft falsche Entwurfsentscheidungen
 wissen, was Sie wann
warum getan haben
 zu alter Version
zurückgehen
g
 Software-Entwicklung ist Teamarbeit
 Sie
Si und
d andere
d
arbeiten
b it parallel
ll l
 ... auf vielen verschiedenen Dateien
 wissen, wer was wann
warum getan hat
 Änderungen gemeinsam
nutzen
 Verwaltung verschiedener Versionen
 Kunde erhält stabile Version, während
Entwicklung weitergeht
 Bugfixes müssen in alle Versionen
integriert werden
 Verschiedene Kunden erhalten
verschiedene Varianten des Produkts
© 2000-2009 Dr. G. Kniesel
 parallele Entwicklung und
I t
Integration
ti kontrollieren
k t lli
 Varianten kontrollieren
Seite 2-3
ROOTS
SCM: Das Fundament des
Entwicklungsprozesses
Analyse
Entwurff
Implementierung
Test
Wartung
Software Configuration
g
Management
g
((SCM))
Sammeln und Verwalten von Informationen
um Software zu erzeugen,
erzeugen zu warten und zu erweitern.
erweitern
 Quellcode
Q ll d
 Bitmaps
Bit
& JPEGs
JPEG
 Anforderungen
A f d
 Binärcode
 HTML/XML Dateien
 Entwürfe
 Build Skripte
 CGI,
CGI Javascript
 Test Skripte
 Konfigurationen
 CSS
 Dokumentation
SCM Features
 Managt alle Komponenten des Projekts in einem „Repository“
 Keine
K i redundanten
d d t K
Kopien
i
 Sicher
 Macht Unterschiede zwischen Versionen sichtbar
 „Was hat sich verglichen mit der gestrigen Version verändert?“
 Erlaubt Änderungen zu identifizieren, auszuwerten, zu diskutieren (!)
und
d sie
i schließlich
hli ßli h anzunehmen
h
oder
d zu verwerfen.
f
 Verwaltet Metadaten: Wer hat was, wann, warum und wo getan?
 „Wer
Wer hat was in Klasse X geändert?“
geändert?
 „Warum hat er es verändert?“
 Ermöglicht die Wiederherstellung voriger Zustände
 Vollständig oder selektiv
 Erlaubt die Definition von Referenzversionen (Tags)
 Letzte konsistente Version
 Milestones
 Releases
SCM Aktivitäten

“Configuration item identification “
 Bestimmung
B ti
d per SCM zu verwaltenden
der
lt d Artefakte
A t f kt
 “Branch management”
 Verwaltung
V
l
verschiedener
hi d
V i
Versionen,
di später
die
ä integriert
i
i werden
d sollen
ll
 “Variant management”
 Verwaltung von Versionen die nebeneinander existieren sollen
 “Change management“
 Erfassung, Genemigung und Nachverfolgung von Änderungswünschen
Ä
 “Promotion”
 Erzeugung von Versionen für andere Entwickler
 “Release”
 Erzeugung von Versionen für Kunden bzw. Benutzer
© 2000-2009 Dr. G. Kniesel
Seite 2-6
ROOTS
SCM Grundbegriffe
 Arbeitskopie
 Unter Kontrolle eines Programmierers
 Nur für ihn sichtbar
Promotion
 Repository
 Zentrales Verzeichnis aller “promoteten”
Versionen
 Von allen Teammitgliedern benutzt
Zentrales
Archiv
Release
 Produkt
 Externe, veröffentlichte Version
Foo’95
Foo’98
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
ROOTS
Grundlegende Ansätze
Vault Model
Standard Repository
Virtual File System
Arbeitsumgebung und Repository
Arbeitsumgebung
g
g ((“Sandbox”))
Repository
p
y
 Enthält nur die aktuell relevante
 Enthält alle Versionen (incl.
Version eines jeden Artefaktes
aus d
dem R
Repository
it
 die Aktuellste
 die letzte Funktionierende
 ...
“branches”) eines jeden
A t f kt
Artefaktes,
d unter
das
t SCMSCM
Kontrolle stehen
src
foo.c
src
foo.c
foo.h
foo.h
Allgemeines Szenario
Entwicklungswerkzeuge
k
/
...
...
Entwickler
...
Arbeitsumgebung
SCM-Tools
Repository
 Frage:
F
Wie
Wi interagieren
i t
i
obige
bi B
Beteiligte?
t ili t ?
 Muss der Entwickler selbst seine Arbeitsumgebungen verwalten oder kann
das ein SCM-Tool (größtenteils) automatisch?
 Ist immer eine lokale Kopie in einer Arbeitsumgebung erforderlich oder
können Entwicklungswerkzeuge direkt auf das Repository zugreifen?
SCM-Ansätze: „Vault Model“
k
/
...
...
Entwickler
...
Arbeitsumgebung
Repository
SCM-Tools
 Idee
 Dateien kopieren: Arbeitsumgebung   Repository
 Probleme
 Evtl. viele private Kopien in Arbeitsumgebungen außerhalb des Repository
 Entwickler arbeitet evtl. auf veralteten Dateien
 Möglicher Datenverlust durch gleichzeitige oder abgebrochene Updates
© 2000-2009 Dr. G. Kniesel
Seite 2-11
ROOTS
SCM-Ansätze: "Standard Repository API"
Entwicklungs-Werkzeuge
...
API
/
Entwickler
...
...
...
Repository
Dateien in Arbeitsumgebung (‚sandbox‘)
 Idee
 Alle
All E
t i kl
k
greifen
if di
direkt
kt auff d
das R
Repository
it
zu,
über eine standardisierte Schnittstelle
 Problem
 Alle Werkzeuge müssen angepasst werden -- bei jeder Änderung des
Standards!
SCM-Ansätze: "Virtual File System" (VFS)
Entwicklungs-Werkzeuge
...
/
Entwickler
...
...
Repository
...
Arbeitsumgebung
 Idee
 Abfangen von I/O-Operationen des Betriebssystems (open, read, write)
und Umleiten zum Repository
p
y
 Vorteile
 Transparenz, da das Repository als normaler Verzeichnisbaum erscheint
 nahtlose Integration bestehender Standardsoftware
 Benutzer kann wie gewohnt arbeiten
© 2000-2009 Dr. G. Kniesel
Seite 2-13
ROOTS
Verbreitete SCM-Tools die obige Ansätze
umsetzen
 CVS (simpel, kostenlos)
 Repository = Dateisystem
 Versionierung von Dateien
 Hauptsächlich Textdateien, Binärdateien nur eingeschränkt
 Repository = Datenbank  Transaktionsunterstützung
 Versionierung von Dateien und Ordnern  Umbenennungen
 Text und Binärdatein
 Komfortable graphische Benutzeroberflächen
mächttiger
 SVN (besser, kostenlos)
 ClearCase (high-end, kommerziell)
 Virtuelles Dateisystem basierend auf Datenbank
 Alle Eigenschaften von SVN plus...
 Dynamische Sichten auf Repository
 „Derived Object Sharing“
 Multiple Server, Replikation

© 2000-2009 Dr. G. Kniesel
Prozessmodelierung
Seite 2-14
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 2: Konfigurationsmanagement
o gu at o s a age e t mitt Sub
Subversion
e so
Arbeiten mit SVN (und CVS)
Check-in und Check-out
Commit und Update
Synchronisierung
Konfliktbeurteilung durch Dateivergleich
Manuelle Konfliktauflösung
ROOTS
CVS und SVN: “Vault Model”
CVS / SVN
Arbeitskopie
p
Repository
CVS / SVN
Arbeitskopie
 Prinzip
 Ein
Ei zentrales
t l Sammelbecken
S
lb k („Repository“)
(R
it “) aller
ll relevanter
l
t D
Dateien
t i
 Nur „offizielle“ Versionen
 Viele private Arbeitsumgebungen („Sandbox“) mit Kopien von Dateien
 Auch temporäre, inkonsistente, unfertige, ... Versionen
© 2000-2009 Dr. G. Kniesel
Seite 2-16
ROOTS
CVS und SVN: Checkin und Checkout
CVS / SVN
Arbeitskopie
p
Checkout
CVS(Projekt)
/ SVN
Repository
Arbeitskopie
 Checkin
 Fügt
Fü t Projekt
P j kt dem
d
R
Repository
it
hi
hinzu
 Checkout
 Erstellt eine Arbeitskopie des Projekts vom Repository
© 2000-2009 Dr. G. Kniesel
Seite 2-17
ROOTS
CVS und SVN: Commit und Update
Commit
CVS
/ SVN
(Dateien)
Arbeitskopie
p
Update
CVS / SVN
(Dateien)
Repository
Arbeitskopie
 Commit
 Transferiert
T
f i t vom Programmierer
P
i
geänderte
ä d t Dateien
D t i in
i d
das R
Repository
it
 Update
 Transferiert geänderte Dateien vom Repository in die Arbeitskopie
© 2000-2009 Dr. G. Kniesel
Seite 2-18
ROOTS
Check-In: Projekt unter Versionskontrolle
stellen
 Ausgangssituation
 Ein
Ei R
Repository
it
existiert
i ti t
 Ein Projekt existiert, wird aber noch nicht gemeinsam genutzt.
g / Promotion des Projektes
j
 Check-In / Sharing
 Das Projekt wird dem Repository hinzugefügt
 Es ist nun für alle Entwickler verfügbar die Zugriff auf das Repository
haben
Check-In / Sharing
Projekt X
Repository
Projekt X
Entwickler
https://svn.iai.uni-bonn.de/repos/IAI_Software/se/ swt-vorlesung/groupXX
Repository root
© 2000-2009 Dr. G. Kniesel
Projekt Pfad
Seite 2-19
ROOTS
Check-Out: Initialer Projektdownload
 Check-out eines Projektes
 Entwickler
E t i kl bekommen
b k
eine
i lokale
l k l A
Arbeitskopie
b it k i
 Von jetzt an können sie an dem Projekt arbeiten
pro Projekt
j
g
gemacht!
 Auschecken wird nur einmal p
 Neue Version aus Repository holen  siehe „Update“
Arbeitskopie
Projekt X
R
Repository
it
Entwickler A
Check out
Projekt X
Projekt X
Entwickler B
Arbeitskopie
© 2000-2009 Dr. G. Kniesel
Seite 2-20
ROOTS
Check-Out: Initialer Projektdownload
 Entwickler bekommt eine lokale Arbeitskopie eines Projektes
 Auschecken
A
h k wird
i d nur einmal
i
l pro P
Projekt
j kt gemacht!
ht!
 Neue Version aus Repository holen  siehe „Update“
Arbeitskopie von
Entwickler A
Check Out
Projekt im Repository
Check Out
Arbeitskopie von
Entwickler B
t0
t1
Commit: Änderungen in das Repository
übertragen
 Ausgangslage: Entwickler A hat seine Arbeitskopie geändert
 Commit
C
it
 Er fügt seine Änderungen dem Repository hinzu
 Mit einem „Commit Kommentar“
Kommentar teilt er dem Team mit was er warum
geändert hat: „NullPointer-Exception behoben, die auftrat wenn ...“
Arbeitskopie von
Entwickler A
Check Out
Commit
Check Out
Arbeitskopie von
Entwickler B
t0
t1
t2
Update: Neueste Änderungen vom
Repository übernehmen
 Ausgangslage: Repository hat sich geändert
 Entwickler
E t i kl B iistt sich
i h sicher(!),
i h (!) dass
d
er di
die Ä
Änderungen
d
üb
übernehmen
h
will
ill
 Update
 B aktualisiert seine Arbeitskopie mit dem aktuellen Zustand des Repository
 Problem
 Woher weiß der Entwickler, welche Änderungen er übernehmen soll?
 Besser: Zuerst „Synchronize“ benutzen!
Arbeitskopie von
Entwickler A
Check Out
Commit
/ Update
p
Check Out
Arbeitskopie von
Entwickler B
Update
/ Update
t0
t1
t2
t3
Konflikt?
Synchronisation: Versionsvergleich
 Vergleich des Projektes in Arbeitskopie mit Repository bezogen auf
Stand beim letzten Abgleich (check
(check-in
in / commit / check-out
check out / update)
 Automatisierter Vergleich aller Dateien im Projekt
 Automatisierter Vergleich einzelner Dateiinhalte
 Der Entwickler entscheidet selbst was aktuell ist
 ... und führt Updates oder Commits durch (eventuell selektiv)
Arbeitskopie von
Entwickler A
Check Out
Commit
/ Update
p
Check Out
Arbeitskopie von
Entwickler B
Gemeinsame
Bezugsversion
Update
/ Update
t0
t1
t2
t3
Konflikt?
“Synchronize View”: Gesamtübersicht
 Automatisierte Gesamtübersicht
 Vergleich
V l i h auff P
Projektebene:
j kt b
All
Alle D
Dateien
t i des
d Projektes
P j kt ((oder
d d
des
selektierten Ordners) werden verglichen
 Zeigt pro Datei ein- und ausgehende Änderungen sowie Konflikte durch
entsprechende Symbole
© 2000-2009 Dr. G. Kniesel
Seite 2-25
ROOTS
(lokale Änderung)
 Lokale Datei ist neuer als ihre Version im Repository
 Überschreibe Version im Repository
p
y mit lokaler Version
 Neue lokale Datei existiert nicht im Repository
+
 Füge Datei zum Repository hinzu
 Datei aus Repository wurde lokal gelöscht
(Ä
Änderung im
m Repositorry)
Ein
ngehende
e Änderung
Ausgehen
A
nde Änderrung
Symbole im „Synchronize View“
© 2000-2009 Dr. G. Kniesel
 Datei aus (nächster Version in) dem Repository löschen
 Datei im Repository ist neuer als ihre lokale Version
 Überschreibe
Üb
h ib llokale
k l K
Kopie
i mit
it d
der aus d
dem R
Repository
it
+
-
 Neue Datei aus Repository existiert nicht lokal
 Füge die Datei der lokalen Arbeitskopie hinzu
 Lokale Datei wurde im Repositoryy g
gelöscht
 Lösche die Datei aus der lokalen Arbeitskopie
Seite 2-26
ROOTS
Bedeutung der Symbole im „Synchronize
View“ (Fortsezung)
View
 Die vorherige Folie stellt die Fälle dar, wenn eine Datei gegenüber dem
Stand des letzten Abgleichs mit dem Repository nur auf einer Seite
verändert wurde
 Änderung nur lokal  Übernahme ins Repository (ausgehende Änderung)
 Änderung nur in Repository  Übernahme in lokale Kopie (eingehende
Änderung)
 Wenn eine Datei auf beiden Seiten neuer als der Stand beim letzten
Abgleich ist, wird ein Konflikt gemeldet:
 Dateiinhalt wurde lokal und im Repository verändert
Konfflikt
 Manuelle Konfliktlösung notwendig
+
–
© 2000-2009 Dr. G. Kniesel
 Lokale veränderte Datei wurde im Repository gelöscht
 Lokale gelöschte Datei wurde im Repository verändert
Seite 2-27
ROOTS
Synchronisieren: Konfliktauflösung
 Konfliktauflösung erfordert Inhaltsvergleich der Dateien
 Angezeigt
A
i t iin “Sid
“Side-by-side
b id View”
Vi ” / “Compare
“C
Edit ” von Eclipse
Editor”
E li
 Zeigt Versionsvergleich von Dateien („diff“) übersichtlich an
Beginne Detailvergleich durch Doppelklick
auff die
di entsprechende
t
h d Datei
D t i ...
© 2000-2009 Dr. G. Kniesel
Seite 2-28
ROOTS
Synchronisieren: Inhaltsvergleich im
„Compare
Compare“ Fenster
 Die lokale Arbeitskopie wird mit der Repository Version verglichen
 Hier
Hi ein
i F
Fallll ohne
h K
Konflikte:
flikt nur ausgehende
h d Änderung
Ä d
 SVN
SVN- / CVS
CVS-Plugin
Plugin für Eclipse hilft beim Versionsvergleich
 „Compare View“
© 2000-2009 Dr. G. Kniesel
Seite 2-29
ROOTS
Synchronisieren: Inhaltsvergleich im
„Compare
Compare Editor
Editor“ Fenster
 Hier die Anzeige eines Konfliktes
 Bei
B iB
Bedarf
d f kkann auch
h di
die gemeinsame
i
B
Bezugsversion
i angezeigt
i t
werden (“Show Ancestor Pane”).
 So kann man selbst entscheiden,, welches die relevante Änderung
g ist
© 2000-2009 Dr. G. Kniesel
Seite 2-30
ROOTS
3-Wege-Konfliktauflösung mit Hilfe der
„Common
Common Ancestor Pane
Pane“
 Anhand des gemeinsamen Vorfahren feststellen was sich geändert hat
 Die
Di Änderung
Ä d
üb
übernehmen
h
gemeinsamer Vorfahre
Version A
...
x=0
...
...
x=0
...
...
x=1
...
Version B
...
x=1
...
abgeglichene
g g
Version ((nach „merge“)
g )
 Mit SVN ist dies ein manueller Prozess: Sie selbst entscheiden
 für jjede Datei mit Konflikten
 für jeden Konflikt in der Datei
© 2000-2009 Dr. G. Kniesel
Seite 2-31
ROOTS
Beispiel: „Common Ancestor Pane“ (1)
 Szenario: Gemeinsam eine Ausarbeitung / Veröffentlichung schreiben
 Konflikte
K flikt in
i Datei
D t i “evaluation.lyx”
“
l ti l ”
 Frage: Welcher Stand ist der neueste?
 Erster Schritt: “Show
Show Ancestor Pane”
Pane
© 2000-2009 Dr. G. Kniesel
Seite 2-32
ROOTS
 Antwort: Keiner
 Hier
Hi wurde
d tatsächlich
t t ä hli h an der
d gleichen
l i h Stelle
St ll parallel
ll l geändert!
ä d t!
 Absprache mit dem Kollegen / Co-Author erforderlich!
© 2000-2009 Dr. G. Kniesel
Seite 2-33
ROOTS
 Antwort: Keiner
 Hi
Hier wurde
d ttatsächlich
t ä hli h an d
der gleichen
l i h St
Stelle
ll parallel
ll l geändert!
ä d t!
 Absprache mit dem Kollegen / Co-Author erforderlich!
© 2000-2009 Dr. G. Kniesel
Seite 2-34
ROOTS
Synchronisieren: Aktionen zur
Konfliktauflösung
 „Override and Update“ (Menupunkt)
 Überschreibt
Üb
h ibt llokale
k l V
Version
i mit
it R
Repository-Inhalt
it
I h lt
Override and Commit
Commit“ (Menupunkt)
 „Override
 Überschreibt Repository-Version mit lokaler Version
 Nie ohne vorherige Kommunikation mit dem Autor
d R
der
Repository-Version!
it
V i !
 „Merging
Merging“ (Manueller Vorgang)
 Selektive Übernahme einzelner Änderungen der Datei im „Compare Editor“
 Nur Übernahme von Repository-Stand in lokale Version!
 Anschließend „Mark as Merged“ auf lokaler Version (Menupunkt)
 Lokale Version wird nun als aktueller als die aus dem Repository angesehen
 Bei einem „Commit“ würden nun die nicht übernommenen Repository-Inhalte
p
y
überschrieben!
© 2000-2009 Dr. G. Kniesel
Seite 2-35
ROOTS
Tagging (= Baselining)
h
c
rc
minicalc.dsw
minicalc.h
minicalc.cpp
minicalc.rc
0
0
0
0
Release 1
1
Release 1
1
2
2
Release 1
Release 1
1
1
Release 2
Release 2
2
Release 2
3
4
© 2000-2009 Dr. G. Kniesel
3
Release 2
Jede
J
d Version
V i im
i Repository
R
i
k
kann
ein
i
globales Label (z.B. "Release 1") erhalten
Seite 2-36
ROOTS
Kapitel
Subversion
e so
ROOTS
Vergleich von Subversion (SVN)
und CVS
Versionierung von Verzeichnissen
Globale Commit-Nummerierung
Atomare Commit-Aktionen
Subversion kann mehr als CVS:
1 Versionierung von Verzeichnissen
1.
 Dateien und Verzeichnisse zu löschen, umzubenennen und zu
verschieben entspricht einer neuen Version des umgebenden
Verzeichnisses
 Hier eine Versionsänderung von /usr/src/proj
/usr/src/proj
/usr/src/proj
gui_src
gui
gui_doc
schedule
schedule
src
arc.c
zbuf.c
plan.doc
arc.c
© 2000-2009 Dr. G. Kniesel
doc
zbuf.c
plan.doc
Seite 2-38
ROOTS
1 Versionierung von Verzeichnissen
1.
 Es ist in Subversion möglich Dateien und Verzeichnisse zu löschen,
umzubenennen und zu verschieben
Warnung
g
 Man muss diese Operationen mit einem „Subversion Client“
durchführen!
 Siehe
Si h Folie
F li „Wichtige
Wi hti Li
Links“
k “
 Führt man es selbst auf Systemebene durch wird Subversion nichts
vom Umbenennen oder Verschieben erfahren.
 Es wird annehmen eine Datei wurde gelöscht und eine andere hinzugefügt!
 Man sollte tunlichst vermeiden, versehentlich die „.svn“ Ordner
innerhalb der Arbeitskopie zu verändern!
 Sie enthalten die Meta-Informationen für SVN über die zwischen den
Abgleichen mit dem Repository geschehenen Änderungen auf Dateiebene
© 2000-2009 Dr. G. Kniesel
Seite 2-39
ROOTS
2 Globale Versions
2.
Versions-Nummerierung
Nummerierung
 CVS weist jeder Datei ihre eigenen Versions-Nummern zu
A
B
C
D
1.0
1.0
1.0
1.0
1.1
1.1
1.1
1.1
12
1.2
12
1.2
12
1.2
1.3
1.3
 Problem: Es ist nicht einfach zusehen welche Versionen verschiedener
Dateien zusammengehören
 „Gehört Version 1.0 von Datei A wirklich zu Version 1.1 von Datei B?“
© 2000-2009 Dr. G. Kniesel
Seite 2-40
ROOTS
2 Globale Versions
2.
Nummerierung
 SVN weist jeder Datei die bei einem Commit verändert wurde die selbe
Versions
Versions-Nummer
Nummer zu
zu.
Build 3
Build ?
A
B
C
D
1
1
1
2
3
3
2
5
4
7
3
5
6
 Vorteil: Dateiversionen die zusammengehören sind auf einen Blick zu
erkennen: Zu einer Projektversion V gehören alle Elemente mit
V i
Versionsnummer
V oder
d kleiner
kl i
© 2000-2009 Dr. G. Kniesel
Seite 2-41
ROOTS
2 Globale Versions
2.
Nummerierung
 Ein „Roll back“ auf eine alte Version ist einfach, selbst ohne „Tags“
 „Gehe
G h zurück
ü k zu V
Version
i 3“
Build 3
A
B
C
D
1
1
1
2
3
3
2
5
4
7
3
5
6
 Tagging sollte für wichtige Zwischenstände trotzdem genutzt werden
 „Release 1.0 alpha
alpha“ ist leichter zu merken als Version 1093
© 2000-2009 Dr. G. Kniesel
Seite 2-42
ROOTS
3 Atomic commits
3.
 Netzwerkfehler oder andere Probleme können zu unvollständigen
Commits führen (nicht alle Dateien wurden „commitet
commitet“))
 Wenn dies p
passiert, hinterlässt CVS das Repository
p
y in einem
inkonsistenten Zustand.
 SVN führt bei unvollständigen Commits einen „Roll
Roll back
back“ durch.
durch
 SVN benutzt ein Datenbanksystem um das Repository zu speichern und
kann daher Commits als atomare Transaktionen implementieren!
© 2000-2009 Dr. G. Kniesel
Seite 2-43
ROOTS
Kapitel
Subversion
e so
ROOTS
Struktur von Subversion-Repositories
Spezielle
p
Ordner
Optionen
Repository Layout: Spezielle Ordner
 trunk
 Enthält
E thält di
die aktuelle
kt ll E
Entwicklungslinie
t i kl
li i
(wie HEAD in CVS)
 Also den trunk „auschecken“!
 tags
 Enthält unveränderliche Versionen des
Projekts
 Für Releases, Milestones, Backups
 branches
 Enthält alternative Entwicklungszweige
des Projekts
 Für Untergruppen
g pp eines Teams oder
parallele Entwicklung verschiedener
Varianten
© 2000-2009 Dr. G. Kniesel
Seite 2-45
ROOTS
Repository Layout: Alles nur Konvention!
 Vorherige Folie ist nur
Konvention!
 trunk, branches, tags
sind für Subversion
l O
d
normale
Ordner
 Es ist bloß der
Subversive-Client, der
sie besonders behandelt
 Ob das geschehen soll,
kann als Option
angegeben werden
 Man darf die Ordner des
Projekts organisieren wie
man möchte!
© 2000-2009 Dr. G. Kniesel
Seite 2-46
ROOTS
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
Installation des „Subversive
Subversive“
Plugins für Eclipse
Hinweise zur Installation des „Subversive
Subversive“ Plugins in Eclipse finden Sie in
einem „Exkurs“-Foliensatz zum aktuellen Kapitel und auf der Vorlesungswebsite.
ROOTS
Wichtige Links
 Subversion Buch
 http://svnbook.red-bean.com/nightly/en/svn-book.pdf
htt //
b k db
/ i htl / /
b k df
 Subversion Server
 subversion.tigris.org
 Subversion Clients als Erweiterung für den Windows Explorer
 TortoiseSVN (nur für Windows)
 Subversion Clients als Plugins für Eclipse
 Subversive  Wir empfehlen „Subversive“ zu benutzen
 Homepage: www.polarion.org
www polarion org
 Plugin Download Seite:
http://www.polarion.org/projects/subversive/download/1.1/update-site/
 Subclipse
 www.eclipse.org
© 2000-2009 Dr. G. Kniesel
Seite 2-48
ROOTS
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
Clear Case
ROOTS
ClearCase VOB (Versioned Object Base)
 Sicheres Repository
 aufbauend auf objektorientierter
Datenbank
 Zugriff nur mit ClearCase möglich
 Speichert alle versionierten Daten
0
bugfix
 Source code
0
 Directories
1
 Binaries
 Wer hat was, wann, warum getan?
 Gemeinsamer Datenzugriff
 Beliebig viele VOBs im Netzwerk
2
1
Release 1
2
3
4
develop
0
1
Release 2
4
2
mit beliebig vielen Elementen
 Verteile Datenbank
© 2000-2009 Dr. G. Kniesel
Seite 2-50
ROOTS
Virtual File System bei ClearCase
src
foo.h
foo
foo.c
c
VOB
emacs
make
gcc
grep
eclipse
WIN
DOWS
/
UNIX
M
V
F
S
src
foo c
foo.c
Softwareentwicklungswerkzeuge
foo h
foo.h
Versioned Object Base (VOB)
Regelbasierte Arbeitskopie-Verwaltung
 Prinzip: regeldefinierte Auswahl von Objekten / Versionen
 Sichtdefinition
Si htd fi iti d
durch
hb
benutzerspezifische
t
ifi h Regelmenge
R
l
 Regeln agieren als Filter: Auswahl einer bestimmten Objektversion
verhindert Zugriff auf alle anderen Versionen des selben Objekts
 Projektion der ausgewählten Versionen als normaler Verzeichnisbaum
 Statische Regelauswertung
 Auswertung der Regeln zum Zeitpunkt des Arbeitsbeginns
 ausgewählte
g
Versionen werden in den p
privaten Arbeitsbereich kopiert
p
 der Benutzer muss am Ende explizit die Synchronisation anstoßen
 Dynamische
D
i h R
Regelauswertung
l
t
(Cl
(ClearCase)
C
)
 Auswertung der Regeln zum Zeitpunkt des Objektzugriffs
 Lesevorgänge
g g direkt aus der VOB  längstmöglich
g
g
aktuellster Stand
 Objekte werden erst beim ersten Schreiben in den Arbeitsbereich kopiert
© 2000-2009 Dr. G. Kniesel
Seite 2-52
ROOTS
Regelbasierte Arbeitskopie-Verwaltung:
Regelsyntax und -semantik
semantik
 http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_EndUser/boo
ks/ClrC UG/sgi html/ch05 html
ks/ClrC_UG/sgi_html/ch05.html
 http://www.philforhumanity.com/ClearCase_Support_17.html
© 2000-2009 Dr. G. Kniesel
Seite 2-53
ROOTS
ClearCase Views
 Transparentes Arbeiten mit
verschiedenen
hi d
R
Releases
l
d
des
gleichen Projekts
View
 “Zeig mir Version 2.20”
 Eine Art Filter
 Arbeiten in Echtzeit
 Sofortiger
g Zugriff
g auf den
gesamten Datenbestand
 Downloads finden nur bei
Zugriff statt
 Kein komplettes Kopieren!
© 2000-2009 Dr. G. Kniesel
Seite 2-54
ROOTS
ClearCase Views: Private Storage
View
 Lokale Kopien ermöglichen das
Arbeiten ohne Netzzugriff
 Synchronisation mit der
Datenbank erfolgt automatisch
 Merging erfolgt automatisch
© 2000-2009 Dr. G. Kniesel
Seite 2-55
ROOTS
Automatisches 3-Wege-Merging
 Mit SVN ist dies ein manueller Prozess: Sie selbst entscheiden

 für jeden Konflikt in der Datei 
...
x=0
...
 für
fü jede
j d D
Datei
t i mit
it Konflikten
K flikt
Version A
...
x=0
...
...
x=1
...
Vorfahre
Version B
...
x=1
...
 Clear-Case führt 3-Wege-Merge automatisch durch!
 Experimentelle Resultate (Ende der 80-er Jahre!)
 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
Seite 2-56
ROOTS
ClearCase Views
 Alle Objekte im VOB sind schreibgeschützt
 Check-Out
Ch k O t
 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
 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
Seite 2-57
ROOTS
Build Management mit herkömmlichen
Werkzeugen (make,
(make ant)
 Keine automatisierte Abhängigkeitsanalyse
 Abhängigkeiten
Abhä i k it werden
d vom B
Benutzer
t
manuellll b
beschrieben
hi b
 Das ist aber in einer sich schnell ändernden Umgebung sehr aufwendig
und fehleranfällig
 Kein „Binary sharing“
 Das "normale"
normale Make weiß nichts darüber
darüber, dass ein Kollege evtl
evtl. ein
aufwendig zu erstellendes abgeleitetes Objekt schon erzeugt hat
 Kein „Bill of materials“
 unklar ob zwei abgeleitete Produkte gleichen Namens (foo.o) wirklich
gleich sind
sind, da nicht klar ist
ist, ob sie auch aus den gleichen „Zutaten
Zutaten“ und
nach der gleichen „Rezeptur“ erstellt wurden
© 2000-2009 Dr. G. Kniesel
Seite 2-58
ROOTS
Build Management mit ClearCase
Verwaltung von Informationen zum reproduzierbaren Erstellen von
abgeleiteten
abge
e tete Obje
Objekten
te
 Technische Grundlage
 Durch das VFS ist es möglich, die I/O-Zugriffe vom Compiler oder anderen
W k
Werkzeugen
auff alle
ll beteiligten
b t ili t Obj
Objekte
kt erfassen
f
und
d protokollieren
t k lli
zu
lassen.
 clearmake erledigt diese Aufgabe
 Protokollierung der benötigte Daten (Auditing)  Zutatenliste (bill-ofmaterials)
 Korrekte Versionen aller Quell-Dateien und anderer beteiligter
g Objekte
j
 Namen und Versionen der verwendeten Werkzeuge
 benutzte Parametereinstellungen
 Resultierende nützliche Eigenschaften
 binary sharing: Abgeleitete Objekte können von verschiedenen Benutzern
genutzt werden
 minimal rebuilding: Nur die notwendigsten Operationen zum Erstellen
eines abgeleiteten Objekts müssen durchgeführt werden
Build Management mit ClearCase
clearmake
audit on
invoke build script
audit off
additional
information
f
/bin/cc -g parse.c
view
Config Record
File System I/O Audit
parse.c@@/main/17
parse.h@@/main/7
lex
h@@/main/93
lex.h@@/main/93
parse.o@@12-Jul
---------------HP/UX 9.0.3
/bin/cc -g parse.c
Bill-of-material = „Stückliste“
der „Zutaten“ für die Herstellung
dieses abgeleiteten Objektes.
VOB repository
Zusammenfassung: SCM de Luxe
 Virtuelles Dateisystem
  Transparenz
T
der
d Datenhaltung
D t h lt
 Regelbasierte Konfiguration des Arbeitsbereiches
  Flexibilität
 Dynamische Regelauswertung
  Aktualität
 Automatisches Merging
  Geringer Integrationsaufwand
 Build Management
  Reproduzierbare „build“-Ergebnisse, Effizienz durch „minimal rebuilding“
g
 ECA-Regeln
  Workflow-Management
 Verteilung, automatische Spielelung, verteiltes Building
  Unterstützung für internationale Unternehmen
© 2000-2009 Dr. G. Kniesel
Seite 2-61
ROOTS
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
ROOTS
Von zentraler zu verteilter
Versionskontrolle
Nachteile zentralisierter Ansätze
Prinzip
p der verteilten Versionskontrolle
Vergleich zentrale  dezentrale Versionskontrolle
Werkzeuge
Austausch halbfertiger Zwischenstände
via zentralem SCM
SCM-System
System
 Peter und Lisa haben unabhängig am gleichen Projekt gearbeitet
 Peter will Lisa seine Änderungen
Ä
geben, damit sie sie integriert
 Ohne SCM: Via e-mail, etc.
 Problem: Keine Unterstützung für Abgleich (Synchronize & Merge)
 Mit SCM: Via commit und update
 Problem: Der inkonsistente Zustand erscheint im Repository  betrifft Andere
?
© 2000-2009 Dr. G. Kniesel
checkout / update
Seite 2-64
ROOTS
Probleme
 Commit von inkonsistenten Zuständen
 inkonsistenter Zustand betrifft Andere
 Regel: Kein commit von inkonsistenten Zustände! Niemals!
 Commit
C
i iinkonsistenter
k
i
Z
Zustände
ä d verhindern
hi d
 Spezielle „commiter“ Rolle
 Nur sehr erfahrene Entwickler haben das Recht zum „Commit“
„
 Sie müssen jeden Änderungsvorschlag beurteilen und entscheiden
 Folgeproblem: Engpass
 Kein commit inkonsistenter Zustände
 Synchronize & Merge nicht für Abgleich von Zwischenzuständen nutzbar
 Fehleranfälliger manueller Abgleich von Zwischenzuständen (Peter  Lisa)
 Commit & Revert nicht für Zwischenzustände nutzbar
 Es sammlen sich umfangreiche Änderungen an
 Rücksetzen auf Repository-Stand entsprechend verlustreich und aufwendig
© 2000-2009 Dr. G. Kniesel
Seite 2-65
ROOTS
Prinzipien Verteilter Versionskontrolle
(Distributed Version Control)
 Multiple, verteilte Repositories
 Jede(r) hat ein oder mehrere lokale Repositories
 Mehrere  Verschieden Projekte oder verschiedene Aufgaben im Projekt
 Repository kann geklont werden  inkl. der gesamten Versionshistorie!
 Repository Klonen subsummiert Branch
 Man kann trotzdem auch innerhalb eines Repository „branches“ verwalten
© 2000-2009 Dr. G. Kniesel
Seite 2-66
ROOTS
 Checkout, Commit, Update geschehen lokal
 Unabhängig von Netzverbindung und Server
 Sehr schnell
 Fokus auf Gesamt-Repository statt einzelnen Artefakten
 Jede Gesamt-Änderung hat eine eindeutige ID
 Repository-Zustand ist durch ID der letzten Änderung bestimmt
commit
#e34b
© 2000-2009 Dr. G. Kniesel
Seite 2-67
ROOTS
 Repositories können miteinander abgeglichen werden
 Pull: Holen von Änderungen (Patches) aus anderem Repository
 Push: Übertragen von Änderungen in ein anderes Repository
 Beinhaltet bei Bedarf automatisches Merge
 Merge wird als eigene Änderung verwaltet (Hat eigene ID)
 In der Abb. nehmen wir an es sei kein Merge nötig gewesen
update
commit
push / pull
© 2000-2009 Dr. G. Kniesel
Seite 2-68
ROOTS
 Technische Gleichberechtigung
 Jedes Repository kann geklont werden und von jedem kann abgeglichen
werden
 Egal welches die „ursprüngliche Kopie“ war
 Organisatorische
O
i t i h Z
Zentralisierung
t li i
((wenn gewünscht)
ü
ht)
 Vereinbarung, welches Repository als „Master“ benutzt wird
 Evtl. durch Zugriffsrechte
für „push“
/ „pull“
/ „clone“
unterstützt
g
„p
„p
„
push / pull
© 2000-2009 Dr. G. Kniesel
Seite 2-69
ROOTS
SCM-Ansätze und Werkzeuge
Zentral ((z.B. SVN))
Verteilt ((z.B. GIT))
 Operationen
 Operationen
 –––
 Checkout, Checkin
 Update, Commit
 manuelles Merging (SVN)
 Konzepte
 Konzepte
 Es gibt nur ein Repository
 Interaktion nur über zentralen
Server
 Dateiweise Historie
 Tracking von Umbenennungen
 Verwaltungsdaten in jedem
Ordner
© 2000-2009 Dr. G. Kniesel
 Clone, Pull, Push
 Checkout / Create repository
 Update, Commit
 automatischer 3
3-Wege-Merge
Wege Merge
 Gleichberechtigte Repositories
 Zentrale Instanz
organisatorisch möglich
 Repository
Repository-weite
weite Historie
 Änderung hat eindeutige Id
 Verwaltungsdaten nur im
obersten Ordner
Seite 2-70
ROOTS
Vorteile Verteilter Versionskontrolle
 Eigene, lokale Versionskontrolle
 Nicht
Ni ht erstt d
dann einchecken,
i h k
wenn wirklich
i kli h alles
ll lä
läuft
ft
 Eigene inkrementelle Historie, Rollbacks auch lokal möglich
 Lokal Arbeiten ist sehr schnell
 Diff, Commit und Revert sind rein lokal  kein Netzwerkverkehr nötig
 Branching und Merging ist leicht
 Branch = Clone
 Merge = Push oder Pull
 Partielle Integration ist leicht
 Entwickler können ihre Änderungen untereinander abgleichen
 Änderung eines „zentralen“ Masters erst nach partieller Integration
 Wenig Management erforderlich
 Schneller Start (einfach „clone“ oder „create repository“)
 Nur der eigene Rechner muss andauernd laufen
 Kein Usermanagement erforderlich
© 2000-2009 Dr. G. Kniesel
Seite 2-71
ROOTS
Nachteile Verteilter Versionskontrolle
 Ein zentrales Backup ist dennoch sinnvoll
 auch
h wenn gerne d
dagegen argumentiert
ti t wird
id
 eventuell hat nicht jeder alle Änderungen mitbekommen, also kann man
sich nicht auf andere Repositories als Backup verlassen
 Es gibt keine wirkliche „neueste Version“
 Kann man durch ein dediziertes Repository emulieren
 Es gibt keine Versionsnummern
 jedes Repository verwaltet seine eigene Änderungshistorie
 aber man kann Releases mit sinnvollen Namen taggen
gg
© 2000-2009 Dr. G. Kniesel
Seite 2-72
ROOTS
Listen weiterer SCM Werkzeuge
 Wikipedia
 http://en.wikipedia.org/wiki/List_of_revision_control_software
htt //
iki di
/ iki/Li t f
i i
t l
ft
 Sehr umfangreiche Liste, mit oft guten Fortsetzungen zu den einzelnen
Werkzeugen
 Wikipedia
 http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
http://en wikipedia org/wiki/Comparison of revision control software
 Versuch eines tabellarischen Vergleichs der Systeme
 Teilweise gut, aber hoffnungslose Sisyphos-Arbeit...
 Andere
 http://www.software-pointers.com/en-configuration-tools.html
h //
f
i
/
fi
i
l h l
 http://www.thefreecountry.com/programming/versioncontrol.shtml
 http://www.dmoz.org/Computers/Software/Configuration
p
g
p
g
_Management/Too
g
ls/
© 2000-2009 Dr. G. Kniesel
Seite 2-73
ROOTS
Vergleiche von SCM Werkzeuge
 Wikipedia (allgemein)
 http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
htt //
iki di
/ iki/C
i
f
i i
t l
ft
 Versuch eines tabellarischen Vergleichs der Systeme
 Teilweise g
gut, aber hoffnungslose
g
Sisyphos-Arbeit...
yp
 Wikipedia (nur open source)
 http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_ma
nagement software
nagement_software
 Andere neutrale Vergleiche
g
 http://better-scm.berlios.de/comparison/ (Stand 29. Feb. 2008)
 Nicht ganz unparteiische Vergleiche...
 http://www.relisoft.com/co_op/vcs_compare.html
 http://www.accurev.com/scm_comparisons.html
http://www accurev com/scm comparisons html
© 2000-2009 Dr. G. Kniesel
Seite 2-74
ROOTS
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
SCM und „Issue Management“
Siehe auch Kapitel zu
„Rationale Management“, „Project Management“,
„Softwareprozessmodelle“ und „Agile Softwareentwicklung“
ROOTS
Issue Management
 Entwicklung konzentriert sich auf einzelne „Issues“
 Probleme,
P bl
di
die zu lö
lösen sind
i d
 Neue Funktionen, Funktionsanpassung, Fehlerbehebung, Portierung, ...
 Siehe auch Vorlesungen über
 „Rationale Management“ und
 „Prozessmodelle““ („Issue-Based
(
Development“)
“)
 Tools für die zentrale Verwaltung aller „issues“
„issues und ihrer
Abhängigkeiten
 ClearQuest (s.o., kommerzielles Produkt von Rational / IBM, sehr teuer)
 Jira
Ji (für
(fü universitäre
i
itä V
Verwendung
d
an d
der U
Unii B
Bonn ffreii verfügbar)
fü b )
 roots.iai.uni-bonn.de/services
© 2000-2009 Dr. G. Kniesel
Seite 2-76
ROOTS
Issue Tracking System „Jira“: Story
Overview
© 2000-2009 Dr. G. Kniesel
Seite 2-77
ROOTS
Issue Tracking System „Jira“: Stories and
Tasks
© 2000-2009 Dr. G. Kniesel
Seite 2-78
ROOTS
Issue Tracking System „Jira“: Tasks
© 2000-2009 Dr. G. Kniesel
Seite 2-79
ROOTS
Kapitel
ap te 2: So
Software
t a e Co
Configuration
gu at o Management
a age e t
„Unified Change Management“
=
Configuration + Issue Management
ROOTS
Unified Change Management (UCM)
Aktivitäten
Tätigkeiten die das
Projekt voranbringen
Activity
A
ti it
Activity
Activity
Aktivitäten
Artefakte
Artefakte
Dateien die im Projekt
bearbeitet werden
© 2000-2009 Dr. G. Kniesel
Seite 2-81
ROOTS
UCM: Verbindung zwischen Aktivitäten
und Artefakten
ClearQuest: Aktivitäten
Verwaltung der
Aktivitäten
Request
Priority
Owner
Special Promo
1
Terry
Bug 527
2
Sandy
Add GUI button
2
Kim
Cl
C
A
t f kt
ClearCase:
Artefakte
Ch
Change S
Sett
Special Promo
Verwaltung
V
lt
der
d
Artefakte
© 2000-2009 Dr. G. Kniesel
a html
a.html
V5
c.xml
V3
b.jpg
V8
Seite 2-82
ROOTS
Unified Change Management
Projekt Manager
Projekt erzeugen
Baseline definieren
Richtlinien
festlegen
E t i kl
Entwickler
Integrator
Anmelden am
Projekt
Integration
Arbeiten an
Aktivitäten
B li erzeugen
Baseline
Arbeitsumgebung
aktualisieren
Baselinegüte
vergeben
Ergebnisse
abliefern
© 2000-2009 Dr. G. Kniesel
Seite 2-83
ROOTS
UCM mit Eclipse: Mylin, Jira und SVN
TODO
siehe Kommentarbereich der Folie
© 2000-2009 Dr. G. Kniesel
Seite 2-84
ROOTS

Kapitel 2 Software Configuration Management

Transcription

Similar documents

ClearCase

Linux als File- und Printserver für Windows

Herzlichen Glückwunsch zu Ihrer INSEVIS

Terrorismus und Menschenrechte

FT III ZTV Wegebau

Grundlagen der Datenbanken

Ausflugziele

Betriebsanleitung EL100__HMI EL1xx-EL103 ECO

Dateien anzeigen - Heinrich-Heine

Name - cci Dialog GmbH