Hochschule RheinMain Fachbereich DCSM Studiengang Informatik (Master)

Größe: px
Ab Seite anzeigen:

Download "Hochschule RheinMain Fachbereich DCSM Studiengang Informatik (Master)"

Transkript

1 Fachbereich DCSM Studiengang Informatik (Master) Fachseminar Continuous Integration am Beispiel von CruiseControl Mat. Nr.: Datum:

2 Continuous Integration am Beispiel von CruiseControl 1 Abstract Waiting until the end of a complex software development project to integrate software leads to many sorts of problems which have to be solved by the development team. For example components and modules that worked perfectly stand alone fail if they were put together. Because of schedule pressure the team often introduces even more errors instead of solving the former ones. Continuous Integration (CI) reduces those errors and mitigates risks by integrating software frequently. The following paper examines the concept of CI and covers seven practices which will help to get all benefits out of CI. The last part of the paper introduces the open source CI tool CruiseControl which helps to automate repetitive and error-prone tasks and visualizes the integration build results.

3 Continuous Integration am Beispiel von CruiseControl 2 Inhaltsverzeichnis 1 Einführung 3 2 Continuous Integration (CI) Was ist Continuous Integration? Die CI-Komponenten Praktiken CruiseControl Architektur Plugins Beispiel Fazit 23 A Build-Skript 24

4 Continuous Integration am Beispiel von CruiseControl 3 1 Einführung Unter Integration ist die Kombination verschiedener Quellcode-Artefakte zu einem übergeordneten Ganzen zu verstehen. So werden bei der Integration beispielsweise die verschiedenen Module eines Softwareprodukts zu einer lauffähigen Anwendung zusammengesetzt. Für ein-mann-projekte mag der Integrationsprozess noch trivial sein, aber schon wenn nur eine weitere Person an der Entwicklung beteiligt wird, steigt der Aufwand um sicherzustellen, dass die verschiedenen Softwarekomponenten einwandfrei zusammenarbeiten. An der Erstellung komplexer Geschäftsanwendungen sind heute meist große Teams von Entwicklern, Architekten, Managern etc. beteiligt. Wird hier der Integrationsprozess erst kurz vor der Auslieferung des Produkts an den Kunden zum ersten Mal durchlaufen, sind Fehler vorprogrammiert. Möglicherweise sind wichtige Build-Skripte auf dem Rechner eines Kollegen der im Urlaub ist, die Versionen untereinander inkompatibel oder die Software will auf dem Testsystem nicht laufen. Unter Termindruck wird dann versucht die Fehler zu beheben, nur um anschließend neue Fehler zu Tage zu fördern und schon befindet sich das Team mitten in der integration hell, wie es Paul M. Duvall in [Duv09] treffenderweise beschreibt. Hier soll Continuous Integration (CI) Abhilfe schaffen. Ziel von CI ist es, die Integration im Rahmen von Softwareentwicklungs-Projekten zu einem non-event zu machen. Dabei ist das Prinzip von CI, den Integrationsprozess möglichst häufig und automatisiert zu durchlaufen, um so Fehler zu vermeiden. Martin Fowler beschreibt Continuous Integration in seinem gleichnamigen Artikel so: Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. [Fow06] Aus dieser Definition wird deutlich, dass Continuous Integration kein Tool ist, sondern vielmehr ein Standpunkt bzw. eine Einstellung zu einer bestimmten Arbeitsweise, die das gesamte Entwicklerteam teilt.

5 Continuous Integration am Beispiel von CruiseControl 4 Die beiden Kernpunkte dieser Arbeitsweise sind: kontinuierliches Durchführen von Integrationen, mindestens täglich automatisierte Builds (inklusive Tests) Auf diese Weise wird die Qualität der Software gesteigert und Risiken, wie beispielsweise das späte Auffinden von Fehlern, werden reduziert. In den folgenden Kapiteln werden die Prinzipien und Praktiken rund um Continuous Integration näher erläutert (Kapitel 2) und die Arbeitsweise anhand eines Beispiels vorgestellt (Kapitel 3).

6 Continuous Integration am Beispiel von CruiseControl 5 2 Continuous Integration (CI) 2.1 Was ist Continuous Integration? Continuous Integration einzusetzen bzw. anzuwenden bedeutet, grundlegende Änderungen am Prozess der Softwareentwicklung vorzunehmen. Bei CI wird die Aufgabe Software zu integrieren, die normalerweise nur unregelmäßig und ungern ausgeführt wird, zum Hauptbestandteil der täglichen Programmierarbeit. Die Tatsache, dass die Integration kontinuierlich wiederholt wird, lässt sie zu einem ganz normalen Bestandteil des Softwareentwicklungsprozesses werden. Kontinuierlich im Zusammenhang mit CI bedeutet, mindestens einmal täglich. Die Häufigkeit der Integrationen wird sich zwar von Projekt zu Projekt unterscheiden, dennoch sollte die generelle Regel, mindestens einmal täglich zu integrieren, nicht unterschritten werden. Um das zu erreichen, müssen die Programmierangewohnheiten dem angepasst werden. Die zu erledigenden Aufgaben müssen in kleinere Teilschritte zerlegt werden. Wurde ein Teilschritt abgearbeitet, wird eine Integration durchgeführt. Der Zeitpunkt der Integration beeinflusst auch die damit zusammenhängenden Risiken. Werden in einem Projekt beispielsweise umfangreiche Änderungen wie das Umbenennen von Klassen vorgenommen, ist die Wahrscheinlichkeit hoch, dass die vorgenommenen Änderungen auch andere Entwickler/anderen Code beeinflussen. Je länger hier mit der Integration gewartet wird, desto höher sind die Auswirkungen und desto mehr Aufwand wird es sein, die verursachten Fehler wieder zu beheben. Im Umkehrschluss heißt das: wenn nur kleine Änderungen vorgenommen werden und anschließend eine Integration erfolgt, ist die Anzahl der möglichen Fehlerquellen ebenfalls klein und der Fehler schnell gefunden. Entwickler sind beispielsweise auch eher bereit Änderungen vorzunehmen, wenn sie wissen, dass die Integration und somit das Feedback, ob die Änderungen die restliche Software beeinflussen, nur einen Schritt entfernt ist. Auf diese Weise wird die Softwarequalität erheblich gesteigert. Durch die tägliche Integration der Software ist zudem der Projektstand bzw. -fortschritt einfacher zu erfassen. Ein weiterer Vorteil von CI ist, dass jederzeit eine aktuelle Deploy-fähige Version der Software vorhanden ist und nicht erst kurz vor Auslieferung oder Ende eines Projekt- Meilensteins.

