Raspberry Pi als Jenkins Server – Teil 4

In diesem Teil werden wir den zuletzt automatisch ausgecheckten Source Code automatisiert bauen. Der zweite Step in der Build Chain sorgt für eine täglich aktuelle Software und liefert dem Entwickler sofort Rückmeldung ob eine der letzten Änderungen zu einem Problem geführt hat.

Raspberry Pi als Jenkins Server – Teil 4

Bauen, bauen, bauen. Heute wird Software täglich gebaut. Damit stellt man sicher, dass die letzten Änderungen vom Team die Software nicht kaputt gemacht haben. Gerade bei großen Teams kann jeder Entwickler lokal bauen, baut man aber die gesamte Software, dann läuft schon mal was schief. Automatische Builds der aktuellsten Version im Source Control liefern neben einer stets aktuellen Software auch den einfachsten Test: kann der Code überhaupt gebaut werden?

Build Tool auswählen

Die erste Frage die man sich stellen muss lautet: wie baust du deinen Source Code? Die Frage ist von Entwickler zu Entwickler und von Programmiersprache zu Programmiersprache unterschiedlich zu beantworten. Aus diesem Grund gibt es im Jenkins Server nicht die eine Lösung für alles. Unter der Konfiguration findet man beim Step Buildverfahren folgende Auswahl:

Je nach belieben kann man eines der Build Tools auswählen. Jenkins erlaubt standardmäßig:

• Ant
• Gradle
• Maven
• Docker

zusätzlich kann man auch Kommandos in der Shell ausführen oder eine Windows Batch-Datei ausführen. Der Jenkins Server selbst kann ja sowohl unter Linux als auch unter Windows laufen. Wie bei Git gilt hier übrigens auch, dass das jeweilige Build System installiert sein muss. Unter Jenkins -> Jenkins verwalten -> Konfiguration der Hilfsprogramme kann man den Pfad zum jeweiligen System konfigurieren:

In meinem Fall geht es um ein C/C++ Projekt. Der Einfachheit verzichte ich auf ein Build System und baue meinen Source Code mit g++ in Shell Kommandos, ich wähle also im obigen Step Shell aus. Auch von dort könnte man ein beliebiges Build System wie make oder cmake aufrufen.

Build Script erstellen

Wenn man noch kein Build Tool verwendet kann man immer noch mit dem am System installierten Tools arbeiten wie dem Compiler. Ob nun Java, C# oder C++, über die Kommandozeile lässt sich damit immer der Quellcode bauen. So habe ich auch für mein eigentlich in Visual Studio erstelltes Projekt und mit dem Microsoft C++ Compiler erstellten Quellcode am Raspberry Pi die Build Steps für die Kommandozeile notiert. Diese kann man unter dem Buildverfahren im Textfeld Build ausführen eingeben:

mkdir -p Debug
g++ -c ./GraphPerformanceTest/RandomNumberGenerator.cpp -g -O0 -Wall -o ./Debug/GraphPerformanceTest_RandomNumberGenerator.cpp.o -I. -I.
g++ -c ./GraphPerformanceTest/main.cpp -g -O0 -Wall -o ./Debug/GraphPerformanceTest_main.cpp.o -I. -I.
g++ -c ./GraphPerformanceTest/ClassHierarchyFactory.cpp -g -O0 -Wall -o ./Debug/GraphPerformanceTest_ClassHierarchyFactory.cpp.o -I. -I.
g++ -c ./GraphPerformanceTest/NameGenerator.cpp -g -O0 -Wall -o ./Debug/GraphPerformanceTest_NameGenerator.cpp.o -I. -I.
g++ -o ./GraphPerformanceTest/GraphPerformanceTest ./Debug/GraphPerformanceTest_main.cpp.o ./Debug/GraphPerformanceTest_RandomNumberGenerator.cpp.o ./Debug/GraphPerformanceTest_ClassHierarchyFactory.cpp.o ./Debug/GraphPerformanceTest_NameGenerator.cpp.o -L.

Über den Button „Jetzt bauen“ kann man die Konfiguration testen, ich habe insgesamt 3 Versuche bis zum ersten erfolgreichen Build benötigt. Einmal aufgesetzt verrichtet Jenkins nun mit dem Cron den Dienst und sollte nach jeder Änderung im Source Code spätestens in der Nacht die aktuelle Programmversion erstellen.

Achtung: ohne Build Script, welches mit Git verteilt wird muss dieses Script laufend angepasst werden (beispielsweise wenn eine neue Datei hinzu kommt). Das ist keine gute Lösung, man will die Arbeit ja automatisieren. Deshalb sollte man in einer Produktivumgebung unbedingt auf ein Build System wechseln, auch wenn es unter C++ nur make ist.

Build testen

Testen kann man das Setup nun manuell am Jenkins Server über den „Jetzt bauen“ Button oder automatisiert über eine Codeänderung. In meinem Fall wird die erstellte ausführbare Datei in im Projektordner von Jenkins unter /var/lib/jenkins/workspace. Dieser Pfad ist bei Windows anders und kann auch in diversen Linux Distributionen unterschiedlich sein.

Nachdem nun klar ist, dass der Build funktioniert sollte man nicht darauf vergessen auch das erstellte Programm einmal auszuführen. Schließlich soll es sowohl am Entwicklungssystem (Windows 10) als auch unter Linux am Raspberry Pi funktionieren. In meinem Fall funktionierte dieser manuelle Test ebenfalls.

Fazit

Ich habe gezeigt wie man ein Build Script dem Jenkins Projekt hinzufügt und wie das ohne Build System funktioniert. Für Produktivsystem empfehle ich aber dringend auf ein Build System zu wechseln.

Teil 1 | Teil 2 | Teil 3 | Teil 4