Notes:
- Hallo zusammen und willkommen zur Open Space Diskussion über meine These "Weniger Pipelines, Mehr Spaß!?".
Notes:
Mein Name ist Karsten Günther.
Ich bin seit 20 Jahren als Softwareentwickler im Automobilbereich unterwegs.
Von Ada, Embedded C, C++, Perl, Tcl, Python über die Entwicklung von Dev Tools bis hin zu Jenkins Pipelines hab ich schon eine Menge gesehen und gemacht.
Aktuell arbeite ich als Platform Architekt im Rhein-Main-Team der Marquardt GmbH.
Dort geht es um Software-Produktlinien, interne Developer Plattformen, Automatisierung und CI/CD.
--
-
Tue Gutes ...
- Jenkins/CI in Automotive/Embedded-C
- Unsere Pipelines und Quality Gates
- ... und rede darüber!
Notes:
-
Okay, was will ich eigentlich von euch?
-
Eins vorne weg: ich war noch die in so einem Open Space.
-
Ein alter Chef von mir hat immer gesagt: Tue Gutes und rede darüber! (Ich glaube, der Spruch ist von Goethe.)
-
Also mach ich das, tue Gutes ...
-
und erzähle euch von meiner Erfahrung mit Jenkins und CI in der Automotive/Embedded Welt und ...
-
... wo die Reise mit unseren Pipelines und Quality Gates so hin gehen soll.
-
Tja, und rede darüber! Das würde ich gerne mit euch nach meinen Vortrag ausgiebig tun.
Back to 2005
Note:
- Tja, wo komme ich her?
--
- SW-Entwicklung für Bremsensteuergeräte
- Embedded C? Das hatten wir doch an der Uni!
- Es ist dein Code, aber verändere bloß nichts!
- Always remember: don't break the build!
- Dem Ingenieur ist nix zu schwör!
Note:
Und der Job?
-
Hacken Embedded C für Bremsensteuergeräte
-
Kein Problem, das hatten wir doch an der Uni.
-
Man bekam Verantwortung für einen Teil des Codes, aber verändern sollte man ihn möglichst nicht.
-
Warum? Don't break the build!
-
Klang schwierig, aber wir hatten ja an der Uni gelernt: Dem Ingenieur ist nix zu schwör!
--
- Keine Unit Tests
- Kein CI, nur nightly builds
- Viele Integrationstests, hauptsächlich Fahrversuch
- Code Reuse über alle Projekte
- Mehrere 100 Entwickler weltweit an einer Codebasis
Note:
Die Ausgangslage?
click
Oha, keine Unit Tests.
Keine einige Zeile Testcode im Repository.
Klar, wo testet man Bremsen? Im Auto.
click
Gut, es wurde ein bisschen SIL und HIL gemacht.
click
Aber das meiste wurde im Fahrversuch getestet.
Viele Features waren also irgendwann, irgendwo in irgendeinem Projekt getestet.
Daher das Motto: besser nichts ändern.
click
Aber wie soll das gehen, wenn der Code über alle Projekte geshared ist,
alle Kunden mit neuen Anforderungen um die Ecke kommen ..
click
und mehrere 100 Entwickler weltweit an einer Codebasis arbeiten?
--
--
Note:
- Die Krux mit den Jenkins Pipelines
- Java-Entwickler, die einfach Java programmieren wollen
- Und es dann nicht dürfen!
- Viele Missverständnisse, was wo ausgeführt wird
- Keiner versteht mehr, wie die Pipeline funktioniert.
- Keiner kann debuggen.
- Keiner kann es nachvollziehen.
- Anti-Pattern von CI.
- 2 Scrum Teams waren zu wenigstens 50% mit Maintenance ausgelastet.
- Es ging die "Service Card" um.
--
Note:
Klar, wenn man mit Jenkins startet, geht es mit einfachen freestyle jobs los.
Einfach nur bauen.
--
Note:
- dann passiert plötzlich doch ein bisschen mehr
- nach und nach müssen Tools zusammengeklebt werden
- Anbindung ans SCM System
- Reporting
--
--
Note: Höher, schneller, weiter: Eine Pipeline, um sie alle zu knechten.
--
- Pipeline als Ersatzbuildsystem
- Buildlogik in Pipelines (10000e Zeilen Groovy DSL)
- Ausreichend? Nein! Shared Libraries und Plugins gibt es ja auch noch ...
- Nicht nachvollziehbare CI Ergebnisse
- Worst case: getrennte Repos für Produkt und Pipelines
Note:
- CI-System macht andere/mehr Sachen als die Buildumgebung.
- Mit dem Hammer in der Hand sieht die Welt wie ein Haufen von Nägeln aus.
- Birmingham screwdriver
--
- Pipeline as Code
- Dependencies as Code
- Quality Checks as Code
- Everything else as Code
Note:
--
- Checkout vom Repository
- Installation aller Abhängigkeiten
- Ausführen ausgewählter Tests als Quality Checks
- Archivieren der Ergebnisse
--
...
node() {
stage("Checkout Code") {
checkout scm
}
stage("Installation of Dependencies") {
bat "call build.bat -install -installOptional || exit /b 1"
}
stage ("Execute Tests") {
bat "call build.bat -selftests -marker 'build_debug or reports' || exit /b 1"
}
stage("Deploy Test Results") {
junit allowEmptyResults: false, keepLongStdio: false, testResults: "test/output/test-report.xml"
}
...
}
...--
...
jobs:
test:
name: CI Gate
runs-on: windows-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Installation of Dependencies
run: |
.\build.ps1 -install
shell: powershell
- name: Execute Tests
run: |
.\build.ps1 -selftests -marker "build_debug or reports"
shell: powershell
- name: Deploy Test Results
uses: EnricoMi/publish-unit-test-result-action/windows@v2
if: always()
with:
files: |
test/output/test-report.xml
...- Feedback welcome!
- Ich hab gehört, Jenkins ist tot! Wirklich?
- Wie sehen eure Pipelines so aus?
- Habt ihr Spaß mit CI?