7 Continuous Integration am Beispiel von CruiseControl Die CI-Komponenten In Kapitel 1 wurden bereits die automatisierten Builds als wichtiges Prinzip von CI identifiziert. Unter Build soll im Folgenden nicht nur das Kompilieren von Quellcode verstanden werden, sondern eine Kombination von Tätigkeiten, zu denen neben dem Kompilieren u.a. auch das Testen, Inspection 1 und Deployment gehören. Das Ergebnis eines Builds ist eine funktionsfähige Version der Software. Automatisiert werden die Builds mit Hilfe von Build-Skripten. Die folgenden vier Komponenten bilden das CI-System und sind zugleich die Voraussetzung für die Einführung von Continuous Integration in den Softwareentwicklungsprozess: Build-Skripte System zur Versionsverwaltung (z.b. Subversion 2 ) CI-Server (z.b. CruiseControl 3 ) Feedback-Mechanismus Bevor diese Komponenten in den nächsten Abschnitten näher läutert werden, ist in Abbildung 1 zunächst der Zusammenhang zwischen den Komponenten dargestellt. Dieser soll an folgendem Szenario verdeutlicht werden: Das Szenario beginnt auf der linken Seite der Abbildung 7, wenn ein Entwickler seine Quellcodeänderungen an das Versionskontroll-System (= Repository) übermittelt. Dieser Vorgang wird als Commit bezeichnet. Der CI-Server prüft in regelmäßigen Abständen (bspw. alle fünf Minuten), ob neue Änderungen im Repository vorliegen. Dies ist der Fall, sobald ein Entwickler seine Änderungen ins Repository gestellt hat. Daraufhin lädt der CI-Server den neuesten Quellcode aus dem Repository der Versionskontrolle herunter und führt das Build-Skript aus, mit dessen Hilfe die Software integriert wird. Nach der Integration werden die Build-Ergebnisse über den gewählten Feedback-Mechanismus an die Projektverantwortlichen verteilt. Je nach Feedback-Art sendet der CI- 1 vgl. [15990] 2 3

8 Continuous Integration am Beispiel von CruiseControl 7 Abbildung 1: CI-Komponenten [Duv09] Server hierzu beispielsweise eine an den Entwickler, der die Änderungen ins Repository gestellt hat und benachrichtigt den Projektleiter per SMS. Anschließend beginnt der CI-Server wieder, auf Änderungen im Repository zu warten. Build-Skripte Ein Build-Skript führt die zu einem Build gehörenden Tätigkeiten, wie kompilieren oder testen, automatisiert aus. Für die unterschiedlichsten Programmiersprachen stehen Build- Tools zur Verfügung, mit deren Hilfe plattformunabhängige Build-Skripte erstellt werden können. Ein Build-Tool für Java-Quellcode ist beispielsweise Ant 4. Es ist darauf zu achten, dass zum Ausführen eines vollständigen Builds ein einzelner Befehl ausreicht und dass die erstellten Skripte unabhängig von evtl. verwendeten IDEs sind. Dies ist wichtig, damit der CI-Server die Build-Skripte korrekt ausführen kann. System zur Versionsverwaltung Bei der Verwaltung von Änderungen am Quellcode und anderen Dateien helfen sogenannte Versionsverwaltungssysteme, wie beispielsweise Subversion oder CVS 5. Die Dateien werden dort in einem zentralen Projektarchiv, dem Repository, abgelegt. In den meisten Softwareprojekten gehört heutzutage ein System zur Versionskontrolle zum Standard und auch für CI ist dies unumgänglich. Auf diese Weise werden alle Soft

9 Continuous Integration am Beispiel von CruiseControl 8 wareartefakte an einer zentralen Stelle aufbewahrt und es ist beispielsweise bei Fehlern möglich, auf eine ältere Version zurückzugreifen. Es ist wichtig, dass nicht nur Quellcodedateien im Repository abgelegt werden. Es sollte alles, was für einen Build benötigt wird, dort gespeichert sein. Angefangen von Test- Skripten, Property-Dateien, Datenbank-Schemata über Installationsskripte bis hin zu verwendeten Bibliotheken anderer Hersteller. Ziel sollte es sein, einzig mit dem Inhalt aus dem Repository eine lauffähige Version des Systems erzeugen zu können. CI-Server Der CI-Server führt, wie das eingangs beschriebene Szenario zeigt, jedes Mal ein Integrations-Build der Software durch, wenn er Änderungen im Repository der Versionskontrolle festgestellt hat. Zum Durchführen der Integration fragt der CI-Server alle benötigten Quellcodedateien beim Repository ab und führt anschließend ein oder mehrere Build-Skripte aus. CI-Server Implementierungen sind beispielsweise Open-Source von CruiseControl 6 oder Hudson 7 verfügbar. Um CI in einem Projekt umzusetzen, ist der CI-Server selbst nicht zwingend notwendig. Es ist auch möglich diese Aufgaben manuell durchzuführen. Dieses Vorgehen beschreibt z.b. James Shore in [Dol06]. Auf welche Art integriert wird, also beispielsweise mit CI-Server oder manuell, sollte jedes Team in Abhängigkeit von seinen Gewohnheiten und Möglichkeiten bestimmen. Wichtig ist für beide Varianten, dass für das Ausführen der Integrations-Builds eine separate Maschine vorhanden ist. Feedback-Mechanismus Eines der Hauptziele von CI ist es, möglichst schnell ein Feedback zum Verlauf des Integrations-Builds zu generieren. Die Entwickler und Projektverantwortlichen sollen so zeitnah wie möglich über evtl. vorliegende Integrationsprobleme informiert werden. Hierzu kann der CI-Server beispielsweise SMS-Nachrichten oder s mit den Build- Ergebnissen versenden

10 Continuous Integration am Beispiel von CruiseControl Praktiken Damit CI einem Projekt den idealen Nutzen bringen kann, werden in [Duv09] sieben Methoden beschrieben, die in den Projektteams umgesetzt werden sollen. Commit code frequently Don t commit broken code/ Run private Builds Fix broken Builds immediately Avoid getting broken Code Write automated developer tests All tests and inspections must pass Keep your Builds fast Commit code frequently Damit der CI-Grundsatz, die Integration möglichst früh und häufig durchzuführen, auch eingehalten werden kann, müssen die Entwickler ihre Quellcodeänderungen auch dementsprechend häufig an das Repository übermitteln. Auf diese Weise sind die Änderungen schnell zu überblicken und auftretende Fehler schnell zu lokalisieren. Auch schon kleine Änderungen ins Repository zu stellen gibt anderen Teammitgliedern außerdem die Möglichkeit, schon früher mit einer aktuelleren Version der Software zu arbeiten. Damit der Commit so häufig stattfinden kann, müssen die Entwickler in der Regel ihre Arbeitsweise ändern und ihre Aufgaben in kleine Teile zerlegen. Nachdem der Quellcode für die Teilaufgabe geschrieben wurde, werden Tests zum Verifizieren der Änderungen erstellt und durchgeführt. Anschließend erfolgt gleich ein Commit, der dann die Integration veranlasst. Don t commit broken code/ Run private Builds Ein weiterer CI-Grundsatz ist, dass kein defekter/fehlerhafter Code ins Repository gestellt werden darf. Davon abgesehen, dass dies eigentlich immer gelten sollte, ist es für

11 Continuous Integration am Beispiel von CruiseControl 10 Abbildung 2: Ablauf von privaten Builds [Duv09] CI besonders wichtig, dass der Code im Repository funktionsfähig ist. Um das sicherzustellen, muss vor dem Commit ein Integrations-Build auf der lokalen Entwicklermaschine simuliert werden (siehe Abbildung 2). Bei diesem Build sogenannten privaten Build wird die neuste Softwareversion des Entwicklers mit den neusten Versionen vom Rest des Teams integriert. Die Vorgehensweise hierbei ist in Abbildung 2 dargestellt. Durch die privaten Builds kann schon vor dem Commit an das Repository die Kompatibilität der neuesten Änderungen im Repository, mit den lokalen vom Entwickler vorgenommenen Änderungen überprüft werden. Erst wenn der private Build erfolgreich war, darf der Code ins Repository gestellt werden. Fix broken Builds immediately Ein fehlgeschlagener Build kann verschiedene Ursachen haben: Kompilierungsfehler, fehlgeschlagene Tests oder auch ein Datenbankproblem. All dies können Gründe sein, warum der CI-Server einen nicht erfolgreichen Build meldet. Im Rahmen von CI ist die schnelle Behebung von Build-Fehlern besonders wichtig, damit das gesamte Team weiterarbeiten kann 8. Daher sollte für das Team die Behebung von Build-Fehlern höchste Priorität bei den Projektaufgaben haben. 8 Denn das Team verwendet den aktuellen Repository-Code ja beispielsweise beim privaten Build.

