5 Dinge, die nicht in deiner CI/CD Pipeline fehlen sollten!

Gepostet am 11. Juni 2023

5 Minuten • 889 Wörter • Andere Sprachen: English

In den letzten Jahren ist DevOps und Continuous Integration zunehmend beliebter geworden, um die Agilität in der Softwareentwicklung zu verbessern und Features schneller in Produktion zu bringen. Aber schnelle Auslieferung darf nicht bedeuten, dass Qualität oder Sicherheit dafür reduziert werden darf. Tatsächlich ist die Automatisierung von Prozessen und die Einbindung von DevSecOps sowie automatisierten Tests in die CI/CD Pipeline meiner Meinung nach die Grundlage für Geschwindigkeit in der Softwareentwicklung.

Hier sind 5 Dinge, die in deiner CI/CD Pipeline unbedingt vorhanden sein sollten:

1. Automatisierte Tests

Du hast es wahrscheinlich schon 1 Mio Mal gehört, aber das macht es nicht weniger wahr: Das Wichtigste, was du in deine CI/CD-Pipeline einbauen solltest, sind Unit- / Integrations- / End2End-Tests!

Automatisierte Tests ermöglichen es Entwicklern, Probleme zu erkennen und zu beheben, bevor sie überhaupt in Produktion gelangen, was langfristig Zeit und Ressourcen spart. Außerdem ersetzen sie langsame und fehleranfällige manuelle Tests, die immer wiederholt werden müssen und daher nicht skalierbar sind. Wenn du noch keine automatisierten Tests hast, leg endlich los!

2. Codequalität

Sobald du nicht mehr alleine an einem Projekt arbeitest, solltest du Standards festlegen, wie Code geschrieben sein soll, um ihn wartbar zu halten (und um Diskussionen wie Tabs vs Leerzeichen zu stoppen😂). Daher solltest du einige Qualitätskontrollen wie zum Beispiel SonarCloud / Sonarqube oder ähnliches in deine CI/CD Pipeline integrieren. Diese Tools helfen dir, nach Programmierfehlern, Formatierungsproblemen, Sicherheitsproblemen (wie Klartextpasswörtern in deinem Code) und anderen schwerwiegenden Fehlern zu suchen, die verhindert werden können, noch bevor dein Code die main branch erreicht. Außerdem geben sie dir auch einen objektiven Überblick über den Status deiner Codebasis.

3. Kontinuierliche Sicherheitsscans

Jetzt, da wir ein angemessenes Maß an Codequalität haben, sollten wir sicherstellen, dass wir keine unsichere Code-Infrastruktur veröffentlichen oder pflegen. Verwendest du immer noch veraltete Node.js-Versionen oder Docker-Images? Das ist ein absolutes No-Go. Implementiere Tools wie Snyk oder Trivy, um deine Docker-Images auf potenzielle Sicherheitsprobleme zu scannen. Analysiere deinen Code mit Tools wie OWASP-Quellcode-Analysewerkzeugen. Automatisiere das Aktualisieren von Abhängigkeiten, indem du beispielsweise Dependabot PRs erstellen lässt, um deine Abhängigkeiten von Drittanbietern zu aktualisieren. Sicherheit muss nicht unnötig kompliziert werden, wenn sie ein grundlegender und dauerhafter Teil deiner Bereitstellungspipeline ist.

4. Lizenz-Scanning

Ein Aspekt, der dein Projekt oder dein Unternehmen viel Geld kosten kann, ist die Möglichkeit, Drittanbieter-Abhängigkeiten zu nutzen, die nicht unter korrekten Lizenzen stehen. Der sogenannte “Copyleft”-Effekt könnte dich und deine geistigen Eigentumsrechte ernsthaft beeinträchtigen. Daher solltest du deine Codebasis mit einem Lizenz-Checker scannen, der eine definierte Liste von Lizenzen enthält, die von dir oder deinem Unternehmen zugelassen sind. Auf diese Weise können keine falschen Lizenzen “durchrutschen” und in Produktion gelangen.

