Getting Started. für Subversion & Co. Mai Published under LGPL 2.1. Sponsored by.

Transkript

1 Getting Started Mai 2013 für Subversion & Co. Published under LGPL 2.1 Sponsored by

2 Getting Started Seite 4 von 44 Inhalt 1 Einführung WAS IST IMPACT CM? WAS STECKT HINTER IMPACT CM? MODELLELEMENTE KERNELEMENT BASELINE Impact CM für SVN & Co VMWARE FÜR DEN START START DER VMWARE AUFRUF DES IMPACT CM DESKTOP Erste Schritte anhand der Demodaten IN IMPACT CM NAVIGIEREN DEVELOPMENT LINES VISUALISIEREN INKL. FILTERMÖGLICHKEITEN Aufruf des Development Line Diagramms (DLD) Die Elemente des DLD in der Übersicht Details zu einigen Elementen des DLD Tasks Entwicklungslinien Revisionen Filtermöglichkeiten für das DLD BASELINES VISUALISIEREN TASKS & CHANGE SETS VISUALISIEREN REPOSITORY VIEW: INFORMATIONEN ZU KONFIGURATIONSELEMENTEN Ein neues Projekt einrichten WORKSPACE FÜR DAS PROJEKT ERSTELLEN DATENBANK INITIAL ANLEGEN PRODUKT UND TARGET BASELINE ANLEGEN Einstellungen von einem anderen Produkt importieren SVN-Repository hinzufügen Task-Repository hinzufügen und Tasks in der Task-List anlegen Zuordnung von Entwicklungslinien-Typen Vorbereitung der Synchronisation von Tasks Der Target Baseline initial eine Revision zuordnen Anlegen des Produkts DURCHFÜHREN DER SYNCHRONISATION MIT DEM PRODUKTMODELL VORSCHAU ENTWICKLUNGSLINIENKOPIEN ZUR ERLEICHTERUNG DES SETUP Aktive Konfigurationssteuerung mit Impact CM PLANUNG NEUE BASELINE... 34

3 Getting Started Seite 5 von Voreingestellter Baseline Workflow Neue Baseline anlegen Einer Baseline Change Requests zuordnen Impact CM aus Entwicklersicht (Eclipse PlugIn) DEVELOPMENT LINE DIAGRAM VIA ECLIPSE IDE EINSEHEN GRAFISCHES MERGEN ÜBER DAS DLD IN DER ECLIPSE IDE DEVELOPMENT LINE DIAGRAM VIA ECLIPSE IDE AKTUALISIEREN KONFIGURATIONSOPTIONEN FÜR DEN INTERAKTIVEN MERGE KONFIGURATION DES DLD-SERVERS FÜR DIE SYNCHRONISATION... 42

4 Getting Started Seite 6 von 44 1 Einführung 1.1 Was ist Impact CM? Impact CM ist ein Service AddOn zur Unterstützung des Configuration Management. Configuration Manager bzw. Produkt- und Release Manager nutzen Impact CM bei ihren KM-Aktivitäten für die Visualisierung und einfache Steuerung komplexer Produktionsprozesse auf einer gut verständlichen Abstraktionsebene. 1.2 Was steckt hinter Impact CM? Softwareprodukte bzw. gemischte Software- und Hardwareprodukte bestehen aus einer Reihe unterschiedlicher Konfigurationselemente, die in den einzelnen Lebenszyklusphasen entstehen und in ihrer Komposition ein Gesamtsystem bilden. Die einzelnen Konfigurationselemente sind unterschiedlichster Natur, werden durch verschiedene Dokumentationstechniken beschrieben (textuell, grafisch, als Modelle, Quelltext) und mit entsprechend unterschiedlichen Werkzeugen erstellt und geändert. Es ist meist nur mit erheblichem Aufwand möglich, systemübergreifende Baselines und die Traceability während der Evolution komplexer Systeme sicherzustellen. Die in den beteiligten Werkzeugen isoliert vorliegenden Informationen zu den einzelnen Systembestandteilen und deren Status sind oft nicht aussagekräftig und nur unzureichend miteinander verknüpft. Es fehlt die vollständige Systemsicht über Werkzeuggrenzen hinweg in Kombination mit der zeitlichen Dimension. Dieser Problematik kann mit dem modellbasierten Service AddOn Impact CM begegnet werden. Impact CM impliziert eine modellierte Sicht auf ein Gesamtsystem im Sinne eines ganzheitlichen Configuration Managements. Mit entsprechenden Modellvisualisierungen lassen sich komplizierte Systemzusammenhänge sehr einfach und verständlich darstellen. Abbildung 1: Werkzeugneutrales Impact CM Modell Es liegt ein allgemeines CM-Domänenmodell zugrunde, das die werkzeugübergreifende Steuerung von komplexen Systemkonfigurationen ermöglicht. Dazu werden kontinuierlich wesentliche Informationen aus der Werkzeugebene mit dem Impact CM Modell synchronisiert. Über das Modell läßt sich jederzeit der Zustand der realen Systemkonfiguration inkl. Planung und Historie über verschiedene Sichten gut visualisieren.

5 Getting Started Seite 7 von Modellelemente Das Impact CM Domänenmodell beinhaltet u.a. die grundlegenden Modellelemente Product, Component, Configuration Item, Configuration, Artifact, Baseline, Version, Release, Task, Change Set und Development Line. Diese sollen im folgenden kurz definiert werden, um bei der Verwendung im weiteren Klarheit bzgl. ihrer Anwendung zu haben. Artifact (dt. Artefakt) Configuration Item (dt. Konfigurationselement) Configuration (dt. Konfiguration) Ein File (Quellcode, Library, Dokument, ). Ein Artefakt, das unter Configuration Management gestellt ist. Ein Set von ausgewählten Konfigurationselementen, ein Konfigurationselement kann selbst auch eine Konfiguration sein. Component Product Version Release Baseline (dt. Bezugskonfiguration) Change Set Task Development Line (dt. Entwicklungslinie)... Bezeichnung für eine entwurfstechnisch abgetrennte Teilkonfiguration. Bezeichnung für eine komplette System- bzw. Produktkonfiguration. Ausführungsstand eines Konfigurationselements zu einem bestimmten Zeitpunkt. Versionen sind zeitlich nacheinander liegende Ausprägungen eines Konfigurationselements. Freigabestand einer Konfiguration. Eine bestimmte für die Steuerung des Entwicklungsprozesses ausgewählte Konfiguration, die gezielt geplant, gesichert und bei entsprechender Qualität freigegeben wird. Bis zur letztendlichen Freigabe, also für den Zeitraum der Planung und Abarbeitung der geplanten Aufgaben sprechen wir auch von der Target Baseline. Atomare Änderung an einer Konfiguration. Ist ein Änderungsauftrag in Bezug auf ein Produkt. Tasks sind Auslöser für eine neue Baseline. Repräsentiert die Entwicklung einer Softwarekonfiguration über einen bestimmten Zeitraum. 1.4 Kernelement Baseline Das Kernelement von Impact CM ist die Baseline. Baselines repräsentieren den geordneten Übergang von einer Systemkonfiguration zur nächsten. In Impact CM wird die Baseline nicht nur als erreichter Stand aufgefasst, sondern wird bewußt im Voraus als zu erreichender Stand, die sogenannte Target Baseline, geplant. Auslöser für eine neue Target Baseline sind Anforderungen bzw. Änderungsanforderungen. Soll ein Änderungswunsch in eine bestehende Konfiguration eingearbeitet werden, so wird eine Target Baseline definiert, auf die dann die weitere Fortentwicklung zielt.