12 Continuous Integration am Beispiel von CruiseControl 11 Avoid getting broken Code Genauso wie kein fehlerhafter Code ins Repository gestellt werden darf, sollte auch kein fehlerhafter Code oder fehlerhafte Builds aus dem Repository bezogen werden. Dies erspart dem Entwickler das zeitaufwändige Einbinden von Workarounds. Der für den Fehler zuständige Programmierer arbeitet ohnehin schon an der Behebung des Fehlers. Auch hier wird nochmal deutlich, dass es für den Projektfortschritt wichtig ist, dass alle Build-Fehler umgehend behoben werden. Write automated developer tests Wenn ein Programm sich fehlerfrei kompilieren lässt, gibt das jedoch noch keine Auskunft darüber, ob das Programm auch richtig arbeitet. Dies kann mit Hilfe von Tests zumindest ansatzweise überprüft werden. Durch ausgiebiges Testen können schon im Vorfeld einige Fehler vermieden werden. Im Rahmen von CI sollten diese Tests automatisiert und in den Build-Prozess eingebunden werden. Zur Realisierung der Tests können beispielsweise die verschiedenen xunit Frameworks (wie bspw. JUnit) verwendet werden. Die Ausführung der Tests erfolgt im Rahmen der Build-Skripte. All tests must pass In einer CI-Umgebung müssen alle Tests 100% erfolgreich sein, damit ein Build als erfolgreich gelten kann. Ein Programm, das nicht alle Tests besteht, kann in der Regel auch nicht korrekt sein. Um festzustellen, wie viel Prozent des Programmcodes durch die vorhandenen Tests abgedeckt werden, können in den Integrations-Build-Prozess sogenannte Code-Coverage-Tools (wie beispielsweise EMMA 9 ) eingebunden werden. Keep your Builds fast Schnelles Feedback nach einem Build ist eines der wichtigsten Grundsätze von Continuous Integration. Damit dieses Feedback auch zeitnah erfolgen kann und der Entwicklungsprozess nicht ins Stocken gerät, dürfen die Builds nicht zeitaufwändig sein. Auch wenn Entwickler evtl. vorhandene Build-Fehler unmittelbar nach dem Auftreten beheben können sollen, muss der Build schnell durchführbar sein. Daher sollte die Faustregel gelten, dass ein Build nicht länger als 10 Minuten benötigt. 9

13 Continuous Integration am Beispiel von CruiseControl 12 Sicherlich gibt es Projekte, bei denen dies nicht erreicht werden kann. Dennoch sollte auch hier versucht werden, die Build-Dauer zumindest auf ein Minimum zu reduzieren. Hierzu können verschiedene Analysen durchgeführt werden, um Engpässe ausfindig zu machen 10. Eine Möglichkeit langsamen Builds entgegenzuwirken, ist die Aufteilung in mehrere abgestufte Builds, die dann nacheinander ausgeführt werden. Diese werden als staged Builds bezeichnet (vergleiche Abbildung 3). Abbildung 3: Staged-Builds - Vorgehensweise [Duv09] Der erste, leichtgewichtige Integrations-Build wird durch das Hochladen der neusten Änderungen ins Repository ausgelöst. Damit der Build in kurzer Zeit erstellt werden kann, werden hier nur die Tests durchgeführt, die die offensichtlichsten Fehler aufdecken. War dieser Build erfolgreich, wird ein weiterer umfassender Build durchgeführt, der Datenbank-, Komponenten- und Systemtests, Inspections und (evtl.) das Deployment beinhaltet. 10 vgl. hierzu [Duv09] Seite 87 ff.

14 Continuous Integration am Beispiel von CruiseControl 13 3 CruiseControl CruiseControl 11 ist sowohl ein CI-Tool als auch ein erweiterbares Framework, mit dessen Hilfe benutzerdefinierte kontinuierliche Build-Prozesse definiert werden können. Die Software ist Java-basiert und wurde ursprünglich von der Firma ThoughtWorks 12 entwickelt, ist aber mittlerweile Open-Source. CruiseControl beinhaltet verschiedenste Plugins, mit deren Hilfe beispielsweise die unterschiedlichsten Feedback-Mechanismen wie , Instant-Messages oder SMS realisiert werden können. Ein Web-Frontend gibt einen ausführlichen Überblick über aktuelle oder vergangene Builds und eventuell aufgetretene Fehler. CruiseControl kann als Binary-Distribution, Quellcode-Zip oder als Windows-Installer-Datei von der Homepage heruntergeladen werden. Das Binary-Zip enthält eine CruiseControl Version, die nach dem Entpacken sofort lauffähig ist und ein Beispiel beinhaltet. Im Rahmen dieser Arbeit wird die Binary-Distribution in Version verwendet. 3.1 Architektur Im Wesentlichen besteht CruiseControl aus drei Modulen (vergleiche dazu Abbildung 4): Build-Loop Die Build-Loop ist sozusagen der Kern von CruiseControl und läuft als Prozess im Hintergrund. Dieser Prozess überprüft in periodischen Abständen, ob im Repository der Versionskontrolle Änderungen vorliegen, veranlasst, falls nötig den Build und veröffentlicht anschließend das Feedback zum Build-Status über den gewählten Mechanismus ( , SMS,...). Die Build-Loop wird über eine XML-Datei namens config.xml konfiguriert (siehe Abbildung 4). Hier werden pro Projekt die jeweiligen Einstellungen zu Feedbackmechanismus etc. vorgenommen und beispielsweise bestimmt, ob CruiseControl die Artefakte des abgeschlossenen Builds (z.b. die erstellten JAR 13 -Dateien) veröffentlichen soll JAR=Java Archive

15 Continuous Integration am Beispiel von CruiseControl 14 Abbildung 4: CruiseControl Architektur 14 Reporting Wie bereits erwähnt, stellt CruiseControl dem Benutzer ein Web-Frontend zur Verfügung. Die verschiedenen JSP-Seiten zeigen u.a. die Build-Ergebnisse an und erlauben den Zugriff auf die generierten Artefakte. Dashboard Das Dashboard, eine weitere Web-Schnittstelle, gibt dem Benutzer eine ausführliche Übersicht über alle vorhandenen Projekte und deren jeweiligen (Build-)Status. 3.2 Plugins Die Einsatzbereiche und auch die Art und Weise wie CruiseControl oder allgemein CI eingesetzt wird, können von Team zu Team sehr unterschiedlich sein. Damit CruiseControl möglichst vielfältig verwendbar ist, besteht die Software aus einem kleinen Kern, der die zentralen CI-Bestandteile implementiert. Die verschiedenen Implementierungsdetails sind in Plugins ausgelagert, so kann die Software leichtgewichtig bleiben und einfach angepasst, verändert oder erweitert werden. 14 von

