1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum...

1

Software Configuration Management mit Microsoft

SourceSafe

Ein Erfahrungsbericht zumKonfigurationsmanagement

der Danet GmbH

Klaus Schröter, Danet GmbHWeiterstadt, 06151 868 112

[email protected]

Folien und weitere Infos:www.te.danet.de/scm

d [email protected] 2

Danet GmbH

Software und Beratung z.Zt. ca. 400 Mitarbeiter gegründet 1981 Eigentümer sind Mitarbeiter, SAIC,

Deutsche Telekom Flache Hierarchie,

12 eigenständige Einheiten www.danet.de


Wo ist das Problem?

Jeder PC Benutzer kennt das: Fehler können schnell korrigiert werden Dokumente im Computer sind leicht zu ändern Der Kollege braucht gerade mal einen Ausdruck Zur Sicherheit macht man lieber eine Kopie der Datei Auch auf Diskette, und auf diese Diskette …


Wo ist das Problem?

Aber … Welche Version ist eigentlich aktuell?

“Auf Seite 7 unten ist ein Fehler” “Bei mir steht was anderes”

Dateien werden mit alten Version überschrieben oder verwechselt


Software Entwicklung im Team

Software ist leicht zu ändern Fehler müssen schnell korrigiert werden Der Kollege braucht die Datei Besser die Funktion X modifizieren, als die ganze Datei

xyz.c neu schreiben Der Kunde braucht schnell eine

(Zwischen-)Lieferung


Software Entwicklung im Team Potenzierte Probleme

Änderungen von Kollegen gehen verloren

Module, die noch nicht zusammen-passen werden ausgeliefert

Module, die nicht mehr zusammen-passen werden ausgeliefert

Offene Fragen Wer müßte über einen Update

der Funktion X informiert werden?

Wer bearbeitet zur Zeit die Datei?

Wer ist der Autor? Was wurde geändert? Wann?

Warum? Von Wem? Welche Version ist das

eigentlich?


Software Configuration Management

SCM ist: so alt wie die Softwarekrise wie Teflon ein Produkt der Raumfahrt eine Disziplin des Software Engineering Gegenstand vieler Bücher, Aufsätze, Standards zum Teil kompliziert und abschreckend von zahlreichen Werkzeugen unterstützt


Software Configuration Management SCM of the 70ies

Mainframe Repository, CASE schwierig, kompliziert kostenintensiv

SCM heute PC Flexibel, unabhängig von

CASE oder Methoden einfach, pragmatisch preiswerter


SCM als Disziplin Planen des Vorgehens im Team,

der eigenen Arbeitsweise Identifikation der configuration items

Titel des Dokuments, Dateiname, Autor, etc. Definition von Konfigurationen

Was gehört dazu? aka Project, Release, Baseline, Produkt, Build, Systemversion

Identifikation von Versionen 1, 2, 3 oder “3.1”, “3.11”, “95”, “summer”, ...

Verringern der Anzahl der Versionen


SCM Definitionen Configuration Item (SourceSafe: file)

Zumeist source code Dateien. Allgemeiner: nicht abgeleitetes atomares Objekt

Konfiguration (SourceSafe: project) Definierte Menge von Dateien und

Subprojekten

Version Definierter Zwischenstand einer Datei

oder eines Projekts in der zeitlichen Abfolge der Bearbeitung

Variante Änderung einer Datei oder eines Projekts

für einen neuen Zweck (keine Weiterentwicklung)

Release Eine freigegebene und ausgelieferte

Version


SCM als Disziplin

Änderungkontrolle Wie soll der Freigabeprozeß einer neuen Version

ablaufen?

Autor ist verantwortlich Review durch Kollegen Übergabe an Library-Manager in Protected Library


Software Entwicklung - Projektbibliothek Der Library Manager

beschützt dieProtected Library

Kontrollierter Zugriff zur Bearbeitung oder zum Lesen

Kontrollierte Aktualisierung und Erweiterung der Bibliothek


SCM als Disziplin Änderungsplanung

Was soll / darf überhaupt geändert werden? Wann? Warum? Von Wem?

CCB - Change Control Board

CAPTT - Change and Problem Tracking Tool

SCM ist ein Teil der ISO 9000 Zertifizierung


SCM mit Safe Jede Lieferung wird auf

Band kopiert Das Band kommt in den

Safe Vorteile:

Geschützt vor ungewollter Modifikation

Geschützt vor Verlust durch Diebstahl, Erdbeben, Brand, …

Nachteile: Zugriff schwierig und langsam Kein Überblick über

Zusammenhänge Bänder sind HW/SW spezifisch Kein gemeinsames Archiv Bandlaufwerke und Formate

sind schnell veraltet


SCM mit RCS

Unix Tool Revision Control System Viele ähnliche tools: SCCS, PVCS, …. Vorteile:

Locking: Zur gleichen Zeit kann nur einer die Datei bearbeiten History: Ältere Versionen der Datei können noch extrahiert

werden History-Diff: Was hat sich geändert? Meta-Daten: Kommentare zu den Versionen, zur Datei selbst,

Autor, Bearbeitungszustand etc.


SCM mit RCS

