Andreas Bruns

Softwareentwicklung für Oldenburg und Bremen

CloudBees – Continuous Integration & Delivery leicht gemacht

Wenn man als SW-Entwickler eine kleine Webanwendung für Freunde, Kollegen oder die ganze Menschheit bereitstellen möchte, müssen oft einige Herausforderungen gemeistert werden. Das eigentliche Programmieren der Anwendung geht vielleicht noch recht problemlos. Aber es entsteht ja leider noch allerhand weiterer Aufwand, um beispielsweise die benötigte Infrastruktur zu installieren:

  • Verwendung einer Quellcodeverwaltung (z.B. Git)
  • Installation einer Datenbank (z.B. MySQL, PostgreSQL)
  • Ausführen von Entwickler-Tests (z.B. mit Ant oder Maven)
  • Bauen der Anwendung (z.B. mit Ant oder Maven)
  • Bereitstellung der Anwendung auf einem Server (z.B. mit ssh-Skripte)
  • Testen der bereitgestellten Anwendung (z.B. manuell durch den Entwickler)

Sobald wir öfters neue Anforderungen oder Bugfixes ausliefern müssen, sollten wir diese Schritte nicht mehr manuell durchführen sondern automatisiert haben. Das Zauberwort heißt hier natürlich Continuous Integration und falls wir fehlerfreie Software auch gleich deployen, sind wir schon bei Continuous Delivery. Der CI-Server Jenkins (vormals Hudson) leistet dabei gute Dienste. Den müssen wir uns noch nicht einmal selber installieren, sondern wir bekommen ihn als Platform as a Service (PaaS) von CloudBees bereitgestellt. Dazu liefert uns CloudBees auch alle weiteren Werkzeuge, sodass Continuous Delivery problemlos realisierbar ist:

CloudBees: Continuous Cloud Delivery

CloudBees bietet unter den Begriffen Dev@Cloud und Run@Cloud einiges an nützlicher Infrastruktur, die wir nicht mehr selber aufsetzen müssen:

  • Repositories für Quellcodeverwaltung: Git, Subversion
  • Maven-Repository
  • Jenkins CI-Server
  • Datenbanken: MySQL, MongoDB
  • Laufzeitumgebungen: Java, Grails
  • weitere Services: Papertrail, MongoHQ, Solar, CloudAMQP und viele mehr

CloudBees: Platform Overview

Beispielanwendung mit ClickStart

Unter CloudBees-ClickStart kann man einfach fertige Beispielanwendungen auswählen und installieren. Dabei wird zumeist ein Git-Repository mit einem Jenkins-Build angelegt und eventuell eine fertige Webanwendung deployt, die auf eine neu angelegte Datenbank zugreift. Falls man nur mal einen Blick in den Quellcode machen möchte, muss die ClickStart-Anwendung nicht gleich installiert werden, weil der Quellcde auch bei GitHub verfügbar ist.

CloudBees: ClickStart-Übersicht

CloudBees: ClickStart-Übersicht

Für eine Java-Webanwendung bietet Clickstart ‚Tomcat 7' (Github-Code) einen guten Start. Damit bekommt man eine fertige Java-Webanwendung mit Datenbank installiert. Wenn der Entwickler den Quellcode ausgecheckt hat, kann er ihn entsprechend anpassen, die Änderungen einchecken und der CloudBees-Jenkins sollte die Anwendung dann automatisch neu bauen und anschließend deployen.

Bei meinem lokalen Entwicklungszweig musste ich einige Anpassungen machen, damit das CloudBees-Projekt von Maven korrekt gebaut werden konnte:

  • maven-enforcer-plugin erforderte bestimmte Maven-Version:
    – erlaubte Maven-Version in Eltern-POM anpassen
    – oder Eltern-Eintrag in pom.xml herausnehmen
  • Compile-Fehler wegen falscher Annotation (z.B. @interface Resource):
    – JEE nutzt erweiterte Annotation, die im SDK so nicht vorhanden ist
    – daher korrekte Library in pom.xml ergänzen: jboss-annotations-api_1.1_spec
    – pom.xml um weitere build-Einträge ergänzen (Dank an Jaikiran)

     <build>
          <plugins>
             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>2.1</version>
                <executions>
                   <execution>
                      <goals>
                         <goal>copy</goal>
                      </goals>
                      <configuration>
                         <!-- Configure the plugin to copy the jar containing javax.annotation.*
                            to a folder named "endorsed" within the project's build directory -->
                         <artifactItems>
                            <artifactItem>
                               <groupId>org.jboss.spec.javax.annotation</groupId>
                               <artifactId>jboss-annotations-api_1.1_spec</artifactId>
                            </artifactItem>
                         </artifactItems>
                         <outputDirectory>${project.build.directory}/endorsed</outputDirectory>
                      </configuration>
                   </execution>
                </executions>
             </plugin>
     
             <!-- Setup the compiler plugin to use the endorsed directory containing
              our javax.annotation.* classes -->
             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                   <source>1.6</source>
                   <target>1.6</target>
                   <!-- Setup the compiler plugin to use the endorsed directory containing
                   the jar for javax.annotation.* classes. Remember that we setup this folder
                   via the maven-dependency-plugin configuration, above. -->
                   <compilerArgument>-Djava.endorsed.dirs=${project.build.directory}/endorsed</compilerArgument>
                </configuration>
             </plugin>
     
             <!-- Setup surefire plugin to use the endoresed directory containing our javax.annotation.* classes -->
             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.5</version>
                <configuration>
                   <!-- Setup the surefire plugin to use the endorsed directory containing
                   the jar for javax.annotation.* classes. Remember that we setup this folder
                   via the maven-dependency-plugin configuration, above. -->
                   <argLine>-Djava.endorsed.dirs=${project.build.directory}/endorsed</argLine>
                </configuration>
             </plugin>
          </plugins>
       </build>
    
  • verwendete Plugin-Versionen in pom.xml herausfinden und anpassen
    mvn --debug clean install
    

CloudBees-Toolkit für Eclipse

CloudBees bietet für Eclipse das CloudBees-Toolkit als Plugin an, mit dem die CloudBees-Funktionen direkt aus der Eclipse-IDE aufgerufen werden können. Dafür musste bei mir jedoch zunächst das Git-Plugin EGit installiert werden. In den Tutorials Getting Started with CloudBees and Eclipse wird die Verwendung des Plugins vorgestellt. Es ist ein schönes Gefühl, wenn man innerhalb der Entwicklungsumgebung direkten Zugriff auf die zugehörigen Builds und Deployments hat 😉

CloudBees: Eclipse-Plugin

CloudBees: Eclipse-Plugin

ClouBees – ein schönes Fazit

Wenn man mit CloudBees für eigene Projekte als Basis startet oder einfach nur in den ClickStarts stöbert, kann man schon einige Vorzüge genießen:

  • keine eigene Infrastruktur für Code-Verwaltung, CI-Server, Datenbank und Hosting-Server nötig
  • einfacher, schneller Start ohne großen Konfigurationsaufwand für neue Projekte möglich
  • Anwendung beruht auf bewährter Basis mit Standard-Bibliotheken
  • Integration verschiedener Test-Frameworks in CI-Umgebung anhand von Beispielen direkt nutzbar
  • Webanwendung steht für Feedback mit Anwendern sofort lauffähig zur Verfügung

Trotz der vielen schönen Punkte sollte man jedoch nicht seine Produktiv-Anwendung in der CloudBees-Umgebung laufen lassen. Zumindest für personenbezogene Daten gilt das Bundesdatenschutzgesetz (BDSG), sodass man die Daten nicht unbedacht in der Cloud eines amerikanischen PaaS-Anbieters verarbeiten lassen darf (Heise-Artikel zu Cloud-Computing und Datenschutz: hier) .

Kommentare sind geschlossen.