16 Continuous Integration am Beispiel von CruiseControl 15 Die Plugins werden durch Beans repräsentiert, deren Setter-Methoden auf die Elementnamen der XML-Konfigurationsdatei (config.xml) abgebildet werden. Liegen die Build- Skripte beispielsweise als Ant-Skript vor, wird in der Konfigurationsdatei der AntBuilder zum Ausführen der Skripte definiert. Die Zeile in der Konfigurationsdatei wäre folgende: <ant anthome="cc\ant" buildfile="build.xml"/> Wobei für das Attribut buildfile in der Klasse AntBuilder die dazu passende Methode setbuildfile() existiert. CruiseControl unterscheidet sechs verschiedene Plugin-Typen: Bootstrapper: wird vor dem Build ausgeführt, beispielsweise zum Aktualisieren der build.xml Datei SourceControl: fragt beim (Code-) Repository nach Änderungen Builder: führt den eigentlichen Build und die Tests aus LabelIncrementer: nummeriert die einzelnen Builds Publisher: veröffentlicht die Build-Ergebnisse, beispielsweise per Listener: bearbeitet Projekt-Events, wie beispielsweise die Veröffentlichung des momentanen Build-Status 3.3 Beispiel In folgendem Beispiel wird beschrieben, wie eine Anwendung in den CI-Prozess, bzw. in CruiseControl, aufgenommen wird. Als Beispiel wird eine Anwendung namens Calculator verwendet, die einen Taschenrechner implementiert. Folgende Schritte sind nötig, um das Beispiel bereit für CI zu machen. 1. Anwendungscode entwickeln 2. Tests implementieren 3. Build-Skript erstellen und ausführen

17 Continuous Integration am Beispiel von CruiseControl Code ins Repository stellen 5. Projekt in CruiseControl config.xml einbinden Die Beispiel-Anwendung enthält ein Ant-Build-Skript (siehe Anhang A), das nach dem Kompilieren alle vorhandenen JUnit-Tests ausführt und am Ende eine JAR-Datei erstellt. Beim Durchführen der JUnit-Tests sollte immer darauf geachtet werden, dass bei einem gefundenen Fehler der Build-Vorgang abgebrochen und der Build somit als fehlgeschlagen deklariert wird. Hierzu dient bei Ant-Skripten beispielsweise das Attribute haltonfailure="yes", das im Element junit angegeben wird 15. Ein Programm, das nicht alle Tests besteht, kann nicht vollständig funktionsfähig sein und daher muss der Build in einem solchen Fall fehlschlagen. Konfiguration von CruiseControl Um die Calculator-Anwendung in die Build-Loop von CruiseControl aufzunehmen, muss die Datei config.xml um den in Listing 1 dargestellten Eintrag erweitert werden: 1 [...] 2 <project name="calculator" buildafterfailed="true"> 3 <listeners> 4 <currentbuildstatuslistener file="logs/${project.name}/status.txt"/> 5 </listeners> 6 7 <modificationset quietperiod="30"> 8 <svn RepositoryLocation="https://svn.mi.hs-rm.de/svn 9 /2009mobileanw/2009mobileanw04"/> 10 </modificationset> <schedule interval="120"> 13 <ant anthome="${cc.ant.dir}" buildfile="build-${project.name}.xml"/> 14 </schedule> <log> 17 <merge dir="projects/${project.name}/target/test-results"/> 18 </log> <publishers> 21 <artifactspublisher file="projects/calculator/target/calculator.jar" 22 dest="artifacts/calculator" /> <currentbuildstatuspublisher file="currentbuild.txt" /> vgl. Anhang A: Listing 6, Zeile 22

18 Continuous Integration am Beispiel von CruiseControl < mailhost="localhost" defaultsuffix="" 27 buildresultsurl="http://localhost:8080/cruisecontrol/buildresults"> 28 <always /> 29 </ > 30 </publishers> 31 </project> 32 [...] Listing 1: Auszug aus config.xml Durch das Statement in Zeile 6 wird CruiseControl veranlasst, alle zwei Minuten zu prüfen, ob im Repository Änderungen vorliegen. Ist dies der Fall, wird das in Zeile 12 definierte Build-Skript ausgeführt. Dieses lädt die neusten Dateien aus dem SVN-Repository und führt anschließend einen Build inklusive der zugehörigen JUnit-Tests aus. Die weiteren Bestandteile der config.xml werden im Laufe des Kapitels näher erläutert. Projektübersicht Die in Abbildung 5 dargestellte Ansicht zeigt drei Projekte, die mit CruiseControl gebaut werden. Darunter auch die Beispielanwendung calculator. Diese Seite ist der Einstiegspunkt zu den verschiedenen JSP-Projektseiten und gibt zugleich einen Überblick über den jeweiligen Projekt Build-Status. Abbildung 5: Statusseite Damit die Spalte Status zu einem Projekt hier immer aktualisiert wird, wurde der folgende Eintrag in der Konfigurationsdatei vorgenommen:

19 Continuous Integration am Beispiel von CruiseControl 18 <listeners> </listeners> <currentbuildstatuslistener file="logs/${project.name}/status.txt"/> Listing 2: config.xml - listeners Auf diese Weise wird die Statusspalte beispielsweise mit dem Inhalt building aktualisiert, wenn gerade ein Build-Vorgang läuft. Durch Auswahl des calculator-links in der Spalte Project, wird der Benutzer auf die Seite mit den Build-Ergebnissen des Projekts weitergeleitet (siehe Abbildung 6). Build-Ergebnisse Die Hauptseite (Abbildung 6) gibt einen Überblick über den momentanen Status des Builds und informiert den Benutzer beispielsweise, wie viele JUnit-Tests mit welchem Ergebnis durchgeführt wurden oder wer welche Änderungen seit dem letzten erfolgreichen Build vorgenommen hat. Abbildung 6: Build-Ergebnisse Damit die JUnit-Testergebnisse hier richtig angezeigt werden, muss CruiseControl mit-

20 Continuous Integration am Beispiel von CruiseControl 19 geteilt werden, wo die XML-Datei mit den Testergebnissen liegt. Den entsprechenden Eintrag in der Konfigurationsdatei zeigt Listing 3. [...] <log> </log> [...] <merge dir="projects/${project.name}/target/test-results"/> Listing 3: config.xml - Testergebnisse anzeigen Über den Link Build Artifacts gelangt der Benutzer zur Downloadseite (siehe Abbildung 7). Abbildung 7: Artefakte zum Download Hier können die während des Builds erstellten Artefakte heruntergeladen werden. So haben alle Teammitglieder beispielsweise an einem zentralen Punkt Zugriff auf die neuste Version der Software. Welche Dateien hier zum Download bereitgestellt werden sollen, wird über die Konfigurationsdatei im Bereich Publishers festgelegt (siehe Listing 4). [...] [...] <publishers> <artifactspublisher file="projects/calculator/target/calculator.jar" [...] </publishers> dest="artifacts/calculator" /> Listing 4: config.xml - Artefakte bereitstellen Die Seite Test Results, die in Abbildung 8 dargestellt ist, gibt einen ausführlichen Überblick, welche JUnit-Tests mit welchem Ergebnis ausgeführt wurden und wie viel Zeit die

21 Continuous Integration am Beispiel von CruiseControl 20 einzelnen Tests in Anspruch genommen haben. Dies kann hilfreich sein, wenn die Builds zu lange dauern und eine Aufteilung in mehrere Builds gewünscht wird. Dann können die länger andauernden Tests erst als zweites durchgeführt werden (siehe dazu Abschnitt 2.2 Keep your Builds fast ). Abbildung 8: JUnit-Testergebnisse Feedback Feedback ist das zentrale Thema im Rahmen von CI. Damit der Feedback-Mechanismus passend zu den Gewohnheiten eines Teams gewählt werden kann, unterstützt CruiseControl Mechanismen wie , SMS, RSS-Feeds, Instant-Messages und viele mehr. Zusätzlich lässt sich CruiseControl auch um eigene Feedback-Varianten erweitern. Für die Beispielanwendung wurde das Feedback gewählt. Generell stehen zwei Typen zur Auswahl: eine Textversion und eine HTML-Version. Die Textversion informiert den Empfänger, ob der Build erfolgreich war oder nicht und enthält einen Link zu der Ergebnisseite von CruiseControl. Die HTML-Version enthält die gesamten Build- Ergebnisse als Inhalt der . Für das Calculator-Projekt wurde die Variante Textversion gewählt. Um das Feedback zu ermöglichen, muss neben CruiseControl auch ein SMTP-fähiger - Server, wie beispielsweise James 16 von Apache, installiert sein. Anschließend wird der Mailversand noch in der Konfigurationsdatei eingetragen. Hierzu dient das -Tag (siehe Listing 5), das unter Publishers definiert wird. [...] <publishers> [...] < mailhost="localhost" defaultsuffix="" buildresultsurl="http://localhost:8080/cruisecontrol/buildresults"> <always /> </ > [...] 16

