Software-Engineering II

1. Software-Engineering II Versionsverwaltung

2. Themenübersicht Objektorientierung Aspektorientierung Vorgehensmodelle UML Analyse- & Entwurfsmuster Objektorientiertes Testen Versionsverwaltung Refactoring Labor (Praktischer Teil)

3. Bei der Software-Entwicklung im Team greifen unterschiedliche Teilnehmer auf gemeinsame Ressourcen schreibend und lesend zu Strategie erforderlich Synchronisation der Zugriffe Vermeiden eines Verlustes von Änderungen Versions-Historie von Dateien sehr hilfreich in vielen Fällen Versionskontrolle

4. Distributed vs. Centralized Centralized: Es gibt einen Server, der den Quellcode zentral verwaltet. Distributed: Jeder Entwickler hat eine lokale Instanz der Server-Software, die sich mit anderen Server-Instanzen synchronisieren kann. Version Control System Distributed Revision Control Centralized Revision Control Vorlesungsinhalt GIT Concurrent Versions System (CVS) Subversion (SVN)

5. Pessimistic Revision Control Nur eine Person darf zu einer Zeit eine Datei bearbeiten Pessimistischer Ansatz: Gleichzeitiges Bearbeiten ist nicht ohne großen Merge-Aufwand möglich Zyklus: Lock – Modify - Write Optimistic Revision Control Beliebig viele Entwickler können Dateien gleichzeitig editieren Optimistischer Ansatz: In der Regel ist das Mergen von Dateien ohne größere Probleme möglich Zyklus: Copy – Modify – Merge Jeder Entwickler besitzt eine lokale Kopie des gesamten Repository Konflikt-Lösung bzw. -Vermeidung

6. Vertreter Version Control System Pessimistic Revision Control Optimistic Revision Control Vorlesungsinhalt Revision Control System (RCS) Concurrent Versions System (CVS) Subversion (SVN)

7. Centralized Optimistic Revision Control Working Copy des Entwicklers Repository Working Copy des Entwicklers Working Copy des Entwicklers

8. Check-Out Holt eine bestimmte Version eines Repository initial aus dem System Update Aktualisiert die lokale Version auf den neusten Stand Führt merging durch, falls lokal Anderungen an aktualisierten Dateien bestehen Commit Checkt geänderte Dateien in das Repository ein Revert Macht noch nicht eingecheckte Änderungen in der lokalen Working Copy rückgängig Aktionen

9. Durch das Setzen eines Tags kann ein aktueller Stand eines Repository markiert (getagged) werden Dadurch ist es später einfach, den mit einem Tag versehenen Stand wieder auszuchecken Tags

10. Branches • Ein Branch ist ein Extra-Ast im Repository, welcher separat weiterentwickelt werden kann 3. Branch 1. Branch Hauptzweig 2. Branch t Es ist möglich Branches wieder auf andere Branches oder den Hauptzweig zu mergen

11. Branches werden oft erstellt, wenn eine Software einen Release-Zustand erreicht hat Damit später auftretende Bugs in alten Versionen behoben werden können, ist es nötig, getrennte Codebasen zu haben Bugfixes können von „alten“ Branches in den Hauptzweig oder in andere Branches gemergt werden Branches

12. 1989 entstanden Speicherung Repository-Daten werden als gewöhnliche Dateien mit Zusatzinformationen auf dem Dateisystem gespeichert Die Dateien auf dem Dateisystem sind wie im Repository organisiert Geschwindigkeitseinbußen Jede Datei im Repository hat eine eigene Revisionsnummer Kaum weitere Meta-Informationen zu Dateien möglich .cvsignore: Die hier aufgeführten Dateien werden in der Sandbox ignoriert Keine atomaren Commits (E.g. Verbindungsabbrüche!!!) CVS

13. Der „Hauptzweig“ wird bei CVS HEAD genannt Revisionsnummern sind nicht Repositoryweit Spezielle Version nur über ein genaues Datum definierbar Tags sind hier deshalb sehr wichtig Eine spezielle Revision wird markiert Branching ist ein relativ aufwendiges Verfahren Tags, Branches, Hauptzweig