6 Getting Started Seite 8 von 44 2 Impact CM für SVN & Co. Mit dem in der Einführung beschriebenen Modellansatz lässt sich Subversion in Verbindung mit weiteren Werkzeugen wie ein hochintegriertes CM-Werkzeug einsetzen. Zudem können einige derzeit noch in Subversion fehlende Konzepte ergänzt, Konzeptschwächen ausgeglichen und eine gute Transparenz bzgl. der Konfigurationsentwicklung und strukturierung durch entsprechende Visualisierungen über das Modell erreicht werden. 2.1 VMware für den Start Um die ersten Gehversuche mit Impact CM unternehmen zu können, wird eine VMware zum Download bereitgestellt. Der interessierte Nutzer kann sich so zunächst mit der Navigation und der aktuell umgesetzten Funktionalität vertraut machen. In einem Musterprojekt wird die Verknüpfung von Informationen aus einem SVN- Repository mit Informationen aus dem Change Management System Trac über das Produkt-Modell in Impact CM verdeutlicht. Es wird im Folgenden erläutert wie das Produktmodell in verschiedenen Sichten visualisiert werden kann, Schwerpunkt liegt dabei zunächst auf der Visualisierung der Produktkonfigurationen als Entwicklungslinien inkl. Revisionen, Branches, Merges und Tasks. In einem späteren Kapitel geht es dann um die prinzipielle Einrichtung eines Projekts für eigene Produkte, beschrieben am Beispiel der Einrichtung des Musterprojekts. 2.2 Start der VMware Um die VMware betreiben zu können, sollte auf dem zu verwendenden System der VMware Player, die VMware Workstation oder der VMware Server installiert sein. Zudem sind mindestens 12GB freier Festplattenspeicher, 3 GB Arbeitsspeicher und eine minimale Auflösung von 1280x1024 Pixel notwendig. Der virtuellen Maschine sollten 2GB Arbeitsspeicher zugewiesen werden. In der virtuellen Maschine ist die Linux-Distribution CentOS in der aktuellen Version installiert, außerdem das objektrelationale Datenbankmanagementsystem PostgreSQL, das Versionsverwaltungssystem Apache Subversion, das Change Management System Trac und der Apache HTTP Webserver. Die Versionsverwaltung Subversion und das Change Management System Trac sind über den Apache HTTP Server erreichbar, innerhalb der VMware über bzw. von außerhalb über bzw. Falls kein Zugriff mittels der VMware Oberfläche erfolgen kann, besteht die Möglichkeit, den Rechner mit einem VNC-Player über vnc://ip:0 zu bedienen. Das Passwort für den Zugriff per vnc lautet impact. Heruntergefahren werden kann die VMware über den Menüpunkt System Shut Down in der Taskleiste, welche sich am oberen Bildschirmrand befindet. Nach dem Start der virtuellen Maschine wird der Systembenutzer impact automatisch eingeloggt. Auf dem Desktop befinden sich einige zusätzliche Desktop-Icons: Impact CM Desktop: Impact CM DLD Server: Impact CM Migration: startet die aktuelle Impact CM Desktop Version startet den Impact CM Development Line Diagram Server (DLD Server) startet im Bedarfsfall eine Datenmigration von einer früheren Impact CM Version

7 Getting Started Seite 9 von 44 Update Impact CM Desktop: Aktualisierung der Impact CM Desktop Version Update Impact CM DLD Server: Aktualisierung des Impact CM DLD Server Update Impact CM Migration: Aktualisierung der Impact CM Migration Drop Databases: Eclipse: Pfade stellt eine Oberfläche für das Löschen von Datenbanken zur Verfügung startet Eclipse mit installiertem Impact CM Eclipse PlugIn Die Subversion Repositories liegen unter /srv/svn/ und die Trac Projekte unter /srv/trac. Subversion und Trac benutzen dieselbe Passwortdatei /etc/httpd/passwd/impact.passwd. System-Benutzer Benutzer Password Bemerkung root impact Administrator impact impact kann durch sudo höhere Rechte erlangen Datenbank-Benutzer Benutzer Password Bemerkung postgres impact impact Trac-Benutzer, Subversion Benutzer Datenbank-Administrator, der Systembenutzer root kann auf der Konsole mit su - postgres zum Benutzer postgres wechseln Benutzer Password Bemerkung admin impact Trac-Administrator (TRAC_ADMIN) harry impact impact impact Trac-Administrator (TRAC_ADMIN) mikle sally impact impact trac impact Trac-Administrator (TRAC_ADMIN) 2.3 Aufruf des Impact CM Desktop Der Impact CM Desktop stellt die Funktionalitäten für die Rolle des Configuration Manager zur Verfügung. Deshalb starten wir diese Komponente zuerst und werfen einen Blick auf die Bedienung anhand der eingerichteten Beispielprodukte. Abbildung 2: Start des Impact CM Desktops aus der GUI

8 Getting Started Seite 10 von 44 3 Erste Schritte anhand der Demodaten 3.1 In Impact CM navigieren Ausgangspunkt für die Navigation ist stets das Produktmodell mit seinen Baselines unter dem Tab Inventory. Mit dem Filter über der Produkteliste ist auswählbar, welche Baselines zum Produkt angezeigt werden sollen (Show All, Show <Open>, Show <Closed>, (Show <Released>). Abbildung 3: Inventorysicht mit Überblick über Produkte und Baselines Nach Markierung einer Baseline sind die zur Baseline gehörenden Tasks, Repository- Elemente (Software-CI s), Change Sets unter den weiteren Tabs sichtbar. Die jeweils markierte Baseline ist am linken unteren Fensterrand ablesbar. Weitere Menüpunkte befinden sich unter dem Menüpunkt Navigator in der Icon -Bar. Unter dem Menüpunkt Update kann der Workspace mit den letzten Modelldaten aus der Datenbank aktualisiert werden. 3.2 Development Lines visualisieren inkl. Filtermöglichkeiten Aufruf des Development Line Diagramms (DLD) Die zu einem Repository gehörenden Entwicklungslinien lassen sich unter dem TAB Inventory per rechtem Mausklick auf eine ausgewählte Baseline visualisieren. Ebenso kann das ganze Produkt visualisiert werden. Abbildung 4: Kontextmenü Visualisierung Development Lines

9 Getting Started Seite 11 von 44 Die Anwahl führt zur grafischen Darstellung der entsprechenden Development Line inkl. abzweigenden Branches und Releases, Revisionen, Tasks und Merges. Abbildung 5: Development Line Diagramm (DLD) Die Elemente des DLD in der Übersicht Die Elemente im Development Line Diagramm liefern bei Mouse-Over, rechtem Mausklick bzw. Doppelklick zusätzliche Informationen: Element Symbol MouseOver Rechter Mausklick Doppelklick Dev Line Box Task Commit/ Revsion Global Revision Dev Line Anzeige des Pfads im Versionskontrollwerkzeug Branchpfeil Mergepfeil Movepfeil Repository URL Datum, Uhrzeit, Task -ID, Summary Commit Message (Datum, Uhrzeit, Author, Revision) Anzeige Ausgangsentwicklungslinie, Zielentwicklungslinie Anzeige gemergter Revisionen von Entwicklungslinie nach Entwicklungslinie Anzeige des Elements vor dem Move und nach dem Move Commit Message (Datum, Author) Type, Source, Revision, Status Alle Commits zur Task mit Change Sets per Filter: konkreter Commit/ pro Baseline/ pro Produkt Commit Message, Change Sets, incl zus. Info Anzeige der auf der Entwicklungslinie aktiven Tasks Anzeige der auf dem Branch weiterhin aktiven Task Anzeige gemergter Tasks von Entwicklungslinie nach Entwicklungslinie Anzeige der mit dem Move verbundenen Task Repository URL Öffnen der Task im Change Modus Öffnen der Change Set Ansicht

10 Getting Started Seite 12 von Details zu einigen Elementen des DLD Tasks Ein Doppelklick auf das Task-Symbol öffnet die Task im Change Modus. Alle im Change Management Tool zur Task verfügbaren Informationen werden angezeigt, die Task kann bearbeitet und die Änderungen abgespeichert werden. Abbildung 6: Delete, Move, Rename Bereits geschlossene Tasks sind mit einem Häkchen markiert, per Task-Pattern identifizierte aber inhaltlich noch nicht synchronisierte Tasks mit einem Ausrufezeichen. Abbildung 7: Inhaltlich noch nicht synchronisierte Task Entwicklungslinien Ein Delete, Move oder Rename einer Entwicklungslinie wird durch ein rotes Kreuzchen in der Dev Line Box angezeigt. Die Revisionsnummer des neuen Elements (bei Rename, Move) bzw. des Löschvorgangs steht in Klammern hinter der Revisionsnummer des gelöschten Elements. Abbildung 8: Delete, Move, Rename Revisionen Ein Rechtsklick auf ein Revisions-Symbol öffnet die Change Set Ansicht. Alle geänderten Dateien des jeweiligen Change Sets werden gelistet. Änderungen an Properties werden durch ein grünes Häckchen in der Property-Spalte angezeigt. Linker Mouse-Klick auf die Property-Spalte sortiert die Change Sets nach Art der Änderung, so dass alle Property- Änderungen gebündelt gelistet werden. Abbildung 9: Property Changes

11 Getting Started Seite 13 von 44 Durch Markieren einer Datei und Auswahl von Compare ist ein Vergleich mit der vorherigen Version und die Ansicht der Änderungen möglich. Abbildung 10: Text- und Property-Diffs Filtermöglichkeiten für das DLD Über den Filter (Icon Preferences) am rechten oberen Fensterrand kann das Development Line Diagramm bzgl. verschiedener Parameter gefiltert bzw. die Anzeige bzgl. gewünschter Informationen angepasst werden. Abbildung 11: Icon für Development Line Diagramm Filter Abbildung 12: Development Line Diagramm Filter

12 Getting Started Seite 14 von 44 Im Revision-Bereich lässt sich die Darstellung auf einen bestimmten Zeitraum (date) oder einen bestimmten Ausschnitt anhand Revision x bis Revision y einschränken. Der User kann sich aber auch die gesamte Entwicklungslinie anzeigen lassen (0 Head). Im Bereich Display kann All commits aktiviert werden. Im Entwicklungsliniendiagramm werden dann alle Revisionen abgebildet unabhängig von den Mergepunkten. Wird Commit message aktiviert, werden zu allen Revisionen die Commit Messages mit angezeigt. Die Tasks und ihre Beschreibungen (Task summary) lassen sich ausblenden. Im Bereich Development Line Options kann bestimmt werden, welche Informationen zu den Entwicklungslinien man sich anzeigen lässt. Ist Baseline aktiviert, wird der Baseline-Name angezeigt. Über Type werden Informationen zur Art der Entwicklungslinie (Mainline, Releasebranch, Taskbranch,...) angezeigt. Bei Aktivieren von Range wird der Revisionsbereich des jeweiligen Entwicklungslinienabschnitts zwischen zwei Merges angezeigt. Flip spiegelt die Entwicklungslinie an ihrer Achse. Die Mainline liegt nun unten. Durch Aktivieren von Colorize werden die Branchpunkte entsprechend des Entwicklungslinientyps des Branches unterschiedlich eingefärbt. Wird Ignore transitive merges aktiviert, werden nur wirklich durchgeführte Merges angezeigt unabhängig von Merge-Tracking-Informationen in Subversion. Im Bereich Timeline kann die graphische Darstellungsweise der zeitlichen Entwicklungsabfolge angepasst werden. Vertikale Timelines teilen die Entwicklungslinien optisch in zeitliche Entstehungsabschnitte in bestimmten Intervallen (Daily/Weekly/Monthly/Three month) ein. Durch Anwählen von Pack all wird die Darstellung der Entwicklungslinien zwischen zwei Timelines auf die Breite des größten Elements im Zeitintervall komprimiert. Entwicklungsfreie (Commit-freie) Zeitabschnitte können komplett ausgespart angezeigt werden (Exclude empty). 3.3 Baselines visualisieren Unter dem TAB Inventory läßt sich über das Kontextmenü zum Produkt via Show Baseline Diagram eine grafische Sicht auf die existierenden Baselines und Baseline Releases erzeugen. Abbildung 13: Kontextmenü Visualisierung Baseline Diagramm Das nachstehende Baseline Diagramm zeigt für das ausgewählte Demoprodukt die Abhängigkeiten der freigegebenen und in Entwicklung befindlichen Konfigurationen.

13 Getting Started Seite 15 von 44 Abbildung 14: Baseline Diagramm 3.4 Tasks & Change Sets visualisieren Unter dem TAB Tasks erhält man eine konsequent Task-bezogene Sicht auf die Entwicklung im Repository. Im oberen Bereich des Task-Windows werden die Tasks zur ausgewählten Baseline mit ihren Metainformationen gelistet, im unteren Bereich die jeweils zur selektierten Task gehörenden Change Sets. Abbildung 15: Visualisierung Tasks und zugehörige Change Sets Existieren mehrere Change Sets zu einer Task lassen sich diese nach Zugehörigkeit zur Baseline filtern. Mit einem Doppelklick auf ein Change Set gelangt man in eine Vergleichsansicht, die die Deltas zur vorherigen Version des betreffenden Files anzeigt.

14 Getting Started Seite 16 von Repository View: Informationen zu Konfigurationselementen Der Repository View liefert Detail-Informationen zu einzelnen Konfigurationselementen. Die nachfolgend kurz beschriebenen Visualisierungen stehen für Konfigurationselemente (Files, Folder, Externals) unterhalb einer Development Line zur Verfügung. Show Tasks: Dieser View zeigt alle Tasks, die zu einer Änderung (Add, Delete, Modify, Replace) des Konfigurationselements geführt haben, wird abgeleitet aus der Beziehung Task -> ChangeSet -> Resource. Show Resource History: Dieser View zeigt die Historie eines Konfigurationselements analog der SVN-Funktion "log". Die Historie wird aus dem internen Modell berechnet. Für die selektierte Revision wird die zugehörige Task angezeigt. Abbildung 16: Resource History View Show Resource Tree: Dieser View zeigt chronologisch sortiert alle Entwicklungslinien zu einem selektierten Konfigurationselement an. Abbildung 17: Resource History View Show Resource Diagramm: Grafische Darstellung der Entwicklungslinien, in denen das Konfigurationselement enthalten ist.

15 Getting Started Seite 17 von 44 Für Development Lines stehen über das Kontextmenü analoge Visualisierungen und zusätzlich die folgenden zur Verfügung: Show Activities: Der View zeigt alle "Aktivitäten" (Branch, Merge) bei denen die Entwicklungslinie Quelle oder Ziel der Operation ist. Show Development Line Diagram: Der View zeigt die Branch-/Mergeoperationen (s. Funktion "Show Activities") ergänzt um Tasks, Change sets und Timeline. 4 Ein neues Projekt einrichten Meist startet man mit Impact CM nicht auf der grünen Wiese, sondern möchte zum Zeitpunkt X ein bestehendes Softwareprodukt unter modellbasierte CM-Steuerung mit Impact CM nehmen. Dazu synchronisiert man einen Teil oder die gesamte bisherige Historie des Software- Repositorys mit dem Entwicklungslinienmodell in Impact CM. So kann man auch bereits in der Vergangenheit liegende, ohne Impact CM ausgeführte Arbeiten über das Modell visualisieren und analysieren. Am einfachsten geht dies, wenn man bereits bisher mit eindeutigen Bezeichnungen für Branches und Tags gearbeitet hat wie unten im Kapitel Zuordnung von Entwicklungslinien-Typen beschrieben. In der Demoversion von Impact CM gibt es anhand des Projekts PatternDemo_neu die Möglichkeit, die Neueinrichtung eines bereits bestehenden Projekts von Grund auf durchzuspielen. Dabei werden zunächst ein Projekt-Workspace und eine neue Datenbank und dann die einzelnen Produkte angelegt. Bei der Anlage der Produkte wird die eigentliche Synchronisation der Repositorys vorbereitet. Der Zugriff auf das SVN- Repository und auf das Repository der Aufgabenverwaltung wird hier eingerichtet. Außerdem müssen die entsprechenden Pattern eingegeben werden, die eine Zuordnung der verschiedenen Entwicklungslinientypen auf die im Modell vorgesehenen Klassifizierungen bzw. eine Zuordnung der Commit-Informationen zu den Änderungsanforderungen im Change-Management-System ermöglichen. Schließlich wird die Revision des Produktes ausgewählt, die Ausgangspunkt und somit erste Target- Baseline des unter Impact-Verwaltung gestellten Produkts sein soll. Im Folgenden werden diese Aktionen Schritt für Schritt beschrieben. 4.1 Workspace für das Projekt erstellen Startet ein Benutzer den Impact CM-Desktop, öffnet sich automatisch das Dialogfenster Workspaces (Menüpunkt Action im Hauptmenü). Abbildung 18: Anlegen eines Workspace

16 Getting Started Seite 18 von 44 Mit linkem Mausklick auf Create wird ein neuer Workspace angelegt. Es öffnet sich ein Eingabefeld. Hier gibt der User der Demo-Version den Workspace-Namen PatternDemo_neu ein. O.k. erstellt den Workspace, der durch Markieren und Klick auf Open geöffnet werden kann. 4.2 Datenbank initial anlegen Eine Projektdatenbank wird angelegt, auf der die Projektinformationen für Impact CM gespeichert werden. Impact unterstützt lokale und remote Datenbanken. HSQL und SQLite können jedoch nur lokal verwendet werden. Für Postgres und Derby ist eine Identifizierung erforderlich. Das Database-Fenster öffnet sich automatisch, wenn ein Workspace angelegt wurde. Der PatternDemo_neu - User wählt Postgres als Datenbank für sein Projekt aus und benennt die Datenbank im Eingabefeld Identifier mit impact_patterndemo_neu. Er identifiziert sich für den Zugriff auf die Datenbank mit dem Benutzernamen impact und dem Passwort impact. Mit Klick auf Create Database wird eine Datenbank angelegt. Unter dem Link Test Connection kann die Verbindung zur Datenbank überprüft werden. Abbildung 19: Datenbank anlegen 4.3 Produkt und Target Baseline anlegen Ein neues Produkt wird im Inventory unter dem Menüpunkt + Add Product der Toolbar angelegt.

17 Getting Started Seite 19 von 44 Abbildung 20: Produkt hinzufügen Im erscheinenden Produkte-Dialogfenster wird die Synchronisation eines oder mehrerer Produkte des Projekts vorbereitet. Zunächst muss der Produktname und der Name der Baseline, die Ausgangspunkt für den Aufbau des Produktmodells in Impact CM sein soll, eingegeben werden. Abbildung 21: Produkte-Dialogfenster

18 Getting Started Seite 20 von 44 Im Projekt PatternDemo_neu heißt das erste Produkt Product 1 (UnstableTrunk), als Target-Baseline-Name wird Baseline 1 gewählt. Später werden auch Product 2 (StableTrunk) und Product 3 (AgileRelease) hinzugefügt werden Einstellungen von einem anderen Produkt importieren Der erste Menüpunkt im Produkte-Dialogfenster Import from file ist erst für das Anlegen der Produkte 2 und 3 interessant. Hier kann eine Datei importiert werden, in der die Developmentline-Pattern-Einstellungen sowie die Mylyn-task-pattern-Einstellung eines anderen Produktes (im Fall von PatternDemo_neu Product 1 ) gespeichert sind. Auf diese Weise können diese Einstellungen für das neue Produkt übernommen werden Zunächst müssen jedoch einige Schritte ausgeführt werden, um Product 1 vollständig anzulegen SVN-Repository hinzufügen Um auf das Subversion Repository des Produkts zugreifen zu können, muss Impact CM über den Speicherort des Repositorys informiert werden. Die URL wird unter dem Link SVN repository eingegeben. Eine Identifizierung mit Benutzernamen und Passwort für den Zugriff auf das Subversion Repository wird angefordert (für PatternDemo_neu: impact und impact ). Bei Aktivierung der Option Use the repository URL as the label wird das Repository bei Nennung in Impact CM mit der URL genannt). Unter Use a custom label kann jedoch auch ein benutzerdefiniertes Label verwendet werden, z. B. UnstableTrunk. Durch Aktivierung von Validate Repository Location on finish wird die Repository-URL bei Beendigung der Operation automatisch überprüft. Abbildung 22: SVN-Repository anlegen

19 Getting Started Seite 21 von 44 Es ist empfehlenswert die Option Save Password zu aktivieren, damit das Passwort nicht bei jeder Datenabfrage erneut eingegeben werden muss. Mit Finish wird die Repository-Location angelegt. Die Repository-URL für Product 1 (UnstableTrunk) in PatternDemo_neu lautet Task-Repository hinzufügen und Tasks in der Task-List anlegen Unter dem Link Task Repository wird der Repository-Speicherort des verwendeten Task- Management-Systems angegeben. Impact CM unterstützt bis jetzt die Anbindung von Bugzilla, CollabNet Project Tracker, CollabNet TeamForge, JIRA und Trac. Das Trac- Repository für das Projekt PatternDemo_neu wird für alle drei Produkte eingesetzt. Es muss daher nur einmalig mit der URL hinzugefügt werden. Abbildung 23: Task-Repository hinzufügen Damit Zugangsdaten für das Task-Repository eingegeben werden können, muss die Check-Box Anonymos deaktiviert werden. Die Identifizierung für den Zugriff auf das Trac-Repository erfolgt mit impact und impact. Mausklick auf Validate Settings veranlasst die Validierung der Datenbank-URL sowie der Login-Daten. Unter Additional Settings sollte im Demo-Projekt jetzt XML-RPC als Access Type angegeben sein. Ist der Zugriff auf das Task-Repository nicht Passwort-geschützt, besteht auch die Möglichkeit eines anonymen Zugriffs über eine Web-Oberfläche (Access Type Web). Es ist empfehlenswert die Option Save Password zu aktivieren, damit das Passwort nicht bei jeder Datenabfrage erneut eingegeben werden muss. Mit Finish wird das Repository angelegt Zuordnung von Entwicklungslinien-Typen Im Produktkontextmenü (rechter Mausklick auf das Produkt) sind unter Preferences/ Development Lines eine Reihe von Entwicklungslinientypen charakterisierbar. Damit lassen sich bestimmten Arten von SVN-Entwicklungslinien eindeutige Typ- Bezeichnungen im Modell zuordnen und später visualisieren. Der Benutzer kann unter dem Button Manage hier auch selbst Entwicklungslinientypen sowie deren Benennung und Verhalten in Bezug auf Öffnen und Schließen einer Baseline beim Synchronisieren historischer Daten definieren. Dabei werden folgende Entwicklungslinienarten nach ihrem Baseline Verhalten unterschieden:

20 Getting Started Seite 22 von 44 Mainline Codeline Hauptentwicklungslinie, Separate Entwicklungslinie, die mitunter explizit zur Pflege einer Produktversion angelegt wird (Product Branch) Unspezifische Nebenentwicklungslinie. Die bestehende Baseline wird sowohl auf dem Abzweig als auch auf der fortlaufenden Linie beibehalten. Release(Prep) Line Vorbereitende Entwicklungslinie, die zum Release führt. Die bestehende Baseline wird auf dem Abzweig (ReleasePrep Line) fortgeführt. Auf der fortlaufenden Linie entsteht eine neue Baseline. Release Tag bzw. Label, um einen Release-Stand eines Produktes festzuhalten. Die bestehende Baseline wird auf dem Abzweig beibehalten, geschlossen und released. Auf der fortlaufenden Linie wird eine neue Baseline angelegt. Die Arten Codeline, Mainline, Release(Prep) Line, und Release bestimmen bei der automatischen Synchronisation von SVN-Repository und Produktmodell die Baseline-Strategie. Jeder neu definierte Entwicklungslinientyp muss einem dieser Arten zugeordnet werden. Für die in PatternDemo vordefinierten Entwicklungslinientypen gilt hinsichtlich ihres Baseline-Verhaltens: Mainline und Product Branch gelten als Mainline, Task Branch, Third Party Codeline, Bugfix Branch und Feature Branch werden als Codeline typisiert. Der Release Branch entspricht der Release(Prep) Line und das Product Release dem Release. Wenn die Mainline z.b. auf einen Product Branch kopiert wird, wird die aktuelle Baseline geschlossen und für die Fortführung der Mainline eine neue Baseline erstellt. Daneben wird für den Product Branch eine weitere unabhängige Baseline eingerichtet. Jede Baseline hat genau eine aktive Entwicklungslinie. Die Zuordnung einer Entwicklungslinie zum Development Line Typ erfolgt über reguläre Ausdrücke, die auf den relativen Pfad der Entwicklungslinie zum Repository angewendet werden. Wenn keine Übereinstimmung gefunden wird, wird die Entwicklungslinie als Codeline typisiert. Für ein bereits bestehendes Subversion Projekt geht das natürlich nur, wenn man bereits bisher mit eindeutigen Bezeichnungen für Branches und Tags gearbeitet hat. Nachstehend ist die Angabe der Patterns für das Beispiel der PatternDemos dargestellt. Relativer Pfad im SVN-Repo Patterns mit regulären Ausdrücken Mainline /trunk /trunk$ Task Branch Entwicklungslinientypen /branches/select-colorbranch /branches/translation /branches/select\-.* /branches/translation Bugfix Branch Feature Branch /branches/bug-fix-r1> /branches/bug-fix-r2> /branches/bug-fix2-r2> /branches/requirement1 /branches/requirement2 /branches/requirement3 /branches/bug\-fix\d*\-r\d+ /branches/requirement\d+ Release Branch /branches/release1.x /branches/[rr]elease\d+\..*

21 Getting Started Seite 23 von 44 Entwicklungslinientypen Relativer Pfad im SVN-Repo /branches/release2.x Patterns mit regulären Ausdrücken Product Release /tags/release1.0 /tags/release2.0 /tags /tags/release\d+\.\d+.* /tags$ Die Nutzung von regulären Ausdrücken zur Pattern-Definition ist detailliert hier beschrieben: Beim Anlegen eines neuen Produktes erfolgt die Zuordnung der Entwicklungslinien unter dem Link Pattern im Produktfenster. Die Eingabe der regulären Ausdrücke erfolgt im Eingabefeld unten mittig. Unter Test patterns hat der User die Möglichkeit, zu überprüfen, ob die eingegebenen Pattern den gewünschten Pfad im SVN-Repo finden. Abbildung 24: Testen der Development Line Pattern Die Zuordnung der Patterns erfolgt durch Klick auf den zum rechten Eingabefenster weisenden Pfeil und das abschließende OK.

22 Getting Started Seite 24 von 44 Sofern man nicht schon Einstellungen unter Import from file importiert hat, können Pattern beim Anlegen weiterer Produkte automatisch durch Anwählen des Links Copy patterns from other product von einem bereits angelegten Produkt übernommen werden. Im sich öffnenden Dialogfenster wird das bereits angelegte Produkt bei PatternDemo_neu z. B. Product 1 (UnstableTrunk) - ausgewählt. Abbildung 25: Hinzufügen Development-Line-Pattern Vorbereitung der Synchronisation von Tasks Für die richtige Synchronisation der Tasks mit dem Modell ist für jedes Produkt eine Einstellung unter Preferences/Tasks im Kontextmenü (rechter Mausklick auf das Produkt) vorzunehmen. Die Informationen zu den Commits je Change Set auf den unterschiedlichen Entwicklungslinien werden aus den Commit-Messages gewonnen. Entsprechend dem verwendeten Format der Commit-Messages, insbesondere der Angabe der Task-ID, ist in den Preferences ein regulärer Ausdruck zu hinterlegen. Beispiele: Trac-Repository: Format Commit-Message: NEW - # 9: Modell: ItemProviderAdapter Pattern in Impact: Pattern in Impact: #(\d+): oder: - Impact findet die task-url..*#(\d+):.* - Impact findet die task-id. Da sich die URL des Trac Repositories ändern kann, ist jedoch die zweite Variante sinnvoller. Durch Eingabe einer existierenden Commit Message kann mit Klick auf Test

23 Getting Started Seite 25 von 44 überprüft werden, ob der verwendete reguläre Ausdruck geeignet ist, die Commit Messages im Trac Repository zu finden. Beim Anlegen eines Produktes werden unter dem Link Set Mylyn task pattern im Produktfenster die Task-Preferences aufgerufen. Nach Aktivieren des Kontrollkästchens Use Mylyn task pattern wird im Demo-Projekt.*# (\d+):.* als regulärer Ausdruck eingegeben. Abbildung 26: Festlegung regulärer Ausdrücke für Tasks Der Target Baseline initial eine Revision zuordnen Unter dem Link Active development line im Produktfenster oder unter dem Tab Repository lässt sich an die zuvor gewählte Baseline eine Softwarekonfiguration binden. Im Falle von Subversion ist dies eine Repository-URL, die auf einen Dateiordner mit zugehöriger Revisionsnummer zeigt. Bei einem kompletten Neuanfang wäre dies die Revision 1, bei Auswahl einer bestehenden Softwarekonfiguration ein definierter Stand, von dem aus man mit Impact CM-unterstützt weiterarbeiten möchte. Also wahrscheinlich ein Punkt in der Vergangenheit der Entwicklungsgeschichte einer Softwarekonfiguration. Zentrales Konzept innerhalb des Impact CM Modells sind in diesem Kontext Development Lines, die die Entwicklung von Softwarekonfigurationen in einem Repository repräsentieren. Abbildung 27: Verknüpfung Baseline mit Development Line Die Konfigurationselemente einer Development Line (aktive Entwicklungslinie) sind die primären Produktartefakte, die innerhalb des Entwicklungsschrittes vom Entwickler bearbeitet werden. Eine Entwicklungslinie kann über mehrere Baselines fortgeführt werden.