22 Continuous Integration am Beispiel von CruiseControl 21 [...] </publishers> Listing 5: config.xml - Feedback per Mail Dashboard Wie eingangs bereits erwähnt, hilft das Dashboard dabei, den Status der verschiedenen Projekte zu visualisieren (siehe Abbildung 9). Abbildung 9: Dashboard Jedes Projekt wird durch ein Quadrat in der Liste repräsentiert. Die Farben der Quadrate geben Auskunft über den Status. Grau symbolisiert beispielsweise inaktive Projekte, hellgrün signalisiert, dass das Projekt seit weniger als 24-Stunden erfolgreich ist, rot steht für einen fehlgeschlagenen Build. Der Reiter Builds führt zur in Abbildung 10 dargestellten Ansicht. Abbildung 10: Dashboard - Build-Ansicht Hier werden alle Projekte mit näheren Informationen zu den Builds aufgelistet. In Abbildung 10 wird gerade der Build-Vorgang für das Projekt brewery ausgeführt und das Status-Quadrat entsprechend gelb dargestellt. Von dieser Seite aus ist es auch möglich,

Continuous Integration mit Jenkins

Continuous Integration mit Jenkins Continuous Integration mit Jenkins Christian Robert anderscore GmbH Senior Software Engineer Frankenwerft 35 christian.robert@anderscore.com 50677 Köln www.anderscore.com FrOSCon 2012 Christian Robert

Mehr

intersoft AG Continuous Integration Der einfache Weg zu besserer Software Copyright 2006 by intersoft AG

intersoft AG Continuous Integration Der einfache Weg zu besserer Software Copyright 2006 by intersoft AG intersoft AG Continuous Integration Der einfache Weg zu besserer Software Inhalt Was ist Continuous Integration? Was soll Continuous Integration? Wie geht Continuous Integration? Wie sieht Continuous Integration

Mehr

ANT. Kurzvortrag von Manuel Schulze. mschulze@inf.fu-berlin.de

ANT. Kurzvortrag von Manuel Schulze. mschulze@inf.fu-berlin.de ANT Kurzvortrag von Manuel Schulze mschulze@inf.fu-berlin.de ANT Überblick Teilprojekt der Apache Software Foundation [1] ANT ist Opensource Build-Tool ähnlich wie make (?) jedoch voll auf Java zugeschnitten

Mehr

Das Build-Tool ANT ETIS SS05

Das Build-Tool ANT ETIS SS05 Das Build-Tool ANT ETIS SS05 Motivation Build - Datei Allgemeiner Aufbau Project Target Task Properties Zusammenfassung Literatur Gliederung 2 Motivation ANT I open source-projekt (aktuell: Version 1.6.5)

Mehr

URT Eclipse All in one

URT Eclipse All in one URT Eclipse All in one Das Paket Eclipse All in one enthält Programme und Einstellungen, die zum Programmieren mit Eclipse in Zusammenarbeit mit Subversion und ANT benötigt werden. Dieses Paket dient als

Mehr

Auswahl eines Continuous Integrationsservers

Auswahl eines Continuous Integrationsservers Auswahl eines Continuous Integrationsservers Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: 1.0 www.oio.de info@oio.de Gliederung Einführung Auswahlkriterien Fazit 2 Gliederung

Mehr

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Ant - das Java Build-Tool

Ant - das Java Build-Tool Hauptseminar Ant - das Java Build-Tool Funktionalität, Mächtigkeit und Praxiserfahrungen Betreuer: Vortragender: Dipl.Inf. Thorsten Strufe Christoph Lühr Gliederung Build-Tools Aufgaben und Probleme Ant

Mehr

Das Build Tool Ant. Sebastian Mancke, mancke@mancke-software.de

Das Build Tool Ant. Sebastian Mancke, mancke@mancke-software.de Das Build Tool Ant Sebastian Mancke, mancke@mancke-software.de Grundlagen Motivation Bei der Übersetzung und Pflege von Software treten viele, gleich bleibende Arbeitsschritte auf. Übersetzen des Codes

Mehr

Softwaretests. Werkzeuge zur Automatisierung. Thementag Wer testet, ist feige. Autor: für 24.06.2009. Markus Alvermann.

Softwaretests. Werkzeuge zur Automatisierung. Thementag Wer testet, ist feige. Autor: für 24.06.2009. Markus Alvermann. Softwaretests Werkzeuge zur Automatisierung für Thementag Wer testet, ist feige 24.06.2009 Autor: Markus Alvermann Seite 2 / 39 Agenda Motivation Versionsverwaltung Build-Tools Unit-Tests GUI-Tests Continuous

Mehr

Continuous Integration im medizinischen Bereich

Continuous Integration im medizinischen Bereich Philipp Schröter Fachbereich für Informatik Continuous Integration im medizinischen Bereich Ein praktisches Beispiel Gliederung 1. Einleitung 2. Relevanz im medizinischen Bereich 3. Continuous Integration

Mehr

Gerrit und Jenkins ein Traumpaar für Pre-Tested Commit

Gerrit und Jenkins ein Traumpaar für Pre-Tested Commit und ein Traumpaar für Pre-Tested Commit Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Steffen Schäfer Steffen Schluff Version:.0 www.oio.de info@oio.de Gliederung Pre-tested commit und

Mehr

Gerrit und Jenkins ein Traumpaar für Pre-Tested Commit

Gerrit und Jenkins ein Traumpaar für Pre-Tested Commit und ein Traumpaar für Pre-Tested Commit Orientation in Objects GmbH Weinheimer Str. 68 6809 Mannheim Steffen Schäfer Steffen Schluff Version:.0 www.oio.de info@oio.de Gliederung Pre-tested commit und Pre-tested

Mehr

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at www.celix.at September 2015 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile

Mehr

Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven

Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven Dipl.-Inf (FH) Matthias Müller 09.06.2010 Regressionstests Unter einem Regressionstest

Mehr

Subversion als Werkzeug in der Software-Entwicklung Eine Einführung. Tobias G. Pfeiffer Freie Universität Berlin

Subversion als Werkzeug in der Software-Entwicklung Eine Einführung. Tobias G. Pfeiffer Freie Universität Berlin Subversion als Werkzeug in der Software-Entwicklung Eine Einführung Tobias G. Pfeiffer Freie Universität Berlin Seminar DG-Verfahren, 9. Juni 2009 Voraussetzungen/Ziele des Vortrags Situation Der Zuhörer

Mehr

Buildwerkzeuge für Javaprojekte. Christian Bunse Institut für Informatik 03.07.2008

Buildwerkzeuge für Javaprojekte. Christian Bunse Institut für Informatik 03.07.2008 Buildwerkzeuge für Javaprojekte Christian Bunse Institut für Informatik 03.07.2008 Inhalt Der Build Besonderheiten von Javaprojekten Ziele von Buildwerkzeugen Continuous Integration Vorstellung von Buildwerkzeugen

Mehr

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL.

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. Die Erwartungen Ihrer Businesskunden an ihre IT steigen. Mehr denn je kommt es darauf an, die Software optimal am Kunden auszurichten

Mehr

Vom lokalen Build zum Deployment

Vom lokalen Build zum Deployment Vom lokalen Build zum Deployment International PHP Conference Manuel Pichler 12.10.2011 Vom lokalen Build zum Deployment 1 / 36 Über mich Diplominformatiker Mehr als 10 Jahre Erfahrung im PHP-Umfeld Autor

Mehr

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Tutorium auf der KSFE 2015 in Hannover, 25.03.2015 Qualität kommt von Qual. Wissen aus Daten gewusst wie ist IT-Dienstleister

Mehr

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Adrian Fülöp (297545) - 1 - Inhaltsverzeichnis: 1. Einführung 2.

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Software Configuration Management. Referat von Jens Zastrow Software Engineering Projekt WS 2001/2002

Software Configuration Management. Referat von Jens Zastrow Software Engineering Projekt WS 2001/2002 Software Configuration Management Referat von Jens Zastrow Software Engineering Projekt WS 2001/2002 Inhalt Motivation SCM-Aufgaben Item-Identifikation Identifikation Version/Release Management Change

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Ant in Eclipse Starthilfe

Ant in Eclipse Starthilfe IN DIESER KURSEINHEIT Einleitung o Um was geht's eigentlich? Hello World o Das Ant Skript Mehrere Targets und Properties o Hello World Ausgabe Ant Launch Configurations o Definition o Modifikation o Nutzung

Mehr

Datum: 15. Mai 2009. Themendossier. Build Management

Datum: 15. Mai 2009. Themendossier. Build Management Datum: 15. Mai 2009 Themendossier Seite 1 Einführung in das Thema Das gilt als Teildisziplin des Konfigurationsmanagements und hat den Zusammenbau eines Softwareprodukts zum Gegenstand ( Build ). Die Erzeugung

Mehr

Automatisierte Build-Prozesse in Java-Projekten

Automatisierte Build-Prozesse in Java-Projekten Continuous Integration Referent Olaf Kossak Freiberuflicher Informatiker Studium an der Universität Hamburg Java-Entwickler Teamleiter Qualitätsingenieur Banken, Versicherungen, Großhandel, Telekommunikation,

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) ettl@fs.wettzell.de (FESG) neidhardt@fs.wettzell.de 1 A critical view on scientific software Tendency to become complex and unstructured Highly

Mehr

Maven 2 Softwareprojekte mit Kultur

Maven 2 Softwareprojekte mit Kultur Maven 2 Softwareprojekte mit Kultur Patrick Zeising 28.05.2010 Motivation Projekte unterscheiden sich stark im Aufbau Abläufe beim Übersetzen und Deployen unterscheiden sich stark

Mehr

Build My Plug-in! >> Innerhalb der Eclipse IDE werden Plugins. In wenigen Schritten zum automatisierten PDE Build. Praxis

Build My Plug-in! >> Innerhalb der Eclipse IDE werden Plugins. In wenigen Schritten zum automatisierten PDE Build. Praxis Praxis Build-Prozess von Eclipse Plug-ins In wenigen Schritten zum automatisierten PDE Build Build My Plug-in! >> NILS HARTMANN UND GERD WÜTHERICH Mit dem PDE Build stellt die Eclipse IDE ein mächtiges

Mehr

Software- Konfigurationsmanagement (Software Configuration Management)

Software- Konfigurationsmanagement (Software Configuration Management) Software- Konfigurationsmanagement (Software Configuration Management) Definition Software-Konfigurationsmanagement (SKM) ist die Disziplin zur Verfolgung und Steuerung der Evolution von Software. W. Tichy

Mehr

1. Ausgangslage. 2. Bisheriger Build- und Deployment-Prozess

1. Ausgangslage. 2. Bisheriger Build- und Deployment-Prozess Modernisierung des Entwicklungsprozesses - ein Projektbericht Markus Heinisch Principal Consultant September 2013 Neue und höhere Anforderungen an eine Entwicklungsabteilung eines Finanzinstituts erfordern

Mehr

Software Configuration Management (SCM)

Software Configuration Management (SCM) Software Configuration Management () und n Einzelarbeit Namensgebung und Nummerierung Anleitung : Problemsituationen beim Arbeiten im Team Mehrere Entwickler ändern die gleichen Klassen Die Weiterentwicklung

Mehr

Konfigurationsmanagement

Konfigurationsmanagement Konfigurationsmanagement Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Re-usable Content in 3D und Simulationssystemen Dozent: Prof. Dr. Manfred Thaller Referent: Jannes

Mehr

Configuration Management

Configuration Management Configuration Management Software Engineering Projekt WS 06/07 Fachbereich Softwaretechnik (IV) Technische Universität Berlin Oliver Frank 1 Einleitung...3 2 Version Management... 4 2.1 Lagerung der Dateien...4

Mehr

Business Value-Driven Management and IT Consulting. Erfolgreiches Build- und Release-Management in großen Projekten

Business Value-Driven Management and IT Consulting. Erfolgreiches Build- und Release-Management in großen Projekten Business Value-Driven Management and IT Consulting Erfolgreiches Build- und Release-Management in großen Projekten Stefan M. Heldt Holger Koschek Holisticon AG 20. April 2007 stefan.heldt@holisticon.de,

Mehr

Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen

Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket

Mehr

Installation Guide. Installation Guide. Installationsanleitung für die anaptecs JEAF Plattform. Version 1.2 Letzte Änderung 05.

Installation Guide. Installation Guide. Installationsanleitung für die anaptecs JEAF Plattform. Version 1.2 Letzte Änderung 05. Installation Guide Thema Version 1.2 Letzte Änderung 05. Dezember 2011 Status Installationsanleitung für die anaptecs JEAF Plattform Freigegeben Inhaltsverzeichnis 1 Motivation... 4 1.1 Abgrenzungen...

Mehr

Continuous Integration in.net. Marcin Kawalerowicz CEO CODEFUSION Sp. z o. o.

Continuous Integration in.net. Marcin Kawalerowicz CEO CODEFUSION Sp. z o. o. Continuous Integration in.net Marcin Kawalerowicz CEO CODEFUSION Sp. z o. o. Vortragsziel Dieser Vortrag soll in die Welt der Continuous Integration einführen und aufzeigen warum der Einsatz von CI lohnenswert

Mehr

Agile Java-Entwicklung in der Praxis

Agile Java-Entwicklung in der Praxis Agile Java-Entwicklung in der Praxis Michael Hüttermann O'REILLY* Beijing Cambridge Famham Köln Paris Sebastopol Taipei Tokyo Inhalt Prolog Einleitung XI XV Teil I: Die Methodik agiler Softwareentwicklung

Mehr

Build-Management. Der Einsatz von Make, Ant und Maven und Co. Prof. Dr. Nikolaus Wulff

Build-Management. Der Einsatz von Make, Ant und Maven und Co. Prof. Dr. Nikolaus Wulff Build-Management Der Einsatz von Make, Ant und Maven und Co. Prof. Dr. Nikolaus Wulff Integrierter Arbeitsplatz Eine IDE wie Eclipse, JBuilder oder NetBeans unterstützt die alltägliche Arbeit. Sie bietet

Mehr

Subversion. Einstieg in die. Versionskontrolle

Subversion. Einstieg in die. Versionskontrolle Versionskontrolle mit Subversion Einstieg in die Versionskontrolle Dipl.Ing.(FH) K. H. Marbaise Agenda Wozu Versionskontrolle? Was leistet Versionskontrolle? Historie zu Subversion Projekt Handling Installation

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Wer bin ich. > Senior Consultant, Architekt und Trainer (MATHEMA Software GmbH) > 25+ Jahre Software > 12+ Jahre Java Enterprise > 7+ Jahre.

Wer bin ich. > Senior Consultant, Architekt und Trainer (MATHEMA Software GmbH) > 25+ Jahre Software > 12+ Jahre Java Enterprise > 7+ Jahre. Copyright 2010, MATHEMA Software GmbH 1 Wer bin ich > Senior Consultant, Architekt und Trainer (MATHEMA Software GmbH) > 25+ Jahre Software > 12+ Jahre Java Enterprise > 7+ Jahre.Net > Schwerpunkte Software

Mehr

ISA Server 2004 - Best Practice Analyzer

ISA Server 2004 - Best Practice Analyzer ISA Server 2004 - Best Practice Analyzer Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Seit dem 08.12.2005 steht der Microsoft ISA Server 2004 Best Practice Analyzer

Mehr

Enigma2 Plugin Entwicklung mit Eclipse

Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse Enigma2 Plugin Entwicklung mit Eclipse 1/15 Inhaltsverzeichnis 1 ÜBER... 3 2 INSTALLATION... 4 2.1 INSTALLATION VON ECLIPSE... 4 2.2 INSTALLATION VON PYDEV... 4 3

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

Mehr

Von Continuous Integration zu Continuous Deployment

Von Continuous Integration zu Continuous Deployment Von Continuous Integration zu Continuous Deployment Manuel Pichler 31. Mai 2010 Über mich Manuel Pichler Jahrgang 1978 Diplom Informatiker Softwarearchitekt Entwickler von: PHP_Depend

Mehr

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch Keynote ALMconf 2010 in Stuttgart 26. bis 28. Oktober 2010 Thomas Obermüller elego Software Solutions GmbH - 2010 1 Welcome & Outline Open Source basiertes ALM ganz praktisch Agenda Application Lifecycle

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Build Management. Präsentation von Daniel Mies daniel.mies@1und1.de

Build Management. Präsentation von Daniel Mies daniel.mies@1und1.de Build Management Präsentation von Daniel Mies daniel.mies@1und1.de Agenda 1&1 Member of United Internet Build Management mit Maven Motivation Kompilieren & Paketieren Dependency Management Software Analyse

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Migrationsanleitung von 2.0 auf 2.1

Migrationsanleitung von 2.0 auf 2.1 Die wichtigste Neuerung von 2.0 auf 2.1 aus Sicht der Anwendungs- Migration ist die Verwendung von Maven. Mit Maven holt sich die Anwendung alle notwendigen Bibliotheken in den jeweils angegebenen Versionen

Mehr

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java Hochschule München FK 07 SS 2009 Theis Michael - Senior Developer HVB Information Services GmbH März 2009 Grundlagen des

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Continuous Integration mit Hudson

Continuous Integration mit Hudson Continuous Integration mit Hudson Grundlagen und Praxiswissen für Einsteiger und Umsteiger von Simon Wiest 1. Auflage Continuous Integration mit Hudson Wiest schnell und portofrei erhältlich bei beck-shop.de

Mehr

BOOKLET INTRODUCTION TO CONTINUOUS INTEGRATION. Copyright 2015 bbv Software Services AG

BOOKLET INTRODUCTION TO CONTINUOUS INTEGRATION. Copyright 2015 bbv Software Services AG BOOKLET INTRODUCTION TO CONTINUOUS INTEGRATION Copyright 2015 bbv Software Services AG PROFITIEREN SIE VON UNSERER ERFAHRUNG! Kontakt Schweiz bbv Software Services AG Blumenrain 10 6002 Luzern Telefon:

Mehr

Softwareprojekte mit Kultur

Softwareprojekte mit Kultur Maven Softwareprojekte mit Kultur Patrick Zeising Konfigurationsmanagement Motivation Projektaufbau unterschiedlich Abläufe zum Übersetzen und Deployen unterschiedlich Verwendete Tools, Prozesse, Skripte

Mehr

Verteilte Systeme (WS 2013/14) Übung 0: Einführung in Maven und Git. Oliver Kleine Institut für Telematik, Universität zu Lübeck

Verteilte Systeme (WS 2013/14) Übung 0: Einführung in Maven und Git. Oliver Kleine Institut für Telematik, Universität zu Lübeck Verteilte Systeme (WS 2013/14) Übung 0: Einführung in Maven und Git Oliver Kleine Institut für Telematik, Universität zu Lübeck Build-Management in JAVA 3 Build-Management? Wozu? Traditionelle manuelle

Mehr

Software Engineering I

Software Engineering I Software I Übungsblatt 1 + 2 Claas Pinkernell Technische Universität Braunschweig http://www.sse.cs.tu-bs.de/ Seite 2 Welche Werkzeuge? Programmiersprache Java Integrierte Entwicklungsumgebung Eclipse

Mehr

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

Software Engineering. 13. Configuration Management. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 13. Configuration Management Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 13. Configuration Management 2 Übersicht Dokumentation, Installationssoftware, etc.

Mehr

Erfolgreicher Ums9eg auf Git

Erfolgreicher Ums9eg auf Git CONCEPT PEOPLE IT- TALK Ein Erfahrungsbericht Erfolgreicher Ums9eg auf Git René Preißel (etosquare) Nils Hartmann (Techniker Krankenkasse) VORSTELLUNG René Preißel Freiberuflicher SoGwarearchitekt, Entwickler

Mehr

1 Software-Configurationsmanagement (SCM)

