1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum Konfigurationsmanagement der Danet GmbH Klaus Schröter, Danet GmbH.

Präsentation zum Thema: "1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum Konfigurationsmanagement der Danet GmbH Klaus Schröter, Danet GmbH."—  Präsentation transkript:

1 1 Software Configuration Management mit Microsoft SourceSafe Ein Erfahrungsbericht zum Konfigurationsmanagement der Danet GmbH Klaus Schröter, Danet GmbH Weiterstadt, 06151 868 112 schroeter@danet.de Folien und weitere Infos: www.te.danet.de/scm

2 d schroeter@danet.de 2 Danet GmbH n Software und Beratung n z.Zt. ca. 400 Mitarbeiter n gegründet 1981 n Eigentümer sind Mitarbeiter, SAIC, Deutsche Telekom n Flache Hierarchie, 12 eigenständige Einheiten n www.danet.de

3 d schroeter@danet.de 3 Wo ist das Problem? l Jeder PC Benutzer kennt das: lFehler können schnell korrigiert werden lDokumente im Computer sind leicht zu ändern lDer Kollege braucht gerade mal einen Ausdruck lZur Sicherheit macht man lieber eine Kopie der Datei lAuch auf Diskette, und auf diese Diskette …

4 d schroeter@danet.de 4 Wo ist das Problem? l Aber … n Welche Version ist eigentlich aktuell? l“Auf Seite 7 unten ist ein Fehler” l“Bei mir steht was anderes” n Dateien werden mit alten Version überschrieben oder verwechselt

5 d schroeter@danet.de 5 Software Entwicklung im Team n Software ist leicht zu ändern n Fehler müssen schnell korrigiert werden n Der Kollege braucht die Datei n Besser die Funktion X modifizieren, als die ganze Datei xyz.c neu schreiben n Der Kunde braucht schnell eine (Zwischen-)Lieferung

6 d schroeter@danet.de 6 Software Entwicklung im Team l Potenzierte Probleme n Änderungen von Kollegen gehen verloren n Module, die noch nicht zusammen-passen werden ausgeliefert n Module, die nicht mehr zusammen-passen werden ausgeliefert l Offene Fragen n Wer müßte über einen Update der Funktion X informiert werden? n Wer bearbeitet zur Zeit die Datei? n Wer ist der Autor? n Was wurde geändert? Wann? Warum? Von Wem? n Welche Version ist das eigentlich?

7 d schroeter@danet.de 7 Software Configuration Management l SCM ist: n so alt wie die Softwarekrise n wie Teflon ein Produkt der Raumfahrt n eine Disziplin des Software Engineering n Gegenstand vieler Bücher, Aufsätze, Standards n zum Teil kompliziert und abschreckend n von zahlreichen Werkzeugen unterstützt

8 d schroeter@danet.de 8 Software Configuration Management l SCM of the 70ies n Mainframe n Repository, CASE n schwierig, kompliziert n kostenintensiv l SCM heute n PC n Flexibel, unabhängig von CASE oder Methoden n einfach, pragmatisch n preiswerter

9 d schroeter@danet.de 9 SCM als Disziplin n Planen des Vorgehens im Team, der eigenen Arbeitsweise n Identifikation der configuration items l Titel des Dokuments, Dateiname, Autor, etc. n Definition von Konfigurationen l Was gehört dazu? l aka Project, Release, Baseline, Produkt, Build, Systemversion n Identifikation von Versionen l 1, 2, 3 oder “3.1”, “3.11”, “95”, “summer”,... n Verringern der Anzahl der Versionen

10 d schroeter@danet.de 10 SCM Definitionen l Configuration Item (SourceSafe: file) n Zumeist source code Dateien. Allgemeiner: nicht abgeleitetes atomares Objekt l Konfiguration (SourceSafe: project) n Definierte Menge von Dateien und Subprojekten l Version n Definierter Zwischenstand einer Datei oder eines Projekts in der zeitlichen Abfolge der Bearbeitung l Variante n Änderung einer Datei oder eines Projekts für einen neuen Zweck (keine Weiterentwicklung) l Release n Eine freigegebene und ausgelieferte Version

11 d schroeter@danet.de 11 SCM als Disziplin l Änderungkontrolle n Wie soll der Freigabeprozeß einer neuen Version ablaufen? l Autor ist verantwortlich l Review durch Kollegen l Übergabe an Library-Manager in Protected Library