14. Version Control with Subversion („svn-book“) Online-E-Book -> http://svnbook.red-bean.com/ Ben Collins-Sussman Brian W. Fitzpatrick C. Michael Pilato Subversion

15. Nachfolger von CVS Open Source Repository-Nummern beziehen sich auf das komplette Repository Haben zwei Dateien die gleiche Revisionsnummer, wurden sie mit dem gleichen Commit eingecheckt Speicherung in einer FSFS-Datei-Struktur Bessere Performance Atomare Commits. Entweder ganz oder gar nicht! Subversion

16. Dateien/Verzeichnisse können Properties besitzen Steuerung von Subversion Ablegen von Meta-Informationen Bsp.: svn:ignore bei Verzeichnissen definiert, welche Dateien in der Working Copy ignoriert werden sollen svn:externals gibt URLs von Repositories an, die in dieses Verzeichnis eingebunden werden sollen Properties

17. Konventionen: Der „Hauptzweig“ wird bei SVN Trunk genannt Da Revisionsnummern repositoryweit sind, kann eine spezielle Version bereits darüber spezifiziert werden Tags sind in SVN deshalb von deutlich weniger Bedeutung als bei CVS Branching geht sehr einfach Es wird eine Kopie vom Trunk oder einem Branch erstellt $ svn copy http://[url]/trunk http://[url]/branches/new_branchname Tags, Branches, Hauptzweig

18. Nie fehlerhaften Quellcode einchecken Egal ob im Trunk oder im eigenen Branch Der Code muss Compilierbar sein Der Code sollte fehlerfrei sein Hooks erlauben das Kontrollieren von Commits Korrekter Code!

19. Shell Skripte, liegen im SVN-Server-Verzeichnis Pre-Commit Shell-Skript wird vor dem Committen ausgeführt Erlaubt das Verweigern eines Commits Bsp.: Syntaxcheck von Sourcecode, XML-Dateien Post-Commit: Shell-Skript wird nach dem Committen ausgeführt Keine Möglichkeit den Commit abzubrechen Bsp.: Teammitglieder über Commits informieren, Continuous-Integration-Server antriggern … Hooks

20. 3 verschiedene Arten von Branches Trunk Feature Branches Release Branches Practical Guidelines

21. Der Trunk enthält nur „Stable“ Features Stable bedeutet, dass zu jedem Zeitpunkt, bei jeder Revision Der Code releast werden könnte Vom Stand ein Development-Branch gemacht werden könnte Alle Commits in stable branches müssenatomar sein Es macht oft keinen Sinn direkt im Trunk zu entwickeln, denn Man sollte so oft wie möglich committen In der Regel sind viele commits nötig, bis eine stable Version vorliegt Trunk

22. Direkt im Trunk entwickeln bei: Bugfixes Erweiterungen, die so klein sind, dass sie nur einen Commit benötigen Aber: Oft werden Features unterschätzt, es fehlen am Ende Resourcen wie Übersetzungen oder Grafiken, die das Feature so lange blockieren So lange nicht alle Resource fertig sind, darf nicht committed werden Trunk - Ausnahmen

23. Ist eine Entwicklung abgeschlossen, wird ein neuer Release-Branch erzeugt Die Version dieses Branches wird deployed Release Branches release release release branch trunk

24. Release-Branch erstellen Der Branch wird vom Trunk erstellt Für Branch-Namen sollte ein Schema gefunden werden $ svn copy http://[url]/trunk http://[url]/branches/DATE-NAME branches/2009-01-01-New-Years-Features

25. Nicht jede stabile Änderung im Trunk benötigt einen neuen Release Branch (Z.B.: Bugfixes) Entscheidend ist der Umfang der Änderungen Merging im Release Branch Bugfixes release release release branch trunk

26. Bei kleinen Bugfixen kann der Release-Branch aktualisiert werden $ cd <branch_checkout_dir> $ svn up $ svn merge –rXXX:YYY [REP.URL]/trunk $ svn commit XXX:YYY ist der Bereich der zu mergenden Commits im Trunk (Bsp.: 100:104) XXX exklusive (wird nicht gemergt) Nur eine Revision mergen (REV-1):REV Release-Branch updaten