1 Software-Configurationsmanagement (SCM) Inhaltsverzeichnis Vorlesungsplan 1. Einstieg OO 2. Modellierung (UML) 3. Design (Designmuster) 4. Implementierung (GUI-Programmierung) 5. Spezifikation (Design by Contract) 6. Qualitätssicherung (Korrektheit,

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr

1. Installation und Inbetriebnahme pcon.update

1. Installation und Inbetriebnahme pcon.update Manual pcon.update 1. Installation und Inbetriebnahme pcon.update Unter nachfolgendem Link können Sie die erforderliche Software pcon.update herunterladen. ftp://ftpdownload:download-9200@ftp.weber-os.ch/download/pcon/update/p-up-

Mehr

Eclipse Plugins für die komfortablere Verwendung von ibatis SQLMaps

Eclipse Plugins für die komfortablere Verwendung von ibatis SQLMaps Projekt: Intern Softwareprojekt FH Furtwangen Status: Draft Ersteller: Kai Grabfelder Datum: 11.02.2007 Eclipse Plugins für die komfortablere Verwendung von ibatis SQLMaps 1 Beschreibung... 2 Semesterprojekt...

Mehr

Die 7 Wege zum Clean Code

Die 7 Wege zum Clean Code Die 7 Wege zum Clean Code Über mich Claudio Altamura Softwareentwickler Certified ScrumMaster Interessen Agile Softwareentwicklung Softwarearchitekturen Java ccd2013@claudioaltamura.de 2 Inhalt 1. Statische

Mehr

Programmentwicklung ohne BlueJ

Programmentwicklung ohne BlueJ Objektorientierte Programmierung in - Eine praxisnahe Einführung mit Bluej Programmentwicklung BlueJ 1.0 Ein BlueJ-Projekt Ein BlueJ-Projekt ist der Inhalt eines Verzeichnisses. das Projektname heißt wie

Mehr

Kontinuierliche Integration am Beispiel Jenkins

Kontinuierliche Integration am Beispiel Jenkins Kontinuierliche Integration am Beispiel Jenkins Sujeevan Vijayakumaran Ubucon, Berlin 20. Oktober 2012 1 / 25 Inhaltsverzeichnis 1 Über mich 2 Was heißt kontinuierliche Integration? 3 Test-Schnittstellen

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Agile Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de

Agile Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Agile Entwicklung àla The Eclipse Way Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Über mich Martin Lippert Senior-IT-Berater bei Akquinet Agile GmbH martin.lippert@akquinet.de

Mehr

antlogger SCMP Software Engineering Projekt Patrick Bründler, Pascal Mengelt, Andy Wyss, Fabian Heusser Dozent: Jörg Hofstetter

antlogger SCMP Software Engineering Projekt Patrick Bründler, Pascal Mengelt, Andy Wyss, Fabian Heusser Dozent: Jörg Hofstetter FHZ > FACHHOCHSCHULE ZENTRALSCHWEIZ HTA > HOCHSCHULE FÜR TECHNIK+ARCHITEKTUR LUZERN Abteilung Informatik- >Software Engineering- >Projekt AntLogger Software Engineering Projekt antlogger SCMP Patrick Bründler,

Mehr

Builddreikampf: Ant, Maven und Gradle. Sven Bunge / Carl Düvel

Builddreikampf: Ant, Maven und Gradle. Sven Bunge / Carl Düvel Builddreikampf: Ant, Maven und Gradle Sven Bunge / Carl Düvel holisticon AG Wettkampfplan 1. Die Regeln 2. Vorstellung der Kandidaten 3. Ring frei die Disziplinen! 1. Dependency Management 2. Multiprojektsupport

Mehr

Datenbank-Refactoring mit LiquiBase

Datenbank-Refactoring mit LiquiBase Datenbank-Refactoring mit LiquiBase Agile Software-Entwicklung mit RDBMS Refactoring & Change Management Benjamin Schmid Softwareentwicklung in der Praxis Hervorragende Lösungen beim Programmcode für:

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Buildsystem. Maven & Scons. Controls Entwicklungsforum Januar 2012

Buildsystem. Maven & Scons. Controls Entwicklungsforum Januar 2012 Buildsystem Maven & Scons Controls Entwicklungsforum Januar 2012 1 2 a call from the past Binary Repository Speichern von Artefakten (z.b. Shared Library und zugehörige Header) Versionierung von Artefakten

Mehr

Automatischer Build mit Maven 2

Automatischer Build mit Maven 2 Automatischer Build mit Maven 2 Stefan Scheidt OPITZ CONSULTING GmbH Ihr Referent Stefan Scheidt Senior Architekt bei der OPITZ CONSULTING GmbH Seit über 10 Jahren im Oracle- und Java-Umfeld tätig Schwerpunkte:

Mehr

Serbest Hammade / Resh serbest.hammade@hammade.de. Do, 21. Juni 2012

Serbest Hammade / Resh serbest.hammade@hammade.de. Do, 21. Juni 2012 Serbest Hammade / Resh serbest.hammade@hammade.de Do, 21. Juni 2012 Continuous Integration Konzept von Continuous Integration Vorraussetzungen für CI Vor- & Nachteile Jenkins Beispiel mit Java Beispiel

Mehr

So ziehen Sie Ihr Wordpress Blog zu STRATO um

So ziehen Sie Ihr Wordpress Blog zu STRATO um So ziehen Sie Ihr Wordpress Blog zu STRATO um Version 1.0 So ziehen Sie Ihr Wordpress Blog zu STRATO um Das Wordpress-Plugin Duplicator ermöglicht Ihnen, in wenigen Schritten Ihre Wordpress-Instanz umzuziehen.

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Konfigurationsmanagement mit Maven

Konfigurationsmanagement mit Maven Konfigurationsmanagement mit Maven Manfred Wolff, wolff@manfred-wolff.de, www.manfred-wolff.de Michael Albrecht, malbrecht@neusta.de, wwwneusta.de Im Entwicklungsstadium von Software spielen Managementfragen

Mehr

XenClient Enterprise Upgradeanleitung

XenClient Enterprise Upgradeanleitung XenClient Enterprise Upgradeanleitung Version 5.0 19. August 2013 Inhaltsverzeichnis Informationen zu diesem Dokument...4 Wichtige Hinweise zum Aktualisieren auf Version 5.0...4 Empfohlene Verfahren für

Mehr

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG Michael Palotas 7. April 2015 1 GRIDFUSION IHR REFERENT Gridfusion Software Solutions Kontakt: Michael Palotas Gerbiweg

Mehr

Crashkurs Subversion / Trac / Provisioning. Jan Zieschang, 04.01.2008, Berlin

Crashkurs Subversion / Trac / Provisioning. Jan Zieschang, 04.01.2008, Berlin Crashkurs Subversion / Trac / Provisioning Jan Zieschang, 04.01.2008, Berlin Agenda 2 Subversion Das SCM TortoiseSvn Der Client Trac Das Tracking-Tool Provisioning Das Provisioning Tool Arbeiten mit Subversion/TortoiseSvn

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014 Entwicklungsumgebungen Packer, Vagrant, Puppet Alexander Pacnik Mannheim, 10.11.2014 inovex... über inovex und den Referenten 2 Entwicklungsumgebungen... Übersicht Einführung Packer Konfiguration Packer

Mehr

Deployment Deployment Seite 1 / 25

Deployment Deployment Seite 1 / 25 Seite 1 / 25 Versionskontrolle Seite 2 / 25 Verteilte Versionskontrollsysteme Seite 3 / 25 Seite 4 / 25 Zusammenfassung Versionskontrolle Wir verwenden bei der Entwicklung das dezentralisierte Versionskontrollsystem

Mehr

Build-Pipeline mit Jenkins

Build-Pipeline mit Jenkins JUG Augsburg 24.10.2013 Seite 1 Wer sind wir? Agiler Architekt und Entwickler Eigenes Produkt mit kompletter Pipeline / CD aktuell: Architekt / Entwickler in einem großen Entwicklungsprojekt im Automotiv

Mehr

Agile Qualitätssicherung. Holger Schmeisky, 17.10.2013

Agile Qualitätssicherung. Holger Schmeisky, 17.10.2013 Agile Qualitätssicherung Holger Schmeisky, 17.10.2013 Agile Qualitätssicherung Studie SoundCloud Team Payment Entwicklungsprozess Qualitätssicherung Analyse / Diskussion 17.10.2013 Holger Schmeisky - Agile

Mehr

Software Engineering. 14. Build und Deployment. Franz-Josef Elmer, Universität Basel, WS 2006/07

Software Engineering. 14. Build und Deployment. Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering 14. Build und Deployment Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 14. Build und Deployment 2 Übersicht Dokumentation, Installationssoftware, etc. Source

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel XDK

Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK vertraut. Es wird Schritt für Schritt die erste eigene Hybrid-App entwickelt

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

Software Engineering in

Software Engineering in Software Engineering in der Werkzeuge für optimierte LabVIEW-Entwicklung Folie 1 Best Practices Requirements Engineering Softwaretest Versionsmanagement Build- Automatisierung Folie 2 Arbeiten Sie im Team?

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Dezentrale Versionsverwaltung

Dezentrale Versionsverwaltung Dezentrale Versionsverwaltung mit GIT with that guy 14.08.2012 Lars Kumbier 1 Versionsverwaltung? 14.08.2012 Lars Kumbier 2 Versionsverwaltung? Speichern unterschiedlicher Entwicklungsschritte (oder Versionen)

Mehr