DevOps, GitLab & Jenkins

DevOps ist eine Kultur und ein Ansatz zur Zusammenarbeit zwischen Entwicklung und Betrieb. Ziel ist es, Software schneller und stabiler bereitzustellen. Automatisierung und Verantwortungsteilung stehen im Fokus.

Schnellere Releases, höhere Qualität und stabilere Systeme. Silos zwischen Teams sollen aufgebrochen werden. Feedback-Zyklen werden verkürzt.

CI steht für Continuous Integration. Code wird regelmäßig integriert und automatisch gebaut und getestet. Fehler werden früh erkannt.

CD steht für Continuous Delivery oder Deployment. Änderungen werden automatisiert bis in Produktion gebracht. Manuelle Schritte werden minimiert.

Bei Continuous Delivery ist ein manueller Freigabeschritt nötig. Bei Continuous Deployment wird jede Änderung automatisch ausgerollt. Deployment ist dadurch schneller, aber riskanter.

GitLab ist eine Plattform für Versionsverwaltung und CI/CD. Sie kombiniert Repository, Pipelines und Projektmanagement. Alles ist in einem Tool integriert.

GitLab CI/CD ist das integrierte Pipeline-System von GitLab. Pipelines werden über .gitlab-ci.yml definiert. Builds, Tests und Deployments laufen automatisiert.

Jenkins ist ein Open-Source-Automatisierungsserver. Er wird häufig für CI/CD eingesetzt. Jenkins ist sehr flexibel, benötigt aber mehr Konfiguration.

GitLab CI ist nativ integriert. Jenkins benötigt Plugins. Jenkins ist flexibler, GitLab CI einfacher zu betreiben.

Eine Pipeline ist eine Abfolge automatisierter Schritte. Sie umfasst Build, Test und Deployment. Pipelines sorgen für reproduzierbare Abläufe.

Ein Job ist ein einzelner Schritt. Er führt Skripte aus. Mehrere Jobs bilden eine Pipeline.

Stages gruppieren Jobs logisch. Typische Stages sind build, test und deploy. Sie laufen sequenziell.

IaC beschreibt Infrastruktur in Codeform. Beispiele sind Terraform oder Ansible. Infrastruktur wird versionierbar und reproduzierbar.

Runner führen Pipeline-Jobs aus. Sie können lokal oder remote laufen. Docker-Runner sind sehr verbreitet.

Ein Agent führt Jobs für Jenkins aus. Er entlastet den Master. Skalierung wird möglich.

Artifacts sind Ergebnisse eines Builds. Beispiele sind JARs oder Docker Images. Sie werden für spätere Schritte genutzt.

Ein Pipeline Failure bedeutet, dass ein Job fehlgeschlagen ist. Die Pipeline stoppt meist. Entwickler müssen den Fehler beheben.

Rollback setzt eine frühere Version wieder ein. Es ist wichtig bei fehlerhaften Releases. Automatisierte Rollbacks sind Best Practice.

Zwei Umgebungen laufen parallel. Traffic wird umgeschaltet. Downtime wird vermieden.

Neue Versionen werden schrittweise ausgerollt. Nur ein Teil der Nutzer sieht sie. Risiken werden reduziert.

Features werden per Konfiguration aktiviert. Code ist bereits deployt. Releases werden flexibler.

Monitoring überwacht Systeme und Anwendungen. Metriken und Logs werden gesammelt. Probleme werden früh erkannt.

Logging speichert Ereignisse. Logs helfen bei Fehleranalyse. Zentrale Logs sind wichtig.

Observability kombiniert Logs, Metriken und Traces. Systeme werden transparent. Ursachen lassen sich besser finden.

Gates sind manuelle oder automatische Prüfungen. Sie stoppen Deployments bei Problemen. Qualität wird gesichert.

Security wird früh integriert. Stichwort DevSecOps. Sicherheitsprüfungen laufen automatisiert.

Secrets wie Passwörter werden sicher gespeichert. Tools wie Vault oder GitLab Secrets werden genutzt. Hardcoding wird vermieden.

Docker containerisiert Anwendungen. Umgebungen sind konsistent. Deployments werden einfacher.

Kubernetes orchestriert Container. Skalierung und Self-Healing sind möglich. Es ist zentral für moderne DevOps.

Environments repräsentieren Zielumgebungen. Beispiele sind dev, test, prod. Deployments werden zugeordnet.

Pipelines laufen vor dem Merge. Code wird geprüft. Qualität steigt.

Code Reviews sichern Qualität. Sie sind Teil der Pipeline. Wissen wird geteilt.

Zu wenig Automatisierung. Fehlendes Monitoring. Security wird ignoriert.

Bei komplexen, individuellen Pipelines. Wenn viele Plugins nötig sind. In bestehenden Jenkins-Landschaften.

Bei neuen Projekten. Wenn Einfachheit wichtig ist. Weniger Wartungsaufwand.

Über parallele Runner oder Agents. Cloud-Ressourcen werden genutzt. Lastspitzen werden abgefangen.

Automatisieren, messen, verbessern. Kleine Changes deployen. Verantwortung teilen.

Bei sehr kleinen Projekten ohne Betrieb. Wenn Prozesse stark reguliert sind. Trotzdem sind einzelne Praktiken sinnvoll.