12 d schroeter@danet.de 12 Software Entwicklung - Projektbibliothek l Der Library Manager beschützt die Protected Library l Kontrollierter Zugriff zur Bearbeitung oder zum Lesen l Kontrollierte Aktualisierung und Erweiterung der Bibliothek

13 d schroeter@danet.de 13 SCM als Disziplin l Änderungsplanung n Was soll / darf überhaupt geändert werden? Wann? Warum? Von Wem? l CCB - Change Control Board l CAPTT - Change and Problem Tracking Tool l SCM ist ein Teil der ISO 9000 Zertifizierung

14 d schroeter@danet.de 14 SCM mit Safe l Jede Lieferung wird auf Band kopiert l Das Band kommt in den Safe l Vorteile: n Geschützt vor ungewollter Modifikation n Geschützt vor Verlust durch Diebstahl, Erdbeben, Brand, … l Nachteile: n Zugriff schwierig und langsam n Kein Überblick über Zusammenhänge n Bänder sind HW/SW spezifisch n Kein gemeinsames Archiv n Bandlaufwerke und Formate sind schnell veraltet

15 d schroeter@danet.de 15 SCM mit RCS n Unix Tool Revision Control System n Viele ähnliche tools: SCCS, PVCS, …. n Vorteile: l Locking: Zur gleichen Zeit kann nur einer die Datei bearbeiten l History: Ältere Versionen der Datei können noch extrahiert werden l History-Diff: Was hat sich geändert? l Meta-Daten: Kommentare zu den Versionen, zur Datei selbst, Autor, Bearbeitungszustand etc.

16 d schroeter@danet.de 16 SCM mit RCS n Nachteile: l Benutzung relativ schwierig l Bei falscher Konfiguration mehrere Historien derselben Datei l Datenverluste bei der Windows Version (MKS) l Platzbedarf

17 d schroeter@danet.de 17 SCM Automatisierung l Integration von SCM Aufgaben n z.B. individuelle scripts, die RCS aufrufen l Verwaltung von Versionen und Varianten l Integration von n Problem Reports n Change Control n make n Testautomatisierung n Freigabe n Release Tape Erzeugung, … l Workflow Konzepte

18 d schroeter@danet.de 18 SCM Automatisierung l Nachteile: n Starre Arbeitsweise, inflexibel n Festlegung der SW-Technologie, z.B. UNIX und C Programme n Hoher Anpassungsaufwand bei geänderten Anforderungen

19 d schroeter@danet.de 19 SCM mit Microsoft SourceSafe l Einfach zu beherrschendes Tool l Nur ein Zweck: SCM l Für alle Arten von Dateien und Projekten geeignet l Integration und Anpassung nicht notwendig aber möglich

20 d schroeter@danet.de 20 SourceSafe l Ein Safe für Sourcen l Alle Dateien können in SourceSafe gespeichert werden: n Source Code, DLLs, Graphics, Dokumente, help files, icons, *.xls…

21 d schroeter@danet.de 21 Arbeiten mit SourceSafe l Check out aus dem SourceSafe l Bearbeiten der Datei in einem privaten working directory l Check in der neuen Version der Datei

22 d schroeter@danet.de 22 SourceSafe File check-out l Eine Datei wird aus dem Safe geholt n (Repository, Protected Library, Project Library, Archiv, ….) l Gesperrt für andere Benutzer

23 d schroeter@danet.de 23 SourceSafe check-in

24 d schroeter@danet.de 24 SourceSafe Historie einer Datei

25 d schroeter@danet.de 25 SourceSafe und Working Directories l Alle Dateien und ihre Historie werden in der zentralen SourceSafe Database gespeichert l Die Bearbeitung (edit, compile,...) erfolgt in einem normalen Verzeichnis (i.A. privat) n keine unbeabsichtigte Aktualisierung n Workspace, sandbox, etc. l Die Werkzeuge (Editor, Compiler,...) müssen nichts von SourceSafe wissen und umgekehrt

26 d schroeter@danet.de 26 SourceSafe Projekte n Ein SourceSafe Projekt ist eine Liste von Dateien und Unterprojekten n Ein SourceSafe Projekt ist eine Konfiguration n Auch die Geschichte des Projekts wird gespeichert l Wann gehörte welche Datei mit welchem Namen dazu?

