Es liegt in der menschlichen Natur, dass man etwas vergisst einzuchecken, eine Änderung nicht abspeichert oder einfach einen Fehler macht. Damit diese Fehler frühzeitig erkannt werden und die Qualität der Software Anpassungen stimmen, haben wir unseren hauseigenen Buttler in Betrieb genommen. Herzlich willkommen im Team Jenkins.
Warum wir Jenkins unbedingt in unserer Firma benötigen
Bis vor einigen Monaten lief unser Buildprozess intransparent und sehr statisch. Der Buildprozess wurde jeweils am Abend um 18:30 Uhr mit der Windows Aufgabenplanung gestartet. Nach diesem Job wurden die kompilierten Files auf die Abnahmeumgebung kopiert, wieder mit der Windows Aufgabenplanung. Meist wurden die Fehler vom Produktmanager erst nach Stunden des Testens gefunden. Ob wirklich eine Aufgabe Fehlerhaft ausgeführt wurde, konnte nur über die Logfiles herausgefunden werden. Gäbe es doch nur einen Buttler, der sich meldet wenn etwas schief läuft…
Den gibt es – Jenkins Automationsserver ist die Lösung!
Meine best practises mit Jenkins
Ein Tool ist nur so gut wie man es einrichtet. Darum habe ich meine Erfahrungen hier für dich niedergeschrieben:
#1: Installiere die LTS Version für deine Produktive Umgebung.
#2: Der open source Automation Server bietet unzählige Plugins um Projekte jeglicher Art automatisieren zu können. Plugins sind im Grunde genommen eine gute Sache, jedoch sollten nur so wenige wie möglich und so viele wie es benötig im Jenkins installiert werden. Achte bei der Auswahl deiner Plugins darauf, dass sie aktuell sind, eine gute Dokumentation bieten und gute Bewertungen haben.
#3: Wer kennt es nicht, man hat unzählige Logins und dann kommt meine IT und möchte, dass du dein Passwort alle drei Monate änderst. Damit du dir kein zusätzliches Kennwort für Jenkins merken musst, binde ihn an dein Active Directory an. Zum Beispiel mit diesem Plugin.
#4: Wenn du die Anbindung am Active Directory erfolgreich abgeschlossen hast, empfehle ich dir die AD Gruppen via Matrix-based security zu berechtigen. Diese Berechtigung findest du unter Manage Jenkins/Configure Global Security unter dem Menüpunkt Matrix-based security.
#5: Die Job- und Plugineinstellungen werden im Jenkins Home Verzeichnis gespeichert. Damit bei einem Ausfall nicht alles reproduziert werden muss, lege dein Jenkins Home Verzeichnis auf einem gesicherten Ort ab. Hier wird beschrieben, wie du das Jenkins Home Verzeichnis verschieben kannst.
#6: Die einfachen Freestyle Jobs eignen sich gut um gewisse Batch- oder Kompilierfiles zu testen. Meine Empfehlung für den produktiven Betrieb lautet jedoch die Pipelines zu verwenden. Mit den Pipelines bist du viel flexibler. Zusätzlich kannst du dir eine Massgeschneiderten CI/CD Pipeline bauen, welche wie die Faust aufs Auge in deinen Betrieb passt.
#7: Überprüfe bei deinen Buttler regelmässig ob Updates installiert werden müssen (ich empfehle ein Mal pro Woche). Nachdem Update ist ein Neustart vom Jenkins und von deinem Server empfohlen. Um sicher zu gehen, dass alles wieder gestarten werden konnte, überprüfe nach dem Update das Logfile unter Manage Jenkins/System Log.
#8: Die Idee hinter DevOps ist es nach jedem Commit in einem releaseble State zu sein. Dadurch wird nachdem Fertigstellen des Jobs umgehend erkannt, ob alle Tests und der Kompiliervorgang erfolgreich abgeschlossen werden konnten. Wir haben dies mit dem Post Commit Trigger gelöst. Das Pollen von der Sourceverwaltung wird NICHT empfohlen, da es viele Ressourcen benötigt. Eine Anleitung dazu findest du hier, hier und hier.
Fazit
Unser Firmeneigener Buttler hat uns schon viele Male aus der Sch….. geholfen. Einen grossen Teil haben wir bereits umgesetzt. Fertig werden wir nie sein, da wir ihr alle wisst; die Technik schläft nicht!
