Software Engineering. 13. Configuration Management. Franz-Josef Elmer, Universität Basel, HS 2012

Transkript

1 Software Engineering 13. Configuration Management Franz-Josef Elmer, Universität Basel, HS 2012

2 Software Engineering: 13. Configuration Management 2 Übersicht Dokumentation, Installationssoftware, etc. Source Code Lauffähige Applikation Ausgelieferte Software Source Code Management Build Deployment

3 Software Engineering: 13. Configuration Management 3 Source Code Management (SCM) (Zentrale) Verwaltung des Quellcodes in einem Repository Verfolgung des Entwicklungsverlaufs Repository Originale check out check out check in check in check in check out PC: Entwickler 1 PC: Entwickler 2 PC: Entwickler 3 Kopie Kopie Kopie Zentrale SCM Tools: CVS, Subversion (SVN) Dezentrale SCM Tools: Git, Mercurial

4 Software Engineering: 13. Configuration Management 4 SCM: Pessimistic und Optimistic Locking Pessimistic Locking: 1.Entwickler checkt Datei aus. Ein Lock wird gesetzt Andere Entwickler können eine read-only Kopie auschecken aber keine Änderung einchecken. 2.Entwickler checkt veränderte Datei wieder ein. Jetzt kann ein anderer Entwickler die Datei auschecken und editieren. Optimistic Locking: 1.Entwickler checkt Datei aus. Es wird kein Lock gesetzt Andere Entwickler können die Datei ebenfalls auschecken und editieren. 2.Entwickler checkt veränderte Datei wieder ein. Locking nur während des Vorgangs des Eincheckens. Voraussetzung: Zwischen Aus- und Einchecken wurde die Datei im Repository nicht verändert.

5 Software Engineering: 13. Configuration Management 5 SCM: Pessimistic versus Optimistic Locking Pessimistic Locking: Vorteile: Sicherheit: Es wird garantiert, dass immer nur ein Entwickler an der Datei arbeitet. Entwickler müssen keine Merging Konflikte lösen. Optimistic Locking: Vorteil: Mehrere Entwickler können gleichzeitig an derselben Datei arbeiten. Optimistic Locking wird dem Pessimistic Locking vorgezogen, denn Nachteile: Es können nicht mehrere Entwickler gleichzeitig an derselben Datei arbeiten Ein Entwickler vergisst (z.b. vor dem Urlaub) die Datei einzuchecken: Alle anderen Entwickler sind in ihrer Arbeit blockiert. Nachteile: Entwickler muss sich selber darum kümmern, dass seine Änderungen eingecheckt werden können. Entwickler muss von Hand Merging Konflikte lösen. SCM Tools können Quellcode automatisch mergen. Vom Tool nichtlösbare Merging Konflikte sind selten.

6 Software Engineering: 13. Configuration Management 6 SCM: Optimistic Locking: Beispiel 1. Daniel checkt Contants.java aus: class Constants { static final int MAXSIZE = 100; static final double FACTOR = 0.2; } 2. Laura checkt dieselbe Datei aus und checkt folgende Änderung ein: 3. Daniel versucht seine Änderung einzuchecken und scheitert: 4. Daniel check Constants.java neu aus. Das SCM Tool (hier Subversion) mergt beide Versionen und findet einen Merging Konflikt: 5. Daniel löst Konflikt und checkt erfolgreich ein. class Constants { static final int MAX_SIZE = 100; static final double FACTOR = 0.3; } class Constants { static final int MAXSIZE = 50; static final double FACTOR = 0.2; } class Constants { <<<<<<<.mine static final int MAXSIZE = 50; ======= static final int MAX_SIZE = 100; >>>>>>>.r1263 static final double FACTOR = 0.3; } class Constants { static final int MAX_SIZE = 50; static final double FACTOR = 0.3; }

7 Software Engineering: 13. Configuration Management 7 SCM: Optimistic Locking: Handhabung 1. Synchronization der lokalen Codebasis mit dem Repository bevor man mit der Arbeit beginnt. Subversion: svn update 2. Synchronization der lokalen Codebasis mit dem Repository bevor man die eigenen Änderungen einscheckt. 3. Merging Konflikte lösen. 4. Änderungen einchecken und kommentieren. Subversion: svn commit

8 Software Engineering: 13. Configuration Management 8 SCM: Versionierung Das Repository hält alle Versionen der Dateien, die es verwaltet. Jede Version einer Datei hat eine Versionsnummer. Nach dem Einchecken steht eine neue Version der Datei zur Verfügung. Normalerweise wird nur die letzte Version ausgecheckt (in CVS und Subversion HEAD genannt). Man kann sich Unterschiede zwischen zwei Versionen anschauen. Subversion: svn diff Übersichten der Versionshistorie einer Datei sind möglich. Wer hat wann was mit welchem Kommentar eingecheckt? Subversion: svn log Man kann die komplette Codebasis zu einem bestimmten früherer Zeitpunkt auschecken. Wichtig um Bugs zu verifizieren, die bei einer älteren Version der Software aufgetreten sind.