Nachteile: Benutzung relativ schwierig Bei falscher Konfiguration mehrere Historien derselben Datei Datenverluste bei der Windows Version (MKS) Platzbedarf


SCM Automatisierung Integration von SCM

Aufgaben

z.B. individuelle scripts, die RCS aufrufen

Verwaltung von Versionen und Varianten

Integration von Problem Reports Change Control make Testautomatisierung Freigabe Release Tape Erzeugung,

… Workflow Konzepte


SCM Automatisierung Nachteile:

Starre Arbeitsweise, inflexibel Festlegung der SW-Technologie, z.B. UNIX und C Programme Hoher Anpassungsaufwand bei geänderten Anforderungen


SCM mit Microsoft SourceSafe

Einfach zu beherrschendes Tool Nur ein Zweck: SCM Für alle Arten von Dateien und Projekten geeignet Integration und Anpassung nicht notwendig aber möglich


SourceSafe

Ein Safe für Sourcen Alle Dateien können in SourceSafe gespeichert werden:

Source Code, DLLs, Graphics, Dokumente, help files, icons, *.xls…


Arbeiten mit SourceSafe Check out aus dem

SourceSafe Bearbeiten der Datei in einem

privatenworking directory

Check in der neuenVersion der Datei


SourceSafe File check-out Eine Datei wird aus dem

Safe geholt (Repository, Protected

Library, Project Library, Archiv, ….)

Gesperrt für andere Benutzer


SourceSafe check-in


SourceSafe Historie einer Datei


SourceSafe und Working Directories Alle Dateien und ihre Historie werden in

der zentralen SourceSafe Database gespeichert

Die Bearbeitung (edit, compile, ...) erfolgt in einem normalen Verzeichnis (i.A. privat)

keine unbeabsichtigte Aktualisierung

Workspace, sandbox, etc. Die Werkzeuge (Editor, Compiler, ...)

müssen nichts von SourceSafe wissen und umgekehrt


SourceSafe Projekte Ein SourceSafe Projekt ist

eine Liste von Dateien und Unterprojekten

Ein SourceSafe Projekt ist eine Konfiguration

Auch die Geschichte des Projekts wird gespeichert

Wann gehörte welche Datei mit welchem Namen dazu?


SourceSafe Projekte Projekte sind das wichtigste

Feature von SourceSafe Basis für Operationen wie z.B.:

Label Get History ... Difference


SourceSafe Project Difference Was hat sich in einem Projekt

geändert: Zwischen zwei Versionen Zwischen einem

Working Directory und dem SourceSafe Projekt

Ebenso für einzelne Dateien

d [email protected]

Individuelle Anpassung

Viele Aspekte können individuell eingestellt werden

Einstellungen werden für jeden Benutzer zentral gespeichert (ss.ini)

Vorgaben sind in srcsafe.ini möglich

d [email protected]

SourceSafe Automatisierung

Alle Funktionen sind auch auf der Kommandozeile möglich ss get demo.cpp Sinnvoll für Batch Files, Integration in eigene

Umgebung möglich Neu in Version 5.0: OLE Automation

SourceSafe durch Visual Basic steuerbar


Andere SourceSafe Clients Win16 Visual Basic Visual C++ Visual J++ Visual FoxPro 5.0 Microsoft Access 97 FrontPage

Microsoft Word Microsoft Excel Macintosh UNIX

Delphi Visual Intercept Track Record


SourceSafe survival guide kein blindes Vertrauen, aber auch keine Paranoia Fehlermeldungen beachten Windows sauber konfiguriert halten, Virenschutz betreiben Externe Archivierung wichtiger Releases (echter Safe) Regelmäßiges Backup des SourceSafe Data Verzeichnisses Analyze.exe (5.00.2327) regelmäßig laufen lassen


Multiplattform Support

Für alle Dateien geeignet Dateien dürfen nicht den gleichen Namen haben wie z.B.:Readme README readme

Textdateikonversion CR/LF, CR, LF

Effiziente Nutzung gemeinsamer Teile Effiziente Verwaltung von Varianten


SourceSafe in der Praxis

Konfigurationen definieren Abhängigkeiten und Beziehungen verwalten Source Code wiederverwenden Varianten erstellen Freigabeprozeduren Auslieferungen Probleme und Änderungswünsche verfolgen


Konfigurationen definieren Ein SourceSafe Projekt ist eine Konfiguration

Menge von Dateien, „Release“, ...

SourceSafe selbst ist völlig flexibel

Wie soll man seine SourceSafe Projekte strukturieren? z.B. Spiegelbild der Entwicklungsumgebung


Organisation der SourceSafe Projekte Toplevel:

Organisatorische Projekte

Darunter: Produkte, ergänzende Infos

Darunter Zielsysteme Darunter Programme,

deliverables Darin: die zur

Erzeugung benötigten Dateien


Abhängigkeiten und Beziehungen Objekte (Dateien) des SCM bestehen untereinander in

verschiedenen Beziehungen “A spezifiziert B” “A ist ein Testfall für B” “A verwendet B”

In anderen SCM Tools werden diese Beziehungen explizit als Meta-Daten gespeichert