24 Getting Started Seite 26 von 44 Alternativ zur Auswahl einer existierenden Entwicklungslinie lässt sich eine neue Entwicklungslinie anlegen (Create a new development line = neuer Dateiordner im Head von Subversion), eine existierende Entwicklungslinie kopieren (Copy an existing development line = Kopie eines bestehenden Dateiordners = Branch), oder auf die Entwicklungsline einer Vorgänger-Baseline aufsetzen (Select a development line from other baseline = Konfiguration wird in aktueller Baseline fortgeführt). Im Impact CM Projekt PatternDemo_neu ist die Revision 1 von trunk Anfangspunkt für eine Impact-Unterstützung. Das entsprechende Produkt wird oben im erscheinenden Dialogfenster über Pull-Down-Menü ausgewählt. Beim Anlegen des ersten Produkts ist nur eine Produkt-URL auswählbar. Abbildung 28: Produktauswahl Mit linkem Mausklick auf das Feld rechts erscheint das Select-Fenster für die Auswahl der Revision. Die Default-Einstellung ist HEAD. Abbildung 29: Auswahl der Revision Im Hauptfenster werden durch Mausklick auf das Symbol vor dem Produkt die einzelnen Entwicklungslinien und Baselines des Produktes sichtbar. Die aktive Linie wird durch Mausklick markiert und durch finish ausgewählt.

25 Getting Started Seite 27 von 44 Abbildung 30: Auswahl der aktiven Development Line Anlegen des Produkts Durch Schließen des Produktfensters (Close) wird das Produkt angelegt. Die Vorbereitungen zur Synchronisation der Repositorien sind abgeschlossen. 4.4 Durchführen der Synchronisation mit dem Produktmodell Für eine Produktsynchronisation muss der Status der Baseline, die Ausgangspunkt der zu erfolgenden Synchronisation darstellt, auf open gesetzt werden. Das ist über das Kontextmenü (rechter Mausklick auf die Baseline) unter Set Status möglich. Abbildung 31: Setzen der Baseline auf Status Open Wenn ein Produkt mit close neu angelegt wurde, erscheint ein Dialogfenster mit der Frage: Do you want to import from Subversion now? Bei Klick auf Yes wird die Baseline automatisch auf Open gesetzt. Das Dialogfenster Synchronisation öffnet sich. Bei der Synchronisation wird die Historie des SVN-Repository ausgewertet und wesentliche Meta-Informationen werden in das Produktmodell geschrieben. Abbildung 32: Synchronisationsdialog mit Optionen

26 Getting Started Seite 28 von 44 Unter Preferences lassen sich zunächst die Voreinstellungen für die Synchronisations- Vorschau (Traverse SVN History) und die eigentliche Synchronisation (Import from SVN) wählen. Abbildung 33: Preferences für Synchronisation Preview Limit: Für Traverse gibt Preview Limit die maximale Anzahl von "change sets" (SVN log entries) an, die zur Berechnung eingelesen werden. Log Fetch Size: Ähnlich wie Preview Limit wird durch diese Größe die Anzahl der "change sets" definiert (chunks), die während der eigentlichen Synchronisation sequentiell verarbeitet werden. Commit Size: Während der Synchronisation wird das erzeugte KM-Modell in einer In-Memory- Datenbank-Session gehalten. Nach der durch Commit Size festgelegten Anzahl von Modelländerungen wird die Session in der Datenbank persistiert und anschließend geschlossen. Dadurch wird der Speicher wieder freigegeben und kann mit einer neuen Session wieder aktuell gefüllt werden. Start with Head: Bei Start with Head beginnen die Vorschau und Synchronisation ab der zuletzt höchsten (max) eingelesenen Revision. Z.B. Projekt A wurde von Revision bis importiert. Bei erneuter Synchronisation wird dann ab Revision (Head) nach neuen Änderungen im Repository gesucht. Vielleicht möchte man aber ein weiteres Projekt B hinzunehmen, das schon bei Revision beginnt. In diesem Fall muss die SVN-Historie noch einmal ab Revision durchlaufen werden, um auch die Projekt B betreffenden Metainformationen einzulesen. Resolve Artifacts: Für einen schnellen Import ist standardmäßig die Synchronisation der Task-Title ausgeschaltet, es werden zunächst nur die Taskzuordnungen anhand der Task-Patterns synchronisiert. Steht das Task-Repo über eine schnelle Verbindung mit dem Impact CM Server in Verbindung, lässt sich die Synchronisation der Tasks hier gleich mit einschalten. Die Tasks können aber auch ohne weiteres zu einem späteren Zeitpunkt nachsynchronisiert werden.

27 Getting Started Seite 29 von 44 Mit Klick auf Traverse SVN History wird die Historie im Schnelldurchlauf probeweise gescannt und das Ergebnis in der Synchronisationsübersicht angezeigt. Was man in der Übersicht sieht, sind u.a. die entscheidenden Zeitpunkte, zu denen Entwicklungslinien abgespalten und wieder zusammengeführt werden, bzw. zu denen ein Release erstellt wurde. Abbildung 34: Synchronisations-Vorschau Es erfolgt bereits beim Probelauf die Baseline-Zuordnung entsprechend den zugeordneten Development-Line-Patterns, abzulesen in der Spalte Source Development Line. Die gecheckte Option Hide Ignored unterdrückt die Development Line Typen, die als zu ignorieren in den Patterns angegeben wurden. Die vorletzte Spalte beinhaltet die jeweiligen Ziel-Entwicklungslinien in Bezug auf Branches, Merges und Releases. Die Synchronisation wird über Import from SVN gestartet. Abbildung 35: Start der automatischen Synchronisation Soll nur ein Teil der Entwicklungsgeschichte synchronisiert werden, kann unter dem Revision Button oben rechts im Fenster eine Revision angegeben werden, bis zu der die Synchronisation erfolgen soll. Per Default ist dort HEAD eingestellt.!achtung! Bei großen Repositories kann der Import ins Modell einige Zeit dauern. Entscheidend für die Laufzeit des Sync ist die Anzahl der committeten Dateien über die Anzahl zu synchronisierender Revisionen. Insofern macht es unter Umständen Sinn die Synchronisation Stück für Stück durchzuführen bzw. sich nur auf einen ausgewählten Abschnitt zu beschränken. Es fließen neben den Entwicklungslinien-Typen, der Baselinezuordnung nun auch die Merge- und Task-Zuordnungen mit ins Produkt-Modell ein.