9 Software Engineering: 13. Configuration Management 9 SCM: Branching Einfaches SCM: Sequenz von auf einander folgenden Versionen einer Datei bzw. einer Codebasis. Es gibt genaue eine aktuelle Version. Problem mit folgendem Szenario: Am 12. Januar wurde die Software V1.0.0 an den Kunden ausgeliefert. Seit dem wird für die Version V1.1 weiter entwickelt. Am 7. Februar meldet der Kunden einen kritischen Bug der unbedingt gefixt werden muss. Es stellt sich heraus, dass zum Fixen des Bugs 15 Dateien geändert werden müssen. Der Bugfix führt zu einer neuen Version V1.0.1 Natürlich soll der Fix auch in die Entwicklung V1.1 eingehen. Die Lösung für dieses Problem ist Branching: Es kann beliebig viele parallel laufende Sequenzen von Versionen einer Datei bzw. der Codebasis geben. Meistens ist eine Sequenz ausgezeichnet (Trunk genannt).

10 Software Engineering: 13. Configuration Management 10 SCM: Branching Beispiel : V ausgeliefert : Schwerwiegender Bug 9.2.: Bug gefixt 13.2.: V ausgeliefert Zeit Branching merge trunk branch

11 Software Engineering: 13. Configuration Management 11 SCM: Branching Strategien und Szenarios Release Branching: Jeder neuer Zweig ist ein neuer ausgelieferte Release. V1.0.x V1.2.x V1.1.x Experimental Branching: Neue Entwicklung ist experimentell. Merging wenn erfolgreich. experimental branch

12 Software Engineering: 13. Configuration Management 12 Build Build: Erzeugung einer lauffähigen Applikation aus dem Source Code im Source Code Repository. Build Tool: Software zur Erzeugung eines Builds: make Ant Maven Gradle NAnt Build Skript: Programm in der Skriptsprache des Tools welches einen Build erzeugt.

13 } Software Engineering: 13. Configuration Management 13 Make Build Tool in der Unix Welt. Aufruf: prompt> make <target> oder (wenn das Make File nicht 'makefile' oder 'Makefile' heisst) prompt> make -f <make-file> <target> Das Make File ist eine Mischung aus Shell Kommandos und speziellen Make Kommandos, den Target Rules: <target> : <file 1> <file 2>... <command 1> <command 2>... } Shell Target Rule Kommandos TAB Zeichen vor jedem Kommando

14 Software Engineering: 13. Configuration Management 14 Make Target Rule: <target> : <file 1> <file 2>... Regeln: Kommandos: <target> ist eine Datei, die mittels der Kommandos aus den Dateien <file 1> <file 2>... erzeugt wird. Regeln: Die Kommandos werden nur ausgeführt wenn mindestens eine der Dateien <file 1> <file 2>... jünger ist als <target>. Die Kommandos werden nur ausgeführt wenn mindestens eine der Dateien <file 1> <file 2>... jünger ist als <target>. Falls einige der Dateien <file 1> <file 2>... selber Targets im Make File sind, werden ersten deren Target Rules ausgeführt. Target Rule wird immer ausgeführt wenn es keine Datei mit Namen <target> gibt. Jedes Kommando wird in einer eigenen Shell ausgeführt. Die Kommandosequenz wird abgebrochen wenn der Exit Wert eines Kommandos nicht Null ist.

15 Software Engineering: 13. Configuration Management 15 Make: Beispiel # A simple make example program : main.o file1.o file2.o cc -o program main.o file1.o file2.o # Compiling source files main.o : main.c mydefs.h cc -c main.c file1.o : file1.c mydefs.h cc -c file1.c file2.o : file2.c command.h cc -c file2.c Dependency Graph command.h file2.o file2.c program file1.c file1.o mydefs.h main.o main.c Was passiert beim Aufruf make program? 1. Target Rule program wird ausgeführt. 2. Überprüfung, ob für abhängige Dateien Target Rules definiert sind. 3. Target Rule main.o wird ausgeführt. 4. Make stellt fest, dass main.o nicht von weiteren Target Rules abhängt. 5. Wenn mydefs.h oder main.c jünger sind als main.o wird cc -c main.c ausgeführt. 6. Auf dieselbe Art werden die Target Rules file1.o und file2.o ausgeführt. 7. Zum Schluss überprüft Make, ob nun mindestens einer der abhängigen Dateien der Target Rule program neueren Datums ist. Wenn ja wird das Link Kommando cc -o programm main.o file1.o file2.o ausgeführt.

16 Software Engineering: 13. Configuration Management 16 Make: Variable Variablen Definition: <name> = <wert> <name> ist der Name der Variablen. <wert> ist eine beliebige Zeichenkette sein. Referenz auf Variable: $(<name>) $(<name>) wird durch <wert> ersetzt. Beispiel: objs = main.o file1.o file2.o program : $(objs) cc -o program $(objs) Automatische Variablen sind spezielle Variable, deren Wert vom Kontext abhängt. Die beiden wichtigsten sind $@ Name des Targets $+ Liste der abhängigen Dateien Beispiel: objs = main.o file1.o file2.o program : $(objs) cc -o $@ $+