Mit SourceSafe kann Zugehörigkeit durch Unterprojekte modelliert werden


Abhängigkeiten und Beziehungen Bewährte Organisation:

Jedes Produkt (Liefereinheit, Target) wird ein SourceSafe Projekt

Jedes SourceSafe Projekt ist abhängig von seinem Inhalt und seinen Unterprojekten

Erzeugbare Dateien (z.B. exe files) werden Unterprojekte


SourceSafe File Sharing Dieselbe Datei wird in zwei

(oder mehr) Projekten verwendet

Eine Änderung der Datei in Projekt A wird gleichzeitig in Projekt B wirksam


Software Wiederverwendung

Das SourceSafe File Sharing hilft bei der Wiederverwendung Sharing definierter Versionen: “Pin” Lokale Modifikation: “Branch”

Auch die normale Verwendung kann damit dokumentiert werden: “Welches Projekt verwendet Oracle?”


File Sharing Möglichkeiten

Änderungen an $/B/demo.cpp sind zugleich in $/C wirksam und umgekehrt.

Änderungen an $/D/demo.cpp sind nur in diesem Projekt sichtbar. Seit Version 4 ist die Datei eigenständig.

Änderungen an $/A/demo.cpp sind nicht möglich. Die Datei ist auf Version 2 eingefroren.

5

4

3

2

1

$/A

6

5

4

$/B $/C $/D

demo.cpp

pinbranch

share


Variantenverwaltung

Ausgangslage: Ein Programm-Modul für AIX

democ.c 2.000 LOC

Aufgabe: Portierung nach VMS und Windows NT


Varianten: Copy and Modify demo.c. 2.000 LOC demo_nt.c, 2.010 LOC demo_vms.c 2.183 LOC

Nachteile: Informationsverlust Spätere Updates müssen mehrfach nachgezogen

werden SourceSafe kann die Information “A entstand aus B”

speichern


Varianten: Single Source Concept demo.c 2.220 LOC #ifdef überall im Code

conditional compilation Nachteile:

schwer lesbar (Geschmackssache) kombinatorische Explosion enormer Testaufwand oder ungetesteter Code


Varianten: Spezialisierung / Vererbung Drei Projekte:

AIX demo.c 1905

LOC d_aix.c 23 LOC

NT demo.c 1905

LOC d_nt.c 67 LOC

VMS demo.c 1905

LOC d_vms.c 176 LOC

Definition von Funktionen (Methoden, Makros, …) für die unterschiedlichen Ausprägungen der gemeinsamen Aufgabe

Nachteil: Werkzeuge wie SourceSafe erforderlich


Freigabeprozeduren Problem: Wie ist der Stand des

Projekts? Welche Datei ist fertig? Welche getestet?, ...

Jeder Datei kann Status zugeordnet werden (Promotion Level)

Initial, Reviewed, Tested, OK In SourceSafe könnten dafür Label auf

Files gesetzt werden Ist aber nicht sinnvoll, da im SourceSafe

Explorer kein Überblick angezeigt wird


Freigabeprozeduren und Releases Vorgehen für Dateien

Jeder Entwickler hat ein privates Working Directory. Hier kann er entwickeln, experimentieren und und lokale Tests durchführen

Ist eine Datei fertig, so wird sie reviewed

Anschließend erfolgt der check in mit Kommentaren

Vorgehen für Projekte Das Projekt erhält ein Label Alle Dateien werden in ein

separates Build Verzeichnis geholt

Ist der Build erfolgreich wird die erzeugte Software getestet

Sind alle Tests erfolgreich wird die Software zur Auslieferung freigeben (release)


Reproduzierbare Softwareerzeugung Alle notwendigen Dateien

müssen im Projekt sein Der Build Prozeß darf nur von

diesen Dateien abhängen no links, environment

variables, registry entries

Steps to perform Set external build

identification Label the project Get the project files Run “build all” command


Probleme und Änderungswünsche verfolgen

Viele Tools verfügbar, z.B. individuelle Access Lösungen wie CAPTT,MS ATS, MS Team Manager, Track Record, Visual Intercept

Einige Tools bieten direkte SourceSafe Integration


Was SourceSafe noch fehlt Rekursiver Vergleich

parametrisierbar Anzeige von weiteren Daten

im SourceSafe Explorer

Roll-back für Projekte Verschiedene Namen für

shared files

Eigentümer oder home project für shared files

Öffentliche Liste bekannter Fehler

Vielleicht: Asynchrone Replikation

für verteilte Entwicklung


Vorteile von SourceSafe Offenes Werkzeug Einfach zu benutzen Einfach zu lernen

Einfacher Einstieg Dateinamen und Struktur

können nachträglich geändert werden

Flexibel, unabhängig von Programmiersprache Entwicklungsumgebung Methode Zielplattform Reifegrad des SW-

Entwicklungsprozesses Hohe Performanz Für große Projekte und Dateien

geeignet


Fazit SCM lohnt sich immer Mit SourceSafe ist der

Einstieg einfach Sehr nützlich:

Projekthistorie File Sharing Reproduzierbare Builds

1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum...

Documents

Transcript of 1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum...