Rheinisch Westfälische Technische Hochschule Aachen Lehrstuhl

Rheinisch Westfälische Technische Hochschule Aachen
Lehrstuhl für Software Engineering
Seminararbeit
Release Management von Websystemen
Minh Tran
Matrikel-Nr.: 836326
Aufgabenstellung: Prof. Dr. rer. nat. B. Kraft
Betreuer: Claas Pinkernell
Aachen, den 15. Dezember 2011
iii
Kurzfassung
Release Management wird in der Software Entwicklung immer populärer. Die genaue Planung von Release- und Deoploymentprozessen kann Entwicklern und Unternehmen viel
Zeit und Geld einsparen. In Dieser Arbeit wurden Anforderungen an Release Management Systemen erörtert und einige Release Management Systeme evaluiert. Anschließend
wurden die evaluierten Systeme auf die Anforderungen des Energie Navigators getestet.
Viele dieser Systeme sind jedoch nur auf Spezielle Projekt Infrastrukturen ausgerichtet
und nicht Konfigurabel. Dadurch ist es schwierig in ein bestehendes Projekt solch eine
Infrasturktur aufzusetzen.
Abstract
Release management is becomeing increasingly popular in software development. The exact
planning of release and deployment processes can save much time and money to software
engineers and companies. In this thesis I discussed release management system requirements and tested some release management systems. Subsequently the evaluated systems
were tested towards requiremnts of the Energie Navigator project. Many of these systems
focus on special kinds of infrastructure and are not configurable. This makes it difficult to
set up these systems to existing projects and infrastructures.
v
Inhaltsverzeichnis
1 Einleitung
1
2 Release Management
2.1 Der Release Management Prozess . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Release Management Systeme . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
3 Anforderungen eines Release Management Systems
3.1 Versionsverwaltung (R1) . . . . . . . . . . . . . .
3.2 Branching und parallele Entwicklung (R2) . . . .
3.3 Aglie Methoden (R3) . . . . . . . . . . . . . . . .
3.4 Release einzelner Komponenten (R4) . . . . . . .
3.5 Release zurück ziehen (R5) . . . . . . . . . . . .
3.6 Management multipler Instanzen (R6) . . . . . .
.
.
.
.
.
.
7
. 7
. 8
. 8
. 9
. 9
. 10
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
12
13
14
14
5 Release Management Systeme im Energie Navigator Projekt
5.1 Der Energie Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Anforderungen des Energie Navigators an ein Release Management System
5.3 Der Energie Navigator und Release Management Systeme . . . . . . . . . .
17
17
19
20
6 Zusammenfassung und Ausblick
21
Literaturverzeichnis
23
4 Technologien
4.1 Serena Release Manager . . . . . . .
4.2 Aldon Deployment Manager . . . . .
4.3 BMC Application Management Suite
4.4 Smart Bear AutomatedBuildStudio .
4.5 Software Deployment Tools . . . . .
4.6 Zusammenfassung . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
1 Einleitung
Die Planung von Software-Projekten und Releases kann für die Kosten und Qualität der
Ausgelieferten Software ausschlaggebend sein. Viele Unternehmen verlieren wegen nicht
ausreichender Planung viel Geld und können ihre Produkte nicht rechtzeitig ausliefern.
Ein wichtiger Teil der Projekt-Planung widmet sich deshalb auch der Ausführung und
Umsetzung von Software Releases. [Kri94] Der Software Release Prozess wird bei modernen Projekten immer komplexer und bereitet Software-Unternehmen immer häufigere und
größere Probleme. Unter anderem besteht Software nicht mehr aus nur einer Komponente,
sondern aus mehr und mehr kleineren Unter-Komponenten, die zusammen die Software ergeben. Bei einem Release müssen alle diese Unter-Komponenten und ihre Abhängigkeiten
in der richtigen Version in das System eingebaut werden, was bei steigender Anzahl der
Komponenten immer mühseliger wird. [HW03] Nachdem die Software gebaut wurde, muss
sie dem Benutzer bereitgestellt werden. Dies kann über CD-Roms, DVDs oder aber auch
über das Internet geschehen. [Bal]. Einige moderne Werkzeuge unterstützen Entwickler bei
dieser Aufgabe. Release Management Systeme. Diese Systeme übernehmen immer wiederkehrende Aufgaben, wie das Zusammenstellen der Software, auflösen der Komponenten
und Abhängigkeiten und das Bereitstellen (Deployment) der Software.
Im Rahmen meiner Seminararbeit wurden Anforderungen an Release Management Systemen gesammelt, Systeme recherchiert und gegen diese Anforderungen evaluiert. Im zweiten
Teil der Arbeit habe ich diese Werkzeuge gegen die Anforderungen des Energie NavigatorProjekts gestellt. Der Energie Navigator (ENA) ist ein Werkzeug, das im Gebäude Management automatisiert Sensor-Daten erfasst, aufbereitet und analysiert. Diese Analysen
werden durch vorher definierte Regeln und Metriken durchgeführt. Der Energie Navigator
ist eine Rich-Client Applikation, die ihre Berechnungen jedoch auf einem Bereitgestellten
Web-Server ausführt. Alle Daten werden auf diesem Server gespeichert [FKP+ 10].
Diese Arbeit ist wie folgt gegliedert: in Kapitel 2 wird der Release Management Prozess
und Release Management Systeme definiert und erörtert, warum es überhaupt sinnvoll
ist Release Management anzuwenden. Das dritte Kapitel beschreibt dann die Anforderungen die einem Release Management System gestellt werden und die Vor-/Nachteile
solcher Systeme. Kapitel vier wird darauf aufbauend einige bestehende Systeme miteinander Vergleichen und Evaluieren. Wohingegen das fünfte Kapitel diese Systeme gegen den
ENA-Kontext stellt und evaluiert welche sich für unser Projekt eigenen und welche nicht.
Zum Schluss wird im sechsten Kapitel diese Arbeit abschließend zusammengefasst und
einen Ausblick auf weitere Arbeiten gegeben.
1
2 Release Management
In diesem Kapitel werden Grundbegriffe erklärt und eine kurze Einführung in das Release
Management und die dazugehörenden Prozesse gegeben. Viele Software-Unternehmen verwenden bereits einige Komponenten des Release Managements ohne zu wissen was Release
Management überhaupt ist und wie Prozesse eingeordnet werden.
2.1 Der Release Management Prozess
Viele Software-Unternehmen entwickeln ihre Software den Release Prozess ausführlich zu
planen. Was für Abhängigkeiten hat die Software? Wie wird sie an den Kunden gebracht?
Wie werden Updates und Bugfixes an die Nutzer verteilt? Solche Probleme sind jedoch
nicht trivial und können Unternehmen viel Geld und Zeit kosten. Release Management
befasst sich mit genau diesen Fragen und versucht das Auftreten solcher Probleme zu
vermeiden. Jedoch ist Release Management ein Prozess, der nicht erst am ende der Entwicklungsphase eintritt, sondern bereits am Anfang der Projektplanung eine Rolle spielt.
Software release management [...] is the process through which software is
”
made available to and obtained by its users.“ [HHHW97]
Diese Definition von van der Hoek bescheibt das Ziel von Release Management: Software
für Benutzer zugänglich zu machen. Um dieses Ziel zu erreichen werden zunächst einige
Teilprozesse benötigt.
Abbildung 2.1 zeigt, wie die Planung eines Releases nach der Information Technology
Infrastructure Library (ITLI ) aussehen sollte und in welchem Entwicklungsstadium die
einzelnen Teilprozesse betrachtet werden sollten. Der Release Management Prozess zieht
sich durch alle Phasen eines Software-Projektes, von der Planung bis zum tatsächlichen
Release. Ein Release frühzeitig zu planen ist vor allem wichtig, um den Anforderungen des
Kunden zu entsprechen, die im nächsten Release auf ein spezielles Feature angewiesen sind
oder auf Grund von Fehlern im Programm nicht weiter arbeiten können. Durch vorherige
Planung können Software-Entwickler Anforderungen und Fehler am Programmcode identifizieren und priorisieren, um diese bis zum Release abgeschlossen und getestet zu haben.
Diese Releaseplanung kann auch Feature-Freezes, das Sperren neuer Features, um Fehler in bereits vorhandenen Funktionen zu beheben und ausführlich zu testen, beinhalten.
Dadurch kann die Code Qualität vor einem Release deutlich gesteigert werden und die
Software somit stabiler gemacht werden. [WRGM08].
Sollten alle Tests erfolgreich durchgelaufen sein beginnt das Deployment. Deployment Management ist der letzte Teilprozess des Release Managements und beschreibt den Release
Prozess selber. Es wird beschrieben wie das Produkt an den Kunden geliefert wird oder
auf welchen Servern die Applikation deployed werden soll. In einigen Fällen muss das
Zielsystem vor und/oder nach der Installation des Produktes konfiguriert werden. Auch
das Produkt muss nach der Installation an das Zielsystem angepasst werden. Deployment
3
Management befasst sich mit vielen Problemen die beim Deployen auftreten können. Das
Release könnte trotz erfolgreicher Testphase scheitern, da viele neue Faktoren durch die
Zielsysteme hinzu kommen, die nicht alle in die Tests einbegriffen werden können. Des weiteren kann es erwünscht sein, dass das alte System bei einem Release nicht überschrieben
wird, sondern die neue Version auf einem neuen Server deployed wird. Jedoch kann auch
der gegenteilige Fall eintreten, dass ein oder mehrere laufende Systeme aktualisiert werden sollen. In diesem Fall kann es jedoch sein, dass sich das genutzte Datenbank-Schema
ändert. Um möglichen Datenverlust zu vermeiden müssen die alten Datenbankeinträge in
das neue Datenbank-Schema migriert werden.
2.2 Release Management Systeme
Um den Release Prozess zu verwalten und konfigurieren sind in den letzten Jahren einige
Release Management Werkzeuge entwickelt worden. Einige dieser Werkzeuge unterstützen
den gesamten Release Management Prozess (Release Management System), wobei andere
nur das Projekt Deployment verwalten (Deployment Management System). Erstere erleichtern die Release-Planung indem sie visuelle Benutzeroberflächen bieten um MeilensteinPläne zu erstellen und Bugfix- und Feature-Requests zu verarbeiten. Des weiteren bieten sie Tool-Unterstützung für Nightly Build- oder Continuous Integration (CI )-Systeme.
Diese Verfahren erstellen jede Nacht (Nightly Build) oder nach einem Commit in die Versionsverwaltung (CI) eine Instanz des aktuellen Stands der Software und führen Tests
durch. Somit können Entwickler des Systems feststellen, ob ihre Änderungen funktionieren und ob gegebenenfalls weitere Module von den Änderungen negativ betroffen sind.
Das Software Deployment wird dadurch vereinfacht, dass die Systeme sowohl direkte als
auch transitive Projekt-Abhängigkeiten verwalten und Deployment Server konfigurieren.
Projekt-Abhängigkeiten liegen oftmals in vielen Versionen zu Verfügung. Das Deployment
Management System ist in der Lage die richtigen Versionen aus vordefinierten Repositories
herunter zu laden und zu verwalten. Somit können verschiedene Versionen der Abhängig-
Release Management
Projekt
Planung
• Release Politik
• Release Planung
Entwicklung
• Entwicklung
• Soft- und
Hardware
• Weitere Release
Planung
Tests
• Release
Konfiguration
• Qualitäts-Review
• Akzeptanz Tests
• Verifizierung
Deployment
• Release
Ausführung
• Implementierung
Verifizieren
• Installation
Abbildung 2.1: Verschiedene Prozesse im Release Management [WRGM08]
4
keiten schnell und einfach ausgetauscht werden. [HHHW97, HW03] Web-Projekte liegen
oft nicht nur auf einem Server, sondern sind auf mehreren Servern verteilt, somit ist es
mühselig alle Server manuell zu aktualisieren. Viele Deployment Management Systeme
können dem Entwickler diese Aufgabe abnehmen und mehrere oder alle Server aktualisieren.
Auch wenn bei der Einführung solcher Systeme ein großer Mehraufwand entsteht, können
sie den Release Prozess sowohl für Entwickler als auch für Kunden vereinfachen. ReleaseZyklen können durch richtiges Management der Prozesse verkürzt und einfacher geplant
werden. Anforderungen des Kunden können in Meilensteinpläne aufgenommen werden und
somit vereinfacht geplant werden, welche Anforderungen beim nächsten Release erfüllt sein
sollten und wann das Release ausgeführt wird. Außerdem werden Build- und DeploymentInformationen gespeichert und können von Entwicklern abgerufen und automatisiert werden.
5
3 Anforderungen eines Release Management
Systems
Ein Release Management System einzuführen erfordert Zeit und Planung. Verschiedene
Release Managemen Systeme unterstützen verschiedene Werkzeuge und sind auf verschiedene Infrastrukturen angepasst. Jedoch gibt es allgemeine Anforderungen die solch ein
System erfüllen sollte. Im folgenden Kapitel werden einige Anforderungen definiert, auf
die Release Management Systeme evaluiert werden.
3.1 Versionsverwaltung (R1)
Viele Moderne Software-Projekte benutzen bereits Versionsverwaltungs Software, wie Subversion(SVN ) [sub11] oder Concurrent Versions System(CVS ) [cvs11] um ihre CodeArtefakte abzuspeichern. Solche Systeme ermöglichen es Artefakte einfach und schnell
mit dem ganzen Entwicklerteam zu teilen und die Software somit für alle Entwickler auf
dem gleichen stand zu halten. Ein weiterer Vorteil der Versionsverwaltung ist, dass Entwickler die Möglichkeit haben auf ältere Stände der Software zuzugreifen, Änderungen
einzusehen und sie gegebenenfalls wieder rückgängig zu machen. Ebenso ist es möglich
das Projekt auf mehreren Zweigen (Branches) zu entwickeln. [Pil04, Ves03] Abbildung
3.1 zeigt wie zum Beispiel die Entwickler des Energie Navigators branchen. Nach dem 1.0
Release wurde eine Kopie des gesamten Projekts auf einem anderem Branch erstellt, um
die 1.0 Version dort zu pflegen und Fehler zu beheben. Entwickler, die einen Bug beheben
möchten erstellen aus dem aktuellen Stand (Revision) des 1.0 Maintenance Branches eine
erneute Kopie des Projektes und beheben dort den Fehler. Danach kann der der Entwickler seine Änderungen von seinem Bugfix Branch aus in die beiden anderen Branches
übernehmen (mergen). So müssen Entwickler Fehler nicht auf allen Branches wiederholt
bearbeiten, sondern können über die Merge-Funktion der Versionsverwaltung Fehler auf
mehrere Branches beheben.
Bugfix 1 Branch
Bugfix 2 Branch
Merge
Merge
1.0 Maintenance Branch
1.0 Release
Merge
Merge
Trunk (Development Branch)
Abbildung 3.1: Das Branching im Energie Navigator
7
Diese Systeme können über Scripte oder dafür entwickelte Clients angesprochen und bedient werden, jedoch sollte ein Release Management System mit solchen Versionsveraltunssystemen interagieren können. Vor den Release muss der Code auf den aktuellen Stand
gebracht werden und nach dem Realease Änderungen im Konfigurations-Dateien, wie zum
Beispiel die Versionsnummer, wieder in die Versionsverwaltung eingespielt werden (Commit). Auch das erstellen von Branches nach einem Release sollte das von einem Release
Management System automatisch gelöst werden.
Release Management Systeme sollten Versionsverwaltungssysteme wie SVN oder CVS
unterstützen.
3.2 Branching und parallele Entwicklung (R2)
Wie im vorherigen Abschnitt erwähnt ist es wünschenswert nach einem Release einen
Bugfix Branch für die Software zu erstellen, damit instabile Features im Trunk nicht in
Bugfix-Releases auftauchen. Branches werden aber auch bei Produktlinien eingesetzt, bei
denen das anfängliche Projekt zwar das gleiche ist, die Unterschiede später jedoch immer
größer werden. Viele Software-Anbieter bieten zum Beispiel Test-Versionen ihrer Software
an. Diese Testversionen weisen meist weniger Funktionen auf, sind auf wenige Tage beschränkt oder beinhalten Werbung. Sowohl die Test-Version als auch die käufliche Version
müssen gepflegt und weiter entwickelt werden. Damit die Entwickler den gleichen Bugfix
nicht in beiden Versionen der Software wiederholen müssen, kann man Änderungen durch
Patches auf den jeweils anderen Entwicklungszweig übertragen. [Pil04] Umso weiter die
Entwicklung nach einem Release voran geht, desto größer werden aber die Unterschiede
im Code zwischen Trunk und Branch. Nach einiger Zeit wird es nicht mehr möglich sein,
Bugfixes ohne weiteres vom Branch in den Trunk zu mergen und Entwickler müssen diese
Bugfixes in beiden Programm Versionen getrennt durchführen. Einige Werkzeuge ermöglichen es Unterschiede zwischen den Branches anzuzeigen und gegebenenfalls Änderungen
herüber zu kopieren.
Release Management Systeme sollten also Produktlinien und Branch-Releases durchführen
und Branches erstellen und zusammenführen können. Dabei sollen diese auch die Versionierung dieser Releases übernehmen können.
3.3 Aglie Methoden (R3)
Eines der Modernen Softwareentwicklungsansätze sind Agile Methoden. Jeder Entwickler
ist für das gesamte System zuständig und kann gegebenenfalls an jeder stelle des Programms arbeiten, wenn ein Entwickler ausfällt oder seine Änderungen andere Module
des Systems beeinträchtigen. Eine weitere Besonderheit der Agilen Entwicklung ist, dass
das Programm zu jederzeit (aus der Versionsverwaltung heraus) upgedatetd und compiliert werden kann. [CLC03] Diese Eigenschaft ist besonders für Nightly Builds und CI
interessant. Diese Methoden verhindern zwar nicht, dass fehlerhafter Code in der Versionsverwaltung auftaucht wird, jedoch werden die Entwickler direkt gewarnt sobald dies
geschieht und haben die Möglichkeit aus den Build-Reports zu sehen wo der fehlerhafte Code auftaucht und wie er verursacht wurde. Ein solches System kann die Software Qualität
steigern, jedoch ist es ein zusätzlicher Aufwand eine solche Infrastruktur bereitzustellen.
8
CI und Nightly Build Reports sollten automatisch per e-Mail oder Instant Messenger an
die Entwickler geschickt werden. Diese Reports beinhalten sowohl Build-Logs, als auch
Test-Reports und gegebenenfalls Code-Coverage (inwiefern gibt es Tests für den Code)
und Code-Qualität. Builds werden auf extra dafür angelegten Maschinen durchgeführt.
Diese Maschinen sollten von Release Management Systemen verwaltet, CI und Nightly
Builds automatisch angestoßen, getestet und die Reports automatisch verschickt werden.
[DMG07] Dazu können bestehende Frameworks wie Hudson [hud11] oder Jenkins [jen11]
verwendet werden.
Da CI und Nighly Builds keine richtigen Releases sind, die Software wird nicht dem Kunden, sondern den Entwicklern bereitgestellt, der Programmcode dennoch kompiliert und
versioniert wird, soll das Release Management System diese Builds verwalten können.
3.4 Release einzelner Komponenten (R4)
Software besteht nicht immer aus nur einer einzigen Komponente, stattdessen ist es so,
dass Software aus immer mehr und mehr Komponenten zusammen gesetzt wird. Bei einem
Release möchte man jedoch nicht immer alle Software Pakete neu herausgeben, sondern
lediglich einzelne Teil-Komponenten ersetzen. Bei Web-Applikationen mit Rich-Client soll
es zum Beispiel möglich sein, nur den neuen Client zu releasen, wenn sich an dem WebServer nichts geändert hat. Jedoch kann auch der umgekehrte Fall erwünscht sein, nur die
Server-Applikation zu ändern, so dass die Client-Benutzer nichts davon mitbekommen.
Ebenso soll es jedoch auch möglich sein alle Komponenten zusammen zu releasen. Ein
Release Management System sollte erkennen, welche Komponenten oder Abhängigkeiten
sich geändert haben, um nur diese zu releasen. Dieses Vorgehen kann den Release Prozess
bei großen Projekten stark verkürzen, jedoch sollte der Entwickler die Möglichkeit haben, diese automatische Erkennung abzustellen und Komponenten releases zu erzwingen.
Bei manuellen Komponenten Releases kann es jedoch zu Versionskonflikten kommen, da
eine neue Client Version herausgekommen ist, der Server diese aber nicht unterstützt. Dadurch, dass Komponenten einzeln released werden können, können Release Zyklen weiter
verkürzt werden und wichtige Sicherheitsupdates schnell an die Kunden verteilt werden.
Bei kritischen Client Fehlern kann nur der Client neu released werden und umgekehrt.
[HHHW97, HW03]
Release Management Systeme sollten es den Entwicklern ermöglichen den Releaseaufwand
zu minimieren, und somit gegebenenfalls auch die kleinsten Komponenten eines Systems
voneinander getrennt zu Releasen.
3.5 Release zurück ziehen (R5)
Auch bei bester Qualitätssicherung kann es passieren, dass ein fehlerhaftes Release herausgebracht wird. In solchen Fällen soll das Release Management System in der Lage sein
alle oder nur einzelne Komponenten releases wieder zurück zu ziehen (Rollback ) und dem
Kunden die alte Version wieder vorzulegen. Dieser Schritt ist notwendig, falls die Fehler nicht direkt behoben werden können, die Kunden jedoch erwarten, dass das System
funktioniert. Dadurch wird verhindert, dass das System durch ein fehlerhaftes Release für
mehrere Tage ausfällt. Um eine solche Infrastruktur zu schaffen wird meist eine VersionsDatenbank verwendet. Das System erkennt anhand der abgespeicherten Versionen, welche
9
die letzte funktionierende Version war und spielt diese, als neue Version, wieder ein. Rollbacks sollen keine Dauerlösung sein, sondern dem Kunden ein System bieten, auf dem sie
Arbeiten können und den Entwicklern mehr Zeit bringen, Fehler zu beheben. [HW03]
Ein Release Management System sollte in der Lage sein ein Release Rollback auszuführen.
3.6 Management multipler Instanzen (R6)
Viele Web-Applikationen werden nicht nur auf einer einzigen Server Instanz gehostet,
vielmehr gibt es für jeden Kunden eine Server-Instanz auf der für diesen Kunden eingerichtete Applikationen und Webservices laufen. Nach einem Release müssen einige dieser
Maschinen auf die neue Version aktualisiert werden. Diese Maschinen werden meist von
einer Host Maschine verwaltet. Diese Host Maschine enthält eine Datenbank auf der alle
Server gelistet und den Kunden zugeordnet sind. Auf Bertriebssystemebene ermöglichen
es Virtuelle Maschinen mehrere dieser Server-Instanzen auf einem einzigen Physikalischen
Server zu hosten. Dieses System bietet die Möglichkeit diese Virtuelle Maschinen schnell
und automatisiert auszutauschen und somit die Downtime bei einem Systemfehler zu reduzieren. Außerdem können bei Bedarf automatisch neue Maschinen hochgefahren und
konfiguriert werden. Einige Systeme können von bereits existierenden Maschinen Klone
erstellen, die als Backup aktueller Server oder als Template für neue Maschinen dienen.
Des weiteren ist es möglich, dass das entwickelte System nicht auf einer einzigen Maschine
läuft, sondern Komponenten auf physikalischen, virtuellen und cloud Instanzen verteilt
wird und Daten zwischen den Instanzen transferiert werden. Das System wird dann auf
einem Rechner erstellt und dann auf die verschiedenen Maschinen verteilt. Solche Fälle
sollte ein Release Management System bearbeiten können, in der Lage sein die verschiedenen Maschinen zu verwalten und auf diesen zu deployen. Hierbei sollte es Windows, Linux
oder Unix basierte Systeme unterstützen.
10
4 Technologien
Im folgenden Kapitel werden einige Release Management Systeme auf die im vorigen
Kapitel definierten Anforderungen evaluiert.
4.1 Serena Release Manager
Serena Release Manager ist ein Release Management Werkzeugpaket, das den ganzen Release Management Prozess von der Projekt-Planung bis hin zum Deployment unterstützt.
Es bietet das Werkzeug Release Control um Workflow Diagramme und Release Kalender
zu erstellen, die aus dem Internet heraus abrufbar sind. So kann jeder Entwickler des Projekts einsehen wie weit das Projekt vom nächsten Release oder Meilenstein entfernt ist
und seine Arbeit genau planen. Ebenso ist es somit möglich abzuschätzen, ob das Projekt
der Zeit der Planung voraus oder zu spät ist.
Zusätzlich enthält es auch Release Automation, ein Werkzeug, das das Software Deployment für Entwickler stark vereinfachen und somit Zeit sparen soll. Dieses Werkzeug unterstützt automatische Releases auf verschiedenen physikalischen, virtuellen und cloud
Instanzen und soll Zeit und Kosten, die Entwickler benötigen ihre Software zu releasen,
um bis zu 75% verringern. [ser11] Das Tool testet die erzeugte Software vor einem Release
und verwaltet die Versionierung der einzelner Komponenten zentral um Versionskonflikte
schnell und einfach zu beheben. Sollte dennoch fehlerhafter Code released werden bietet
Serena Release Automation ein echtzeit Monitoring des Build Prozesses an und ist in der
Lage direkt ein Versions Rollback zu starten.
Das dritte Werkzeug des Werkzeugpaketes ist Serena Release Vault. Dieses Werkzeug hilft
den Entwicklern des Software Systems die Compilierbarkeit des Projektes zu gewährleisten,
indem es die Software automatisiert deployed, testet Reports erstellt. Entwickler können
über die Reports und Change-Logs einsehen, welche Änderungen am Programmcode zu
Fehlern führte. Entwickler können in Rollen und Zuständigkeiten unterteilt werden und
funktionierender Code kann für Entwickler gesperrt werden. Somit wird garantiert, dass
funktionierender Code nicht mehr verändert wird. Serena Release Vault ist sowohl für
Windows als auch für Linux und Unix Maschinen geeignet und unterstützt out-of-the-Box
Releases für andere Systeme.
Jedoch unterstützt Serena Release Manager kaum Dritt-Anwender Werkzeuge und erfordert, dass Benutzer die Versionsverwaltung und andere Werkzeuge von Serena anwenden,
um die Serena Infrastruktur vollständig zu nutzen. So müssen noch Serena PVCS Version
Manager und Serena Service Manager vorhanden sein.
4.2 Aldon Deployment Manager
Ein weiteres Werkzeug zur automatisierten Auslieferung von Software-Systemen ist der Aldon Deployment Manager. Dieses Werkzeug unterstützt vor allem den Deployment-Prozess
11
und kann Software automatisch auf Java Runtime Environment(JRE ) unterstützende Maschinen ausliefern. Dabei versioniert es die ausgelieferten Pakete selbstständig und generiert Log-Dateien, die den Vorgang Protokollieren. Voraussetzung dafür ist jedoch, dass
die Code-Artefakte der Software auf einem Server mit dem von Aldon bereitgestellten
Versionsverwaltungsystem, Aldon Lifecycle Manager, bereit liegen. Über diesen greift der
Deployment Manager auf den Code zu, der dann compiliert und versioniert wird. Der Aldon Lifecycle Manager unterstützt des weiteren Workflow Management Prozesse und erlaubt es rollenbasiert auf Programmcode zu zugreifen. Alle Änderungen im Programmcode
werden dokumentiert und können in Enwicklungs-, Test- oder Produktivstadien eingestuft
werden. Diese Infrastruktur ermöglicht es bereits funktionierenden und validierten Code
für Entwickler zu sperren und fehlerhafte Änderungen zu vermeiden.
Der Aldon Deployment Manager unterscheidet beim Compilieren eines Projekts drei Stufen: Integrations-, Test und Produktiv Builds. Integrationbuilds werden gebaut um die
Funktionalität einzelner Programm Komponenten zu testen und werden in der Regel direkt nach dem Commit eines Code-Stücks durchgeführt (CI Vorgehensweise). Die Tests
Builds, die etwas länger dauern testen darauf die Funktionalität zwischen den Software Komponenten und Klassen, um zu gewährleisten, dass die Programm Komponenten
auch gemeinsam funktionieren. (Nightly Build). Waren beide vorangehenden Tests positiv, kann nun ein Produktiv System gebaut werden, das in der Regel wiederum getestet
wird, um mögliche Fehler beim Kompilieren auszuschließen. Dieses Produktiv System wird
anschließend als Release herausgegeben und auf einem oder mehreren Produktiv Systemen
deployed. [ald11]
Beim Deployment ist Aldon Deployment Manager in der Lage die Software auf mehreren
physikalischen oder virtuellen Rechnern zu verteilen. Dabei spielt es keine Rolle, ob es ein
Windows, Linux oder Unix System ist. Der Benutzer kann den gesamten automatisierten
Prozess überwachen und ist zu jeder Zeit in der Lage, diesen Prozess anzuhalten oder
abzubrechen und bei Fehlern und Problemen ein Systemrollback durchzuführen.
4.3 BMC Application Management Suite
Das BMC Application Management Suite ist ein Werkzeug Paket, das aus zehn unabhängigen Werkzeugen besteht:
• Application Automation ist ein Tool, das Software Konfigurationen und Änderungen automatisiert, managed und kontrolliert.
• Middleware Automation unterstützt das Management und die Kontrolle von
Diensten und Anwendungen.
• Application Problem Solution dokumentiert Software Probleme in Form von
Tickets und Hilft bei der Reproduktion von auftretenden Bugs.
• Release Process Management Unterstützt Entwickler bei der Planung, Modellierung und Echtzeit-Verfolgung des Release-Prozesses.
• End-User Experience Management ist ein Feedback-Tool, um Benutzer-Daten
und Software-Performance in Echtzeit zu Überwachen.
• Orchestration hilft bei der Überwachung und beim Management von oft wiederholten Prozessen, Entwicklern und Technologien.
12
• CMDB liefert detaillierte und zeitnahe Daten über Mitarbeiter, Prozesse und Technologien.
• Discovery Entdeckt und managed automatisch die genutzte IT-Infrastruktur von
verteilten- oder Großrechner Systeme.
• Dashboards and Analytics ist ein Werkzeug, dass die IT Performance analysiert
und kritische Prozesse über eine einfache Benutzeroberfläche darstellt.
• Service Level Management unterstützt den kontinuierlichen Verbesserungsprozess und definiert und überwacht Service Levels.
Diese Werkzeuge werden alle von BMC vermarktet und unterstützen den gesamten Release Management Prozess. Jedoch ist es schwierig im Werkzeugpaket einzelne Werkzeuge
auszutauschen, da sie alle aufeinander aufbauen. Werden für einige dieser Tools bereits
andere Lösungen verwendet ist es nicht ohne weiteres möglich diese anstelle der von BMC
mit gelieferten Werkzeuge anzuwenden. [BMC11]
4.4 Smart Bear AutomatedBuildStudio
Das Smart Bear Automated Build Studio ist ein automatisches Build und Release Management System für .NET, Java und Windows Systeme. Es unterstützt Entwickler indem es
automatisiert CI Builds und Reports erstellt und diese per e-Mail oder Instant Messenger
(MSN oder ICQ) verschickt. Diese Builds können entweder zu einer vordefinierten Zeit
oder durch Events angestoßen und automatisch getestet werden. Sowohl Build- als auch
Testlogs werden auf der Reporting Übersicht angezeigt und analysiert. Die Konfiguration
der Builds geschieht über ein mitgeliefertes visuelles Interface oder direkt in Microsofts
Visual Studio.[Sma11b]
Smart Bear Automated Build Studio ermöglicht es Benutzern Makros zu erstellen, die
den Build Prozess anstoßen und Tests ausführen. Diese Makros können auf einer visuellen
Benutzeroberfläche erstellt werden und sowohl automatisiert oder manuell von der Maschine oder per Remote-Interface gestartet werden. Es ist möglich diese Makros konfigurabel
zu halten, um verschiedene Versionen des Projekts zu releasen und somit Redundanz zu
vermeiden. Somit können für CI und tatsächliche Releases die gleichen Makros benutzt
werden, denen jedoch unterschiedliche Parameter übergeben werden.
Das Automated Build Studio unterstützt eine Vielzahl an Compilern, Build Tools, Versionsverwaltungen und anderen Werkzeugen. Somit kann es sowohl mit den Compilern, die
in Microsofts Visual Studio mitgeliefert werden also auch mit Java oder Borland Delphi
Compilern umgehen. Versionsverwaltungen wie SVN, CVS oder Serena Dimensions CM
werden ebenso wie die Build Tools Apache Ant und Mircosoft MSBuild nativ unterstützt.
[sma11a]
Smart Bear Automated Build Studio ist ein sehr flexibles und gut Konfigurierbares Release
Management Tool, das viele oft bereits genutzte Entwicklungswerkzeuge unterstützt und
mit anderen Release Management Werkzeugen kombiniert werden kann. Es liefert eine
eigene Makro-Sprache mit, mit der Prozesse einfach konfiguriert und automatisiert werden
können. Jedoch unterstützt es in der aktuellen Version nur Windows Systeme und keine
Linux oder Unix Maschinen.
13
4.5 Software Deployment Tools
Software Deployment Tools unterstützen Software-Entwickler speziell im Deployment Prozess und bei der Auslieferung beim Endbenutzer. Diese Software kann genutzt werden wenn
große Teile des Release Managements bereits von anderen Werkzeugen unterstützt werden.
Häufig genutzte Deployment Management Werkzeuge sind:
• Installshield ist ein speziell für Windows Applikationen ausgelegtes Werkzeug, dass
aus Programmcode Windows Installations Dateien erstellt (.msi Dateien). Das Tool
erstellt die für Windows Benutzer typischen Installer und vereinfacht so das Installieren der Applikation für den Endbenutzer. Entwickler können auch Patches und
Updates über das Installshield ausliefern und verschiedene Versionen der Applikation
erstellen lassen (Testversion, Premiumversion etc.) [ins11]
• Ant Build Scripts Ant Scripts werden in der Regel von Entwicklern geschrieben
um den Build Prozess einer Software zu automatisieren. Ant wird durch XML Scripte
gesteuert, die den Java Compiler oder System-Programme aufrufen können. Diese
Scripts sind jedoch sehr schwierig zu warten und sehr fehleranfällig, da sie von Hand
geschrieben werden müssen und bei großen Projekten sehr lang werden können.
[ant11]
4.6 Zusammenfassung
Viele Release Managemant Systeme unterstützen den Release Management Prozess stark
und entsprechen vielen allgemeinen Anforderungen (siehe Tabelle 4.1).Dadurch, dass das
Release einzelner Komponenten eines der größten Motivationen ist, Release Management
zu betreiben und solche Software zu nutzen, sind alle evaluierten Release Management Systeme dazu in der Lage. Agile Mehtoden werden in Software Unternehmen immer weiter
verbreitet und werden auch von allen getesteten Werkzeugen unterstützt. Auch die Verwendung einer Versionsverwaltung ist in Software Projekten üblich, jedoch gibt es dafür
viele verschiedene Lösungen. Einige der getesteten Systeme nur die Versionsverwaltungssoftware aus dem eigenen Haus und lassen Open Source Lösungen und Lösungen anderer
Unternehmen außen vor, was Benutzer dieser Systeme dazu zwingt die Versionsverwaltungen der jeweiligen Unternehmen zu verwenden. Die Verwaltung multipler Instanzen
Serena Release Manager
Aldon Deployment Manager
BMC Application Manager Suite
Smart Bear Automated
Build Studio
Installshield
Apache Ant
R1
X
X
R2
X
X
R3
X
X
R4
X
X
R5
X
X
R6
X
7
Preis
Auf Anfrage ($125,000)
Auf Anfrage
X
X
X
X
X
7
Auf Anfrage
X
X
X
X
X
X
Auf Anfrage ($349)
X
X
X
(X)
7
(X)
X
X
7
7
7
7
Professional: 1,789 e
Open Source
Tabelle 4.1: SRMs
14
auf sowohl physikalischen als auch virtuellen und cloud Maschinen ist in der Informations Technologie noch jung und wird noch nicht von vielen Systemen Unterstützt. Jedoch
ist dies vorallem im Deplyment Management ein wichtiger Punkt, der Entwicklern viel
Zeit einsparen kann. Dadurch dass Release Management Systeme noch nicht sehr populär
sind, ist der Preis solcher Systeme sehr hoch und Open-Source Lösungen sind noch nicht
gegeben.
Obwohl viele Anforderungen erfüllt sind, ist es, vor allem in großen Unternehmen, schwierig ein Release Management System einzuführen, da viele Unternehmen bereits andere
Software benutzen, die zwar Teile des Release Management Prozesses unterstützen, jedoch nicht alle. Da diese Unternehmen jedoch nicht ihre vollständige Infrastruktur an das
Release Management System anpassen wollen, müssen geeignete Systeme für die Infrastruktur gefunden werden.
15
5 Release Management Systeme im Energie
Navigator Projekt
In diesem Kapitel wird die Infrastruktur des Energie Navigator Projekts beschrieben und
die vorgestellten Release Management Systeme entgegen der Anforderungen des Energie Navigators evaluiert. Dazu wird erst einmal eine Einleitung die die Projekt Domäne
gegeben und danach darauf basierend Anforderungen definiert und evaluiert.
5.1 Der Energie Navigator
Viele moderne Gebäude enthalten mehr und mehr Sensoren. Diese Sensoren sammeln und
messen Daten, die den Energieverbrauch dieser Gebäude widerspiegeln und analysieren
können. Diese Sensordaten müssen bevor sie ausgewertet werden können, erst einmal aufbereitet und mögliche Fehlmessungen korrigiert werden. Der Energie Navigator ist ein
Werkzeug dass diese Sensordaten, wie in Abbildung 5.1 dargestellt, automatisiert oder
manuell importiert, aufbereitet und analysiert. Gebäude-Manager können über den ENAClient Anlagen, Regeln, Funktionen und Metriken spezifizieren, die das Gebäude und
optional
Data Import
Building
Preprocessing
automatic
manual
filter
standard.
types
scale
normalization
outlier
detection
counter
interpolation
equidist.
timesteps
User
Expert
Reporting
rule based
userdefined
reporting
pattern based
expert comments
visualisation
Specification
rules
Analysis
 carpet plots
 line plots
 scatter plots
 performance