28 Getting Started Seite 30 von 44 Eine erste Übersicht hinsichtlich des synchronisierten Modells kann man sich im Produktkontextmenü unter dem Punkt Overview verschaffen, via Refresh ist die Ansicht zunächst zu aktualisieren. Abbildung 36: Überblick synchronisiertes Modell In der Spalte Total Tasks wird die Anzahl der jeweils einer Baseline zugeordneten Tasks ausgewiesen. Das Anlegen weiterer Produkte kann erleichtert werden, indem die Einstellungen unter Patterns und Set Mylyn task pattern des bereits angelegten Produkts exportiert und als Vorlage für andere Produkte wieder importiert werden. Rechter Mausklick auf das Produkt im Inventory ermöglicht im Kontextmenü die Auswahl Preferences -> Export. Ein Dialogfenster bietet die Eingabe eines Dateinamens sowie die Auswahl eines Speicherorts an. Unter dem Punkt Add Product/Import from file können diese Einstellungen für neu anzulegende Produkte übernommen werden. Unter Patterns muss der Link Copy patterns from other product nun nicht mehr aktiviert werden, da bereits alle Einstellungen kopiert wurden. Als Speicherort kann der Ordner impact gewählt werden. Im Übrigen muss beim Hinzufügen von Product 2 (StableTrunk) und Product 3 (AgileRelease) genauso wie bei Product 1 vorgegangen werden. Die Repository-URL für Product 2 (StableTrunk) ist die für Product 3 (AgileRelease) Alle angelegten Produkte sind im Inventory sichtbar.

29 Getting Started Seite 31 von 44 Abbildung 37: Produkte im Inventory Im Inventory lässt sich erkennen, dass die Regel gegriffen hat, bei einem Release-Tag die aktuelle Baseline zu releasen (Release Basline 1), dann zu schließen, eine neue Baseline (Baseline 3) anzulegen und in den Status Open zu versetzen, und mit dieser fortzufahren. 4.5 Vorschau Entwicklungslinienkopien zur Erleichterung des Setup Soll ein fremdes Repository eingelesen werden, dessen Konfigurationsmanagementkonzept nicht bekannt ist, wird die Administration des DLD durch eine Repo-Analyse- Funktion zur Ermittlung der Konfigurationswerte Startrevision und Entwicklungslinienpatterns unterstützt. Man kann mit dieser Funktion bei gegebener Entwicklungslinie die tatsächlich im SVN- Repository durchgeführten Kopieroperationen ermitteln, vorwärts oder rückwärts über die Zeit. Die dabei entstandene Übersicht erleichtert die Einstellung von Entwicklungslinien- Patterns und -Typen, sowie die Auswahl einer sinnvollen und gültigen Startrevision für die Anzeige eines DLD. Die Funktion steht über den SVN Repositories-View im ImpactCM-Desktop zur Verfügung. Man wählt eine SVN-Entwicklungslinie aus, die den Ausgangspunkt für die Analyse bilden soll, im Regelfall wird man den jüngsten Tag oder Branch wählen und dann die Kopieroperationen rückwärts verfolgen. Mit Selektion der Entwicklungslinie wird bei Aufruf des Kontextmenü-Dialog der Menüpunkt Copied From/To aktiv.

30 Getting Started Seite 32 von 44 Abbildung 38: Kontext-Menü Copied From / To Bei Bestätigung der selektierten Entwicklungslinie wird ein Look-Up-Window geöffnet, welches das selektierte Repository, die selektierte Entwicklungslinie und Radio-Buttons für die Optionen Copied From und Copied To beinhaltet. In den unteren Bereich des Look-Up-Window ist eine Tabelle für die Darstellung der Suchergebnisse in Form einer verketteten Liste integriert, siehe nachstehende Abbildung. Abbildung 39: GUI-Layout Bestätigungs- und Ergebnisbildschirm

31 Getting Started Seite 33 von 44 Bei Bestätigung mit Start wird die Analyse des Repos gestartet und ausgehend von der Revision für die selektierte Entwicklungslinie die SVN-History reverse nach SVN-Copy- Operationen durchsucht. Während der Analysephase, die je nach Anzahl der zu untersuchenden Revisionen und Größen der daran hängenden Change Sets, eine Weile dauern kann, wird eine Infobox mit dem Analysefortschritt (Anzeige der jeweils in Analyse befindlichen Revisionen) eingeblendet. In der Ergebnistabelle werden alle SVN-Copies in der Form Ziel <- Quelle inkl. Revisionen angezeigt. Abbildung 40: Ergebnisbildschirm mit verketteter Liste Die als verkettete Liste dargestellten SVN-Copy-Informationen können durch Aufruf der View-Funktion als Entwicklungsliniengraphen dargestellt werden. Abbildung 41: Graphische Vorschau der Kopieroperationen Bei alternativer Wahl der Option Copied To wird die SVN-History ausgehend von der Revision für die selektierte Entwicklungslinie forward nach SVN-Copy-Operationen durchsucht.

32 Getting Started Seite 34 von 44 5 Aktive Konfigurationssteuerung mit Impact CM 5.1 Planung neue Baseline Voreingestellter Baseline Workflow Über Impact CM werden Produkte im Sinne von Systemkonfigurationen gesteuert. Das Prinzip ist dabei die Synchronisation des in Impact CM modellierten CM Domainenmodells mit den Objekten der realen Welt. Der zentrale Ausgangspunkt aller Aktivitäten in Impact CM ist das Produkt. Dem Produkt wird zunächst eine Target Baseline zugeordnet, die die zu planende Bezugskonfiguration für Entwicklung und Weiterentwicklung des Produkts bildet. Mit der Target Baseline wird eine konkrete Systemkonfiguration verknüpft und initial synchronisiert. Entsprechende, für diese Target Baseline umzusetzende Tasks können darauf basierend geplant werden. Abbildung 42: Produkt-/Baseline-Zyklus Impact CM Die Planung erfolgt über die Zuordnung von Tasks zur in Planung befindlichen Baseline. Die Tasks (im Sinne von Change Requests) werden im zugehörigen Change Management Werkzeug erfasst. Mit der Zuordnung wird der Funktionsumfang der Target Baseline festgelegt. Mit der Abarbeitung der Tasks entstehen Change Sets in Bezug auf die ursprüngliche Systemkonfiguration. Die Synchronisation der Änderungen an den Konfigurationselementen der realen Welt entsprechend der zur Baseline gehörenden Tasks mit dem Modell in Impact CM erfolgt kontinuierlich. Sind alle Change Requests für die Baseline abgearbeitet und getestet, dann wird sie geschlossen und bei entsprechender Qualität und Freigabe als released gekennzeichnet.

33 Getting Started Seite 35 von 44 Abbildung 43: Übersicht Baseline Workflow Neue Baseline anlegen Die Anlage der zugehörigen Baseline erfolgt per rechtem Mausklick über das Kontextmenü. Abbildung 44: Anlage Baseline zum Produkt über Kontextmenü

34 Getting Started Seite 36 von 44 Eine Baseline zum Produkt ist nun angelegt und befindet sich im Status Planned. Eine Baseline durchläuft verschiedene Status, von der Planung bis zur Freigabe: Planned - Baseline in Planung, es werden der initiale Stand der Systemkonfiguration und die für diese Baseline umzusetzenden Tasks zugeordnet. Open - Baseline in Bearbeitung, die geplanten Tasks werden umgesetzt, d.h. es wird entsprechend der Tasks an der ursprünglichen Systemkonfiguration gearbeitet. Closed Baseline ist geschlossen und unveränderbar. Es lassen sich keine Tasks mehr ändern, Sytemkonfiguration + Tasks werden eingefroren. Erfüllt die Baseline bestimmte Qualitätskriterien so kann sie als Released markiert werden. Es kann stets nur eine aktive Baseline pro Entwicklungslinie geben (Status Open), d.h. eine neu angelegte Baseline (Status Planned) zum Produkt kann erst dann in den Status Open befördert werden, wenn die vorherige geschlossen wird (Status Closed) Einer Baseline Change Requests zuordnen Change Requests (oder auch Tasks) sind der Anlass für die Planung einer neuen Baseline (eines Release). Der Konfigurationsmanager übernimmt die Änderungsanforderungen aus dem angekoppelten Change Management Werkzeug und ordnet sie der gewünschten aktiven Baseline (Status Planned oder Open) zu. Dazu ist zunächst unterhalb des Folders Tasks zur ausgewählten Baseline per rechtem Mausklick eine Task-Category (Requirements, Bugs, etc.) anzulegen. Abbildung 45: Anlegen einer Category für Baseline 5 Abbildung 46: Zuordnung Change Request (Ticket 11) zu Baseline, Schritt 1