17 Software Engineering: 13. Configuration Management 17 Make: Pattern Rules Zusammenfassung von Target Rules zu einer Pattern Rule: Target und abhängige Dateien enthalten das Zeichen '%': Es steht für einen beliebige Zeichenkette, die in beiden Teilen der Regel denselben Wert hat. Beispiel: CC=gcc objs = main.o file1.o file2.o progam : $(objs) $(CC) -o $@ $+ %.o:%.c $(CC) -c $+ main.o : mydefs.h file1.o : mydefs.h file2.o : command.h

18 Software Engineering: 13. Configuration Management 18 Nightly Builds und Continuous Integration Nightly Builds: Jede Nacht wird aus dem Source Code Repository die aktuelle Version ausgecheckt, compiliert, alle Unit Tests ausgeführt und eine lauffähige Version der Software gebaut Continuous Integration: Nach jeder Änderung des Source Code Repositorys wird ein kompletter Build gemacht. Das Ergebnis des Builds wird als Report auf einer Web Site allen Entwicklern zur Verfüngung gestellt. Eventuell werden bei fehlerhaften Builds s verschickt. Open-Source Continuous Integrations Servers: Hudson/Jenkins (für Java): Übersicht:

19 Software Engineering: 13. Configuration Management 19 Deployment Auslieferung der Software an den Kunden bzw. Benutzer. Deployment kann folgendes mit einschliessen: Bündelung (Packaging): Erfolgt oft durch Build Skripte und umfasst: Die eigentliche Applikation Dokumentation (für Benutzer, Administrator, etc.) Installationsprogramm, -skript Installation und Konfiguration Integrationstests Verwaltung von Lizenzen Schulung Formen des Deployments: Auf CD/DVD: Konsumentensoftware wird meist in einer Schachtel eventuell mit Handbüchern ausgeliefert. Elektronisch: via Als Datei (komprimiert mit/ohne Installer) aus dem Internet herunterladbar Automatischer Start und Update Mechanismus via Internet. z.b. Java Web Start

20 Software Engineering: 13. Configuration Management 20 Installation und Konfiguration Applikationen laufen in einer Umgebung. Dazu gehört: Betriebssystem Applikationsserver z.b. für Web Applikationen Datenbank(en) Andere Server bzw. Services wie z.b. LDAP für Benutzerauthentifizierung SMTP um s abschicken zu können Zusätzliche Software wie z.b. Java VM Spezielle Bibliotheken, die nicht zum Lieferumfang gehören Konfiguration: Anpassung an die Umgebung. Voraussetzung: Software ist so flexible, dass sie ohne zusätzlichen Build vor Ort angepasst werden kann. Automatische Konfiguration: Installationsprogramm erkundet die Umgebung und findet einige Dinge selber heraus. z.b. den Pfad zur Java VM Manuelle Konfiguration: Benutzer bzw. Administrator muss die Konfigurationsparameter selber herausfinden und eingeben z.b. im Installation Wizard (typisch für Consumer Products) in einer textbasierten Konfigurationsdatei (heute oft in XML)

21 Software Engineering: 13. Configuration Management 21 Release Management Release: Auslieferbare bzw. ausgelieferte Version eines Software Produkts inkl. Dokumentation und Installationssoftware. Release Stufen: Alpha: Version, die noch sehr unvollständig und wahrscheinlich voller Bugs ist. Beta: Version, die ziemlich vollständig ist aber wahrscheinlich noch Bugs hat, die unbedingt gefixt werden müssen. Release Candidate (RC): Vollständige Version kurz vor der Freigabe. Letzte Chance um schwerwiegende Bugs zu fixen. Final: Offizielle Version des Produkts. Bekannte, aber nicht mehr gefixte Bugs werden in einer known issue Liste aufgeführt. Release Typen: Major: Version mit vielen neuen Features im Vergleich zur vorherigen Version. Minor: Version mit wenig Änderungen im Vergleich zur vorherigen Version. Patch: Keine neuen Features. Nur Bugfixes und gestopfte Sicherheitslöcher.

22 Software Engineering: 13. Configuration Management 22 Release Management Release Bezeichnung: Extern: Name des Major Releases einer Software für den Kunden. Intern: Häufiges Schema für Nummerierung von Versionen: major.minor.patch[-build] dabei sind major, minor und patch Ziffern für jeden Release Typ. Optional findet man noch eine build ID. Diese erlaubt es eindeutig den zum Release gehörigen Sourcecode aus dem SCM auszuchecken. Alpha- und Beta-Releases werden meistens mit major = 0 gekennzeichnet. Beispiele: 0.9 Beta Release 1.0 Erster Final Release Erster Patch Release nach dem Final Release 1.1 Erster Minor Release nach dem Final Release Release Richtlinien: Wann werden neue Major-, Minor-Releases und Patches herausgebracht? Beeinflusst Planung der Softwareentwicklung.

23 Software Engineering: 13. Configuration Management 23 Links Johannes Franken: Einführung in make M. Fowler: Continuous Integration (2006)