charts
functions
characteristics
metrics
time routines
facility architecture
data export
ticket system
DBS
Abbildung 5.1: Die Module des Energie Navigators [FKP+ 10]
17
Abbildung 5.2: Regel-Definition und Visualisierung im Energie Navigator Projekt
dessen Soll-Stände beschreiben und die importierten Sensordaten entgegen dieser berechnen und analysieren lassen.[FKP+ 10] Ausgewertete Sensoren und Berechnungen können
anschließend exportiert und über so genannte Carpet- oder Line-Plots visualisiert werden
[FPPR10]. Jedoch hilft der Energie Navigator nicht nur beim auswerten und messen von
Sensorwerten, sondern hilft Energieexperten auch bei der Gebäude Planung, Errichtung
und Optimierung [FLP+ 11].
Der Projektschwerpunkt des Energie Navigators liegt in der Rich-Client Applikation, über
die sich Sensoren importieren und visualisieren lassen. Abbildung 5.1 zeig einen Screenshot
dieser Applikation mit in Carpet-Plots visualisierten Sensordaten. Diese Sensordaten werden von der Client-Applikation von einem von Energie Navigator bereitgestellten Webserver heruntergeladen und können Weltweit von autorisierten Personen abgerufen werden.
Ebenso lassen sich Graphen, Sensordaten und Energieausweise auf bestimmten Webseiten
anzeigen und Gebäudeoptimierungs Maßnahmen diskutieren. [FKP+ 10]
Das Software-Projekt ist bereits in der Version 1.0.2 für registrierte Kunden verfügbar.
Nach dem 1.0 Release wurde das Projekt in der Versionsverwaltung in einen weiterEntwicklungszweig (Trunk ) für neue Funktionen und einem Bugfix-Zweig (maintainanceBranch) geteilt. Die Releases wurden bisher über selbst geschriebene Linux Bashscripts
herausgebracht, die jedoch schwer zu warten und auf einem aktuellen Stand zu halten sind.
Um Release Zyklen zu verkürzen und Bugfixes schneller herauszugeben ist es gewünscht
den Release Prozess zu definieren und ein Release Management System einzuführen.
18
5.2 Anforderungen des Energie Navigators an ein Release
Management System
Der Energie Navigator ist bereits in einer späten Phase des Projekts und nutzt bereits einige Werkzeuge, die einige Teile des Release Managements bedecken. Viele Release Management Systeme setzen voraus, dass andere Tools, wie Versionsverwaltung, genutzt werden.
Um möglichen overhead bei einem Umstieg solcher Tools zu vermeiden, wird vorausgesetzt, dass das verwendete Release Management System die bereits genutzten Werkzeuge
unterstützt. Diese Voraussetzungen sind:
• Java Kompatibel (E1 ): Da der Energie Navigator ist eine Java Applikation ist,
sollte das verwendete Release Management System mit dem Java Compiler kompatibel sein.
• Komponenten einzelnd Releasen (E2 ): Da der Energie Navigator aus einer
Client-Applikation und mehreren Webservices besteht und sich bei einem Release
nicht alle Komponenten verändern müssen sollten einzelne Komponenten Release
werden und in das laufende System eingebettet werden können. Das Release Management System sollte diese Funktion unterstützten.
• SVN Versionsverwaltung (E3 ): Der Energie Navigator Programmcode wird seit
beginn der Entwicklung mit über die Versionsverwaltung SVN versioniert und deswegen bereits bei den Entwicklern etabliert. Deswegen sollte das verwendete Release
Management System mit dem SVN-Repository arbeiten können.
• Bashscripts und Ant-Targtets (E4 ): Das bisherige Build-System des Energie
Nativators besteht aus Bash- und Ant-Scripten. Da es einen großen Aufwand bedeuten würde diese umzuschreiben sollte das Release Management System diese Scritps
ausführen können.
• Glassfish SJSAS Deployment (E5 ): Die Energie Navigator Webservices werden
auf einem Glassfish Webserver gehostet. Weil die bisherige Infrastruktur weiterhin
genutzt werden soll, soll das verwendete Release Management Systen auch auf Glassfish Servern deployen können.
• PostgresSQL Datenbank (E6 ): Die Energie Navigator Daten werden in einer
PostgreSQL Datenbank gespeichert. Diese sollte im Idealfall von dem Release Mangement System unterstützt werden. Vorallem Datenbanktransformationen sind ohne
Werkzeugunterstützung sehr mühselig.
• Deployment Virtueller Maschinen (E6 ): Neue Instanzen des Energie Navigators werden über Virtuelle Maschinen verteilt. Dazu sollte das System über vordefinierte Templates diese Instanzen erzeugen und starten können.
• Linux System (E7 ): Energie Navigator wird auf Linux Maschinen Entwickelt und
getestet, auch wenn die ENA-Clients sowohl für Windows als auch Linux Maschinen verfügbar ist, ist die Server Infrastruktur an Linux Systeme gebunden. Hier ist
es wichtig dass das verwendete Release Management System auf Linux Systemen
compilieren und deployen kann.
Auf die Anforderungen (E1-E7) werden die im vorigen Kapitel vorgestellten Release und
Deployment Mangement Systeme nun getestet und analysiert welche davon sich für ENA
eignen.
19
Serena Release Manager
Aldon Deployment Manager
BMC Application Manager Suite
Smart Bear AutomatedBuildStudio
Installshield
Apache Ant
E1
X
X
X
X
X
X
E2
X
X
X
X
X
X
E3
7
X
7
X
7
X
E4
X
7
X
X
7
X
E5
(X)
7
X
(X)
7
(X)
E6
7
X
X
7
7
7
E7
X
X
7
7
7
X
Tabelle 5.1: Release Management Systeme im Vergleich zu den ENA Anforderungen
5.3 Der Energie Navigator und Release Management Systeme
Da der Energie Navigator im Projekt bereits weiter fortgeschritten ist, ist es schwierig
ein Werkzeug zu finden, das alle Anforderungen erfüllt. Tabelle 5.1 zeigt, dass keines der
Vorgestellten Release Management Systeme diese Anforderungen erfüllt. Nun kann erwägt
werden ob es sich lohnt die ENA-Infrastruktur auf für eines der beinahe passenden Systeme
anzupassen. Smart Bear Automated Build Studio unterstützt viele Kern Anforderungen
des Energie Navigators, ist jedoch speziell für Windows Systeme ausgelegt. Für den Energie
Navigator werden zwar sowohl Linux als auch Windows Clients erstellt, jedoch hat der
ENA-Webserver einige Abhängigkeiten auf Applikationen, die an Linux Systeme gebunden
sind. So ist es nicht möglich den Webserver auf ein Windowssystem umzuziehen. Aus
diesem Grunde scheiden Smart Bear Automated Build Studio, BMC Application Manager
Suite und Installshield als Release Management System für das Energie Navigator Projekt
aus.
Serena Release Mangager und Aldon Deployment Manager wären Lösungen, die viele
Anforderungen unterstützen. Jedoch verlangen beide Werkzeuge, dass viele andere Werkzeuge aus deren Unternehmen genutzt werden, die im Energie Navigator bereits anders
gelöst werden. Beide unterstützen zum Beispiel keine SVN Versionsverwaltung und erfordern, dass Serena PVCS Version Manager bzw. Aldon Lifecycle Manager für das gesamte
Projekt benutzt wird. Die Umstellung auf andere Versionsverwaltungssoftware wäre zwar
kein großer Aufwand, jedoch ist die Versionsverwaltung SVN bereits bei den Entwicklern
etabliert.
Ant wird bereits im Energie Navigator als Deployment Management Werkzeug eingesetzt.
Jedoch sind die Deployscripts sehr lang und schwierig zu warten. Außerdem ist es nicht
in der Lage auf Remote-Maschinen zu deployen und unterstützt nur den Build Prozess.
Andere Release Management Werkzeuge werden somit benötigt.
20
6 Zusammenfassung und Ausblick
In den ersten Kapiteln wurden zunächst Grundlagen das Release Managements und von
Release Management Systemen erklärt und wichtige damit zusammenhängende Begriffe
eingeführt. Danach wurden die Anforderungen, die einem Release Management System
gestellt werden zusammengetragen und erörtert. Vier Release Management Systeme und
zwei Deployment Management Systeme wurden anschließend vorgestellt und auf die zusammengetragenen Anforderungen evaluiert. Danach wurde eine Einführung in das Energie Navigator Projekt gegeben und spezielle Anforderungen dieses Projektes an ein Release
Management System vorgestellt. Die zuvor vorgestellten Systeme wurden auf die Anforderungen des Energie Navigators getestet und erörtert ob eines dieser Systeme für das
Projekt passt.
Release Management wird für Unternehmen immer wichtiger. Ein Release Management
System einzuführen ist jedoch keine Aufgabe, die ohne gründliche Überlegung und Planung erledigt werden kann. Die Projekt Infrastruktur an ein Release Management System
anzupassen ist oftmals nicht gewollt, jedoch ist es auch sehr schwierig das richtige System
für die bereits eingesetzte Infrastruktur zu finden. Wie am Beispiel des Energie Navigators kommen viele Probleme bereits auf, bevor ein solches System überhaupt einführt
wurde. Viele Release Management Systeme sind an feste Infrastrukturen gebunden und unterstützen oft nicht die bereits genutzten Werkzeuge, zur Versionsverwaltung oder Release
Planung. Unternehmen müssen nun einschätzen ob es sich lohnt die teureren Lizenzen für
solche Systeme zu kaufen, oder selber eine Software Lösung schreiben, die zwar die eigene
Infrastruktur unterstützt, jedoch auch selbst gewartet werden muss.
Dadurch, dass nur wenige Unternehmen bewusst Release Management betreiben, ist die
Nachfrage nach Werkzeugunterstützung sehr gering. Dadurch steigt der Preis solcher Systeme und es werden kaum Open Source Lösungen angeboten. Die in dieser Arbeit evaluierten Produkte waren ausschließlich Expertenwerkzeuge, die viel Geld kosten. Dadurch, dass
das Thema in den letzten Jahren jedoch populärer geworden ist könnte sich der Markt in
den nächsten Jahren dahin verändern, solche Produkte zu standardisieren. Ein weiterer
Nachteil aktueller Release Management Systeme ist die Fehlende Konfigurierbarkeit mit
anderen Systemen. Viele der getesteten Produkte waren auf wenige Werkzeuge beschränkt.
Auch hier könnten Open Source Lösungen wie SVN oder ANT für andere Teile des Release
Managements unterstützt werden.
21
Literaturverzeichnis
[ald11]
Aldon Deployment Manager: http://www.aldon.com/prod/adm/ov/. Internet, November 2011
[ant11]
Apache Ant: http://ant.apache.org/. Internet, December 2011
[Bal]
Ballintijn, Gerco:
[BMC11]
BMC Application Management Suite: http://www.bmc.com/products/
product-listing/application-management-suite.html. Internet, November 2011
[CLC03]
Cohen, David ; Lindvall, Mikael ; Costa, Patricia: Agile Software Development / Data and Analysis Center for Software. 775 Daedalian Dr. Rome,
New York 13441-4909, Januar 2003. – State-of-the-Art Report
[cvs11]
Concurrent Versions System: http://savannah.nongnu.org/projects/
cvs. Internet, December 2011
[DMG07]
Duvall, Paul M. ; Matyas, Steve ; Glover, Andrew: Continuous Integration: Improving Software Quality and Reducing Risk. 1. Addison-Wesley
Professional, 2007 http://www.worldcat.org/isbn/0321336380. – ISBN
0321336380
[FKP+ 10]
Fisch, N. M. ; Kurpick, T. ; Pinkernell, C. ; Plesser, S. ; Rumpe,
B.: The Energy Navigator - A Web based Platform for functional Quality
Mangement in Buildings, 2010
[FLP+ 11]
Fisch, N. M. ; Look, M. ; Plesser, S. ; Pinkernell, C. ; Rumpe, B.:
Der Energie-Navigator - Performance-Controlling für Gebäude und Anlagen.
In: Fachzeitschrift für Technische Gebäudeausrüstung 04/2011 (2011), March,
36-41. http://www.se-rwth.de/publications/NMF.ML.SP.CP.BR.TAB.Der
Energie-Navigator.pdf
[FPPR10]
Fisch, N. M. ; Plesser, S. ; Pinkernell, C. ; Rumpe, B.: Software für die energieoptimierte Betriebsführung von Gebäuden.
In:
BINE Informationsdienst Projektinfo 14/10 (2010), October, 1-4.
http://www.se-rwth.de/publications/NMF.ML.SP.CP.BR.TAB.Der
Energie-Navigator.pdf. – ISSN 0937–8367
[HHHW97] Hoek, André van d. ; Hall, Richard ; Heimbigner, Dennis ;
Wolf, Alexander:
Software release management.
Version: 1997.
http://dx.doi.org/10.1007/3-540-63531-9 13. In: Jazayeri, Mehdi
(Hrsg.) ; Schauer, Helmut (Hrsg.): Software Engineering ESEC/FSE’97 Bd.
1301. Springer Berlin / Heidelberg, 1997. – ISBN 978–3–540–63531–4, 159175. – 10.1007/3-540-63531-9 13
[hud11]
Hudson Continuous Integration: http://hudson-ci.org/. Internet, December 2011
23
[HW03]
Hoek, André van d. ; Wolf, Alexander L.: Software release management for component-based software. In: Software: Practice and Experience
33 (2003), Nr. 1, 77–98. http://dx.doi.org/10.1002/spe.496. – DOI
10.1002/spe.496. – ISSN 1097–024X
[ins11]
InstallShield: www.installshield.com/. Internet, December 2011
[jen11]
Jenkins Continuous Integration: http://jenkins-ci.org/. Internet, December 2011
[Kri94]
Krishnan, Mayuram S.: Software release management: a business perspective. In: Proceedings of the 1994 conference of the Centre for Advanced Studies
on Collaborative research, IBM Press, 1994 (CASCON ’94), 36–
[Pil04]
Pilato, Michael: Version Control With Subversion. Sebastopol, CA, USA :
O’Reilly & Associates, Inc., 2004. – ISBN 0596004486
[ser11]
Serena Release Automation: http://www.serena.com/products/release
-automation/index.html. Internet, November 2011
[sma11a]
Smart
Bear
Automated
Build
Studio
Support:
http://smartbear.com/support/viewarticle/9304/. Internet, December
2011
[Sma11b]
Smart Bear Automated Build Studio: http://smartbear.com/products/
development-tools/build-management/. Internet, November 2011
[sub11]
Apache Subversion: http://subversion.apache.org/. Internet, December
2011
[Ves03]
Vesperman, Jennifer: Essential CVS. O’Reilly Media, Inc., 2003. – ISBN
0596004591
[WRGM08] Wegmann, A. ; Regev, G. ; Garret, G.-A. ; Marechal, F.: Specifying
Services for ITIL Service Management. In: Service-Oriented Computing: Consequences for Engineering Requirements, 2008. SOCCER ’08. International
Workshop on, 2008, S. 8 –14
24