27. Entwickelungen direkt im Release Branch sollten generell vermieden werden Bugfixes zuerst im Trunk machen, dann in den Release Branch mergen Gefahr: Bugfixes werden nicht in den Trunk übernommen – beim nächsten Release-Branch fehlt der Bugfix Kein Software-Entwickler will einen Fehler zwei Mal beheben! Ausnahme: Änderungen, die für den Trunk Nicht mehr nötig sind Nicht möglich sind Hotfixes im Release Branch

28. Neuentwicklungen, umfangreicher als dass sie mit einem Commit im Trunk abgeschlossen werden können Feature Branches trunk feature branch 1 feature branch 2

29. Feature Branch erstellen Der Branch wird vom Trunk erstellt Für Branch-Namen sollte ein Schema gefunden werden $ svn copy http://[url]/trunk http://[url]/branches/dev-XXX branches/dev(elopment)-Branchname

30. Beginnt ein Team mit mehreren Features zur selben Zeit kann es Sinn machen, nicht jedes Feature in einem separaten Branch zu entwickeln Extra Branch wenn Features nicht korrespondieren und von gegenseitigen Entwicklungen nicht profitieren können Die geplanten Release-Dates der Features sehr unterschiedlich sind (Eine Lang-Zeit-Entwicklungs- und ein kurzes Feature) Was ist ein Feature?

31. Durch kontinuierliches Mergen mit dem Trunk sollte der Branch aktuell gehalten werden 1-2 Mal pro Woche Ansonsten ist das Zurück-Mergen am Schluss sehr schwierig Wenn mehrere Personen an dem Branch arbeiten, sollte eine Person als dafür Zuständig erklärt werden Das Zurück-Mergen ist in Version 1.4 relativ aufwändig: Bereits gemergte Änderungen dürfen nicht noch einmal gemerged werden In Version 1.5 wurde Merge-Tracking eingeführt: Dadurch muss nicht darauf geachtet werden, ob ein Merge dieser Revision bereits gemacht wurde Branch aktuell halten trunk feature branch 1 feature branch 2

32. Um mergen zu können, benötigt man die Revisionsnummer des letzen Merges Beim 1. Merge ist diese die Revisionsnummer bei der der Branch erstellt wurde. Diese Nummer steht in der letzten Zeile der Ausgabe von “svn log --stop-on-copy” Bei späteren merges kann man durch “svn log --stop-on-copy” die Revisionsnummer des letzten merges herausfinden Voraussetzung dafür ist, dass bei jedem Merge das selbe Schema für den Commit String verwendet wird $ svn merge [url]/svn/ncs/trunk -r XXXX:HEAD $ svn commit -m"merged -r XXXX:HEAD from trunk" Merging-Syntax (1.4)

33. Ist das Feature abgeschlossen, muss es wieder in den Trunk gemergt werden In das Verzeichnis eines Trunk Checkouts wechseln Trunk nochmals aktualisieren Aktuelle Revisionsnummer des Trunks notieren (XXX) $ svn merge .@XXXX [url]/branches/branchname@XXXX $ svn commit –m“Merged back branch to trunk“ Ab diesem Moment ist die Entwicklung in diesem Branch abgeschlossen Feature abschließen trunk feature branch

34. Server-Software unter http://subversion.tigris.org/ In vielen Linux-Distibutionen bereits im Paket-Installer enthalten Debian: apt-get install subversion Für HTTP-Verbindung: Apache Modul dav_svn Server-Software

35. Subversion bietet eine Vielzahl an Möglichkeiten, auf das Repository zuzugreifen http:// bzw. https:// Zugriff erfolgt durch eine HTTP-Verbindung (Ermöglicht auch mit HTTP-Proxy das auschecken) Achtung: Bei HTTP keine Verschlüsselung der Authentifizierung svn+ssh:// Software erzeugt eine SSH-Verbindung zum Server und Tunnelt dadurch die Kommunikation Die wichtigsten Zugriffsarten

36. Tools • Tortoise SVN • Windows Explorer Integration • http://tortoisesvn.tigris.org/ • Subversive • Eclipse Plugin • http://www.eclipse.org/subversive/ • Command Line Clients