5. Bereitstellung und Rollback-Pläne

Das Endziel von CI/CD-Pipelines ist normalerweise die Bereitstellung in Produktion. Es gibt jedoch noch einige Schritte, die dazwischen berücksichtigt werden sollten:

Feature-Branch-Environments

Wenn du den Prozess zur Bereitstellung von Umgebungen bereits automatisiert hast, gibt es keinen Grund, auf “Feature-Branch-Environments” für Frontend-Anwendungen zu verzichten. Das sind kurzlebige Umgebungen, die nur dazu dienen, dass Personen (QA, Endnutzer, Business,…) eine bestimmte Funktion oder einen Bugfix isoliert von allem anderen testen können. Feature-Branch-Environments sind super nützlich, weil du keine Änderungen in main übernimmst, die nicht den Geschäftsanforderungen entsprechen oder Fehler aufweisen, die nur durch manuelles / exploratives Testen erkennbar sind. Der Versuch, nur bestimmte Teile eines Releases zurückzusetzen, führt meiner Erfahrung nach fast immer zu einem katastrophalen Ergebnis.

Canary Deployments

Wenn du serverseitigen Code bereitstellst, oder Code bei dem du nicht absehen kannst, ob das Update etwas kaputt macht (bevor es in Produktion ist), überlege dir einmal, wie du mögliche Fehler erkennen kannst und bringe es dann mithilfe von Canary Deployments trotzdem in Produktion. Wie funktioniert das?

Überlege, was schiefgehen könnte
Mache es messbar, indem du Metriken erstellst (z.B. Antwortzeit / Anfrage, Fehlermeldungen in einer Logdatei / Minute, Authentifizierungsfehler / Sekunde,…)
Implementiere diese Metriken

Wenn alles fertig ist, kannst du diese Metriken mit Tools wie Argo Rollouts verwenden, um damit Canary Deployments durchzuführen. Diese rollen Änderungen nach und nach an Nutzer aus und überwachen die Anwendung gleichzeitig. Zum Beispiel:

gib 10% der Nutzer den neuen Code und 90% den alten
überwache, ob die Metriken innerhalb der definierten Schwellenwerte bleiben
gib 20% der Nutzer den neuen Code und 80% den alten
…wiederhole dies, bis das Rollout vollständig ist

Glaub mir, Canary-Deployments werden dich vor einigen Herzinfarkten bewahren und deine CI/CD-Pipeline deutlich aufwerten!

Automatisiere deine Rollback-Pläne

Wie lange dauert es, um die vorherige Version deiner Software wieder in Produktion zu bringen? Ist deine Datenbank-Migration umkehrbar? Was passiert, wenn jemand versehentlich deine Infrastruktur löscht?

Denke über all diese Fälle nach und automatisiere das Testen und Validieren so weit es irgendwie möglich ist. Zum Beispiel:

Infrastructure as Code hilft bei versehentlichem Löschen deiner Infrastruktur
Die Ausführung von “terragrunt plan” vor der Übernahme von Änderungen erkennt, ob die Konfiguration in sich konsistent ist
Blue/Green-Deployments machen es möglich, Änderungen am Frontend innerhalb von 30 Sekunden zurückzusetzen
Das vor- und zurückrollen von Datenbank-Migrationen (hoch/runter/hoch) vor der Testphase in der Entwicklung hilft sicherzustellen, dass sie sauber umkehrbar sind
…

Beim Lesen sind dir wahrscheinlich noch deutlich mehr Ideen gekommen. Automatisierung in CI/CD-Pipelines können deinem Programmier-Workflow deutlich helfen, aber übertreibe es am Anfang nicht. Wie bei fast allen Dingen lohnt es sich, klein anzufangen, auszutesten und von dort aus immer weiter zu inkrementieren. Setze dir zum Beispiel zuerst das Ziel, möglichst schnell einen Schritt aus jedem der oben genannten Bereiche zu implementieren und baue deine Pipeline von dort weiter aus.