27 d schroeter@danet.de 27 SourceSafe Projekte l Proj ekte sind das wichtigste Feature von SourceSafe l Basis für Operationen wie z.B.: n Label n Get n History n... n Difference

28 d schroeter@danet.de 28 SourceSafe Project Difference l Was hat sich in einem Projekt geändert: n Zwischen zwei Versionen n Zwischen einem Working Directory und dem SourceSafe Projekt n Ebenso für einzelne Dateien

29 d schroeter@danet.de Individuelle Anpassung l Viele Aspekte können individuell eingestellt werden l Einstellungen werden für jeden Benutzer zentral gespeichert (ss.ini) l Vorgaben sind in srcsafe.ini möglich

30 d schroeter@danet.de SourceSafe Automatisierung l Alle Funktionen sind auch auf der Kommandozeile möglich n ss get demo.cpp n Sinnvoll für Batch Files, Integration in eigene Umgebung möglich l Neu in Version 5.0: OLE Automation n SourceSafe durch Visual Basic steuerbar

31 d schroeter@danet.de 31 Andere SourceSafe Clients l Win16 l Visual Basic l Visual C++ l Visual J++ l Visual FoxPro 5.0 l Microsoft Access 97 l FrontPage l Microsoft Word l Microsoft Excel l Macintosh l UNIX l Delphi l Visual Intercept l Track Record

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

33 d schroeter@danet.de 33 Multiplattform Support n Für alle Dateien geeignet Dateien dürfen nicht den gleichen Namen haben wie z.B.: Readme README readme n Textdateikonversion l CR/LF, CR, LF n Effiziente Nutzung gemeinsamer Teile n Effiziente Verwaltung von Varianten

34 d schroeter@danet.de 34 SourceSafe in der Praxis n Konfigurationen definieren n Abhängigkeiten und Beziehungen verwalten n Source Code wiederverwenden n Varianten erstellen n Freigabeprozeduren n Auslieferungen n Probleme und Änderungswünsche verfolgen

35 d schroeter@danet.de 35 Konfigurationen definieren l Ein SourceSafe Projekt ist eine Konfiguration n Menge von Dateien, „Release“,... l SourceSafe selbst ist völlig flexibel l Wie soll man seine SourceSafe Projekte strukturieren? n z.B. Spiegelbild der Entwicklungsumgebung

36 d schroeter@danet.de 36 Organisation der SourceSafe Projekte l Toplevel: Organisatorische Projekte l Darunter: Produkte, ergänzende Infos l Darunter Zielsysteme l Darunter Programme, deliverables l Darin: die zur Erzeugung benötigten Dateien

37 d schroeter@danet.de 37 Abhängigkeiten und Beziehungen l Objekte (Dateien) des SCM bestehen untereinander in verschiedenen Beziehungen n “A spezifiziert B” n “A ist ein Testfall für B” n “A verwendet B” l In anderen SCM Tools werden diese Beziehungen explizit als Meta-Daten gespeichert l Mit SourceSafe kann Zugehörigkeit durch Unterprojekte modelliert werden

38 d schroeter@danet.de 38 Abhängigkeiten und Beziehungen l Bewährte Organisation: n Jedes Produkt (Liefereinheit, Target) wird ein SourceSafe Projekt n Jedes SourceSafe Projekt ist abhängig von seinem Inhalt und seinen Unterprojekten n Erzeugbare Dateien (z.B. exe files) werden Unterprojekte

39 d schroeter@danet.de 39 SourceSafe File Sharing n Dieselbe Datei wird in zwei (oder mehr) Projekten verwendet n Eine Änderung der Datei in Projekt A wird gleichzeitig in Projekt B wirksam

40 d schroeter@danet.de 40 Software Wiederverwendung l Das SourceSafe File Sharing hilft bei der Wiederverwendung n Sharing definierter Versionen: “Pin” n Lokale Modifikation: “Branch” l Auch die normale Verwendung kann damit dokumentiert werden: n “Welches Projekt verwendet Oracle?”

41 d schroeter@danet.de 41 File Sharing Möglichkeiten n Änderungen an $/B/demo.cpp sind zugleich in $/C wirksam und umgekehrt. n Änderungen an $/D/demo.cpp sind nur in diesem Projekt sichtbar. Seit Version 4 ist die Datei eigenständig. n Ä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 pin branch share

42 d schroeter@danet.de 42 Variantenverwaltung l Ausgangslage: n Ein Programm-Modul für AIX n democ.c2.000 LOC l Aufgabe: Portierung nach VMS und Windows NT

43 d schroeter@danet.de 43 Varianten: Copy and Modify n demo.c. 2.000 LOC n demo_nt.c, 2.010 LOC n demo_vms.c 2.183 LOC l Nachteile: n Informationsverlust n Spätere Updates müssen mehrfach nachgezogen werden l SourceSafe kann die Information “A entstand aus B” speichern

44 d schroeter@danet.de 44 Varianten: Single Source Concept n demo.c2.220 LOC n #ifdef überall im Code l conditional compilation l Nachteile: n schwer lesbar (Geschmackssache) n kombinatorische Explosion n enormer Testaufwand oder ungetesteter Code

45 d schroeter@danet.de 45 Varianten: Spezialisierung / Vererbung n Drei Projekte: lAIX l demo.c 1905 LOC l d_aix.c23 LOC lNT l demo.c 1905 LOC l d_nt.c67 LOC lVMS l demo.c 1905 LOC l d_vms.c 176 LOC n Definition von Funktionen (Methoden, Makros, …) für die unterschiedlichen Ausprägungen der gemeinsamen Aufgabe n Nachteil: Werkzeuge wie SourceSafe erforderlich

46 d schroeter@danet.de 46 Freigabeprozeduren l Problem: Wie ist der Stand des Projekts? Welche Datei ist fertig? Welche getestet?,... l Jeder Datei kann Status zugeordnet werden (Promotion Level) n Initial, Reviewed, Tested, OK l In SourceSafe könnten dafür Label auf Files gesetzt werden l Ist aber nicht sinnvoll, da im SourceSafe Explorer kein Überblick angezeigt wird

47 d schroeter@danet.de 47 Freigabeprozeduren und Releases l Vorgehen für Dateien n Jeder Entwickler hat ein privates Working Directory. Hier kann er entwickeln, experimentieren und und lokale Tests durchführen n Ist eine Datei fertig, so wird sie reviewed n Anschließend erfolgt der check in mit Kommentaren l Vorgehen für Projekte n Das Projekt erhält ein Label n Alle Dateien werden in ein separates Build Verzeichnis geholt n Ist der Build erfolgreich wird die erzeugte Software getestet n Sind alle Tests erfolgreich wird die Software zur Auslieferung freigeben (release)

48 d schroeter@danet.de 48 Reproduzierbare Softwareerzeugung l Alle notwendigen Dateien müssen im Projekt sein l Der Build Prozeß darf nur von diesen Dateien abhängen l no links, environment variables, registry entries l Steps to perform n Set external build identification n Label the project n Get the project files n Run “build all” command

49 d schroeter@danet.de 49 Probleme und Änderungswünsche verfolgen n Viele Tools verfügbar, z.B. individuelle Access Lösungen wie CAPTT, MS ATS, MS Team Manager, Track Record, Visual Intercept n Einige Tools bieten direkte SourceSafe Integration

50 d schroeter@danet.de 50 Was SourceSafe noch fehlt n Rekursiver Vergleich parametrisierbar n Anzeige von weiteren Daten im SourceSafe Explorer n Roll-back für Projekte n Verschiedene Namen für shared files n Eigentümer oder home project für shared files n Öffentliche Liste bekannter Fehler n Vielleicht: lAsynchrone Replikation für verteilte Entwicklung

51 d schroeter@danet.de 51 Vorteile von SourceSafe l Offenes Werkzeug l Einfach zu benutzen l Einfach zu lernen l Einfacher Einstieg n Dateinamen und Struktur können nachträglich geändert werden l Flexibel, unabhängig von n Programmiersprache n Entwicklungsumgebung n Methode n Zielplattform n Reifegrad des SW- Entwicklungsprozesses l Hohe Performanz l Für große Projekte und Dateien geeignet

52 d schroeter@danet.de 52 Fazit l SCM lohnt sich immer l Mit SourceSafe ist der Einstieg einfach l Sehr nützlich: n Projekthistorie n File Sharing n Reproduzierbare Builds