35 Getting Started Seite 37 von 44 Abbildung 47: Zuordnung Change Request zu Baseline 5/ Category 1, Schritt 2 Die Change Requests werden in Impact CM derzeit ausschließlich über Mylyn verfügbar gemacht. In der entsprechenden von Mylyn bereitgestellten Task List (Hauptmenüleiste/Window/Show View/other/Impact/Tasks/Task List) markiert man die gewünschte Task und ordnet sie per rechtem Mausklick via Add To Baseline der in Planung befindlichen Baseline zu. Nun sind alle wesentlichen Schritte absolviert, die ein modellsynchrones Arbeiten an der Softwarekonfiguration erlauben. Das Ganze macht insbesondere Sinn, wenn der Entwickler in seiner Entwicklungs- Umgebung (Eclipse) unter Angabe der Baseline auf die zu einer bestimmten Baseline gehörenden Task zugreifen kann. 6 Impact CM aus Entwicklersicht (Eclipse PlugIn) 6.1 Development Line Diagram via Eclipse IDE einsehen Entwickler können die DLD auch über ihre IDE Eclipse einsehen und interaktiv mit ihnen arbeiten. Unter anderem ist das Bearbeiten einer Task aus dem Diagramm heraus möglich, das Einstellen der Informationstiefe für das Diagramm, das interaktive Mergen und einiges mehr. Die Funktionen des ImpactCM Eclipse PlugIn sind aus der Eclipse IDE heraus im Project Explorer View über das Kontextmenü erreichbar.

36 Getting Started Seite 38 von 44 Abbildung 48 Kontextmenü im Project Explorer View Das DLD ist in der Eclipse IDE als View verfügbar. Die Elemente des DLD und die verschiedenen Standardinteraktionsmöglichkeiten sind im Kapitel 3.2 beschrieben. Abbildung 49 View Development Line Diagramm (Merge) in Eclipse 6.2 Grafisches Mergen über das DLD in der Eclipse IDE Das Eclipse PlugIn ermöglicht es die zu einer Task gehörenden Commits direkt aus dem Entwicklungsliniendiagramm heraus von einer Entwicklungslinie in eine andere zu mergen. Voraussetzung dafür ist ein konsequent taskbasiertes Arbeiten. Ein ordnungsgemäß konfiguriertes PlugIn vorausgesetzt, lässt sich ein graphischer Merge via Eclipse wie folgt durchführen. Der Entwickler wählt innerhalb der Eclipse IDE das Repository und die Entwicklungslinie aus, in die gemergt werden soll. Diese Entwicklungslinie muss up to date sein (Voraussetzung für einen Merge generell). Im nächsten Schritt ist das DLD via Kontextmenüpunkt Show Development Line Diagram aufzurufen.

37 Getting Started Seite 39 von 44 Im DLD ist in der Quell-Entwicklungslinie die zu mergende Task auszuwählen und durch einen zusätzlichen Klick auf das Merge-Symbol anzugeben, dass sie gemergt werden soll. Merge Symbol Abbildung 50: Entwicklungsliniendiagramm mit für Merge selektierter Task im Wartungsbranch Wird der Merge auf vorgenannte Weise ausgelöst, wird ein Bestätigungsfenster geöffnet: Abbildung 51: Bestätigungsfenster für interaktiven Merge Stimmen die Informationen für Zielentwicklungslinie (Target) und die für die zu mergende Task ausgewiesenen Revision(en), so kann der Merge über die Schaltfläche Merge bestätigt werden. Der Merge wird dann wie üblich im Workspace ausgeführt, eventuelle Konflikte sind aufzulösen und via SVN Commit ins Repository zu übernehmen. Um generell alle Commits zu einer Task auf einer Entwicklungslinie für einen Merge zu selektieren, ist die betreffende Task auszuwählen und zusätzlich das Symbol für die Selektion aller Commits zur Task zu klicken, siehe nachfolgenden Screenshot

38 Getting Started Seite 40 von 44 Abbildung 52: Auswählen aller Commits/ Revisionen zu einer Task Es werden alle Commits zur Task, genauer die betreffenden Task-Symbole, auf der Entwicklungslinie selektiert und beim Ausführen des Merge entsprechend mit berücksichtigt. Möchte man alle Tasks einer Entwicklungslinie für den Merge auswählen, so ist dies analog vorbeschriebenem Verfahren über die Anwahl des Symbols für Branch-Reintegration möglich. Abbildung 53: Auswählen aller Commits/ Revisionen auf einer Entwicklungslinie (Reintegration) Es erscheinen entsprechend alle Tasks auf der Entwicklungslinie als ausgewählt. Abbildung 54: Für Merge selektierte Tasks auf einer Entwicklungslinie und Merge Info 6.3 Development Line Diagram via Eclipse IDE aktualisieren Das Development Line Diagram kann für die Anzeige kürzlich vorgenommener Subversion-Commits direkt aus der Eclipse IDE heraus synchronisiert werden. Für die Synchronisation wird eine Verbindung mit dem zentralen ImpactCM DLD Server aufgebaut, der das aktualisierte DLD zurückgeliefert. Dh. Dieser muß zunächst

39 Getting Started Seite 41 von 44 aufgerufen und über das Startsymbol (Start Jetty) gestartet werden: Abbildung 55: Aufruf Start ImpactCM DLD und Start des Jetty Web Server Nun kann über das Eclipse-Kontextmenü zum Repository für die bereits im Modell enthaltenen Entwicklungslinien im Sinne einer Aktualisierung synchronisiert werden. Abbildung 56: Synchronisation des Entwicklungsliniendiagramms via Eclipse-GUI Wurde bspw. Task #26 in den Trunk gemergt, ist nun nach der Synchronisation im Delevopment Line Diagram der Merge zu sehen (Mergepfeil von Revision 5 nach Revision 6). In der Mergeinfo ist die Task als Already integrated markiert.

40 Getting Started Seite 42 von 44 Abbildung 57: Development Line Diagram nach Synchronisation mit aktueller Mergeinfo 6.4 Konfigurationsoptionen für den interaktiven Merge Im ImpactCM Desktop lassen sich über die Preferences-Einstellungen unter Tasks/ Merge] pro Produkt Merge-Optionen setzen. Abbildung 58: Konfigurationsoptionen für einen interaktiven Merge Mit der ersten Option gibt man an, dass nur abgeschlossene Tasks gemergt werden dürfen. Die zweite Option sollte aktiviert werden, wenn immer alle Commits bzw. Revisionen zu einer Task gemergt werden sollen. 6.5 Konfiguration des DLD-Servers für die Synchronisation Unter Preferences/Impact ist die Datenbankverbindung für den betreffenden im ImpactCM Desktop konfigurierten Workspace einzustellen.