Continuous Integration (CI)

Bei größeren Projekten mit mehreren Entwicklern muss der Programm-Code zentral gespeichert werden, damit alle Entwickler auf den gleichen Stand des Programm-Codes Zugriff haben. Der Programm-Code aller Entwickler muss irgendwann zu einer kompletten Anwendung zusammengebaut, getestet und dann ausgeliefert werden. In der Web-Entwicklung wird die Anwendung meistens auf einen Applications-Server, wie z.B. WildFly oder Tomcat, ausgeliefert.

Damit das Zusammenbauen, das Testen und das Ausliefern und Reporting der eventuellen Fehler regelmäßig und automatisiert erfolgt, gibt es die Continuous Integration.

Continuous Integration (CI) bedeutet:

  • Tests automatisiert durchzuführen
  • Zusammenbau der Applikation automatisiert durchführen
  • Ausliefern auf dem Applications-Server automatisch durchführen

Für eine neue Web-Applikation benötige ich demnächst Tools, um CI im Projekt umzusetzen. Dazu verschaffe ich mir gerade einen Überblick, was dazu alles nötig ist. Grundsätzlich benötigt man folgende Komponenten für diese Anforderung:

  • Ein Repository zur zentralen Ablage der Quelltexte und der Dokumentation aller Entwickler im Projekt. Hier steht zur Auswahl GIT oder Subversion
  • Ein Build-Tool, um alle Java-Klassen, Java-Bibliotheken und alle was sonst noch dazugehört zu einer lauffähigen Anwendung zusammenzubauen. Hier steht zur Auswahl das klassische ANT, maven oder gradle zur Auswahl
  • Ein Server auf dem die Anwendung ausgeliefert und ausgeführt wird, um dann im Web-Browser aufgerufen werden kann. Hier stehen zur Auswahl der JBOSS-Nachfolger Wildfly oder Tomcat
  • Der automatisch Build, das Ausführen der Unit-Tests und schliesslich das ausliefern auf den Application-Sserver soll ein ein Continous Integration – Tool übernehmen. Hier habe ich an Jenkins gedacht
  • Eine Datenbank zum Ablegen der dynamische Daten
  • Am Schluss für den Live-Betrieb noch eine Apache-Webserver als Loadbalancer, SSL-Zertifikats-Container und Reverse-Proxy, damit der Application-Server nicht im Web sichtbar ist

Folgender Plan, um das Ganze zu testen.

Als zentraler Server verwende ich den Raspbarry PI, der mit seinen Ubuntu-Linux gut dafür geeignet ist. Sicher nicht der schnellste Server, aber zum Testen und versuchen gut geeignet.

Der Entwicklung-Rechner soll der iMAC mit OS/X und der Entwicklungsumgebung Eclipse für eine Spring Boot Anwendung sein.

Was wird alles auf dem Server installiert?

  • Zentrales GIT-Repository zur Ablage des Projekts
  • Jenkins-Server
  • Erweitern des Jenkins mit Plugins:
    • GIT-Plugin, für den Zugriff auf das zentrale Repository mit der Anwendung
    • Gradle-Plugin, für den automatischen Build der Anwendung
    • Junit-Tests-Plugin zum Ausführen der Tests und Erstellen von Reports
    • Checkstyle-Plugin zur Code-Analyse und erstellen von Reports
    • Deployment-Plugin für das automatische Deployment und Ausführen der Spring Boot Anwendung
  • Build – Tool Gradle zum bauen der Anwendung durch den Jenkins
  • Tomcat als Applikation-Container

Was braucht man für den Entwicklungsrechner?

  • Entwicklung-Umgebung Eclipse mit JAVA – JDK
  • GIT-Client zu hochladen der Anwendung in das zentrale GIT-Repository
  • Gradle, zum Bau und Test der Anwendung

Was soll der Jenkins-Server alles können?

  • VerwendungProjekts aus dem zentralen GIT-Repository
  • Build des Projekts mit dem Build-Tool Gradle aus den aktuellen Anwendung-Dateien aus dem GIT-Repository
  • Ausführen erstellen von Reports der JUNIT-Tests
  • Anzeige von Metriken für den Build-Prozess
  • Code-Analyse und erstellen von Reports
  • Automatisches Deployment der Anwendung in einen Application-Server bzw. Servlet-Container