Training Module

CI: Continuous Integration & der Build-Prozess

Baustein im DevOps-Kurscluster, klar abgegrenzt von den Nachbarmodulen: Workflow-Strategien und Review-Governance behandelt DevOps Code-Kollaboration, die YAML-Syntax einer echten Pipeline vermittelt Bitbucket Pipeline Grundwissen im Detail – hier geht es um Continuous Integration selbst. In diesem 145-Minuten-Modul (2 Stunden 25 Minuten) seht ihr an der Fallstudie BadCompany GmbH, wie isolierte Team-Builds und ein Build-Server unter dem Schreibtisch jede Integration ausbremsen, lernt Continuous Integration als Kultur und Technik kennen (Mainbranch muss grün sein, die drei Pipeline-Phasen Build/Test/Deploy), arbeitet die Designprinzipien reproduzierbarer Pipelines heraus (KISS/DRY/YAGNI, Container als Laufzeitumgebung, das Dilemma zwischen Zentralpipeline und Team-Hoheit) und vergleicht die vier gängigen CI-Systeme Jenkins, GitLab CI/CD, GitHub Actions und Bitbucket Pipelines. In der Hands-on-Übung wählt ihr für ein Fallbeispiel-Team begründet ein CI-System aus und skizziert die drei Pipeline-Stages – ganz ohne YAML.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

145 Minuten (2 Stunden 25 Minuten), live (remote oder vor Ort), Input & geführtes Hands-on zur CI-Systemwahl

Teilnehmende

Entwickler:innen und Team-/Build-Verantwortliche, die Continuous Integration als Kultur und Technik verstehen und ein CI-System begründet auswählen wollen

Voraussetzungen

Grundverständnis von Git-Branches und Pull-/Merge-Requests; DevOps Code-Kollaboration oder vergleichbares Vorwissen zu Workflow-Strategien hilft beim Einstieg, ist aber keine Pflicht

Warum dieses Training für deine Organisation wirkt

Klare Abgrenzung statt Doppelung

Workflow-Strategien und Review-Governance kommen aus DevOps Code-Kollaboration, YAML-Syntax und Hands-on-Pipeline-Bau aus Bitbucket Pipeline Grundwissen – hier bleibt der Fokus auf Continuous Integration als Kultur und Technik selbst.

Werkzeugwahl als Entscheidung, nicht als Dogma

Jenkins, GitLab CI/CD, GitHub Actions und Bitbucket Pipelines im direkten Vergleich anhand Wartungsaufwand, Rechteverwaltung, Security und Skalierung – als begründete Auswahlentscheidung, nicht als Glaubensfrage.

Hands-on statt Theorie allein

In der geführten Übung wählt ihr für ein Fallbeispiel-Team begründet ein CI-System aus und skizziert die drei Pipeline-Stages – ganz ohne YAML – und gleicht sie mit der Musterlösung ab.

Was Teilnehmende mitnehmen

  • Die Fallstudie BadCompany GmbH auf Build-Server-Ebene einordnen: isolierte Team-Builds, Big-Bang-Integration am Ende einer langen Entwicklungsphase, ein Build-Server unter dem Schreibtisch mit sporadischer Wartung und fehlende reproduzierbare Umgebung.
  • Continuous Integration als Kultur und Technik definieren: fortlaufende, mehrmals tägliche Integration in kleinen Schritten statt seltener großer Merges, mit der eisernen Regel “Mainbranch muss grün sein”.
  • Den Pipeline-Trigger über Feature-Branches und Pull-/Merge-Requests einordnen (die Workflow-Strategie selbst kommt aus DevOps Code-Kollaboration) und die drei klassischen Pipeline-Phasen Build, Test und Deploy unterscheiden.
  • Designprinzipien reproduzierbarer Pipelines anwenden: KISS, DRY, YAGNI sowie Container-Images als reproduzierbare Laufzeitumgebung gegen “Auf meinem Rechner lief es aber”.
  • Das Dilemma zwischen einer zentralen Unternehmens-Pipeline und Team-Hoheit einordnen: wann zentrale Vorgaben (Compliance, Security) sinnvoll sind und wann sie zum unwartbaren Monstrum werden.
  • Jenkins, GitLab CI/CD, GitHub Actions und Bitbucket Pipelines anhand Wartungsaufwand, Rechteverwaltung, Security und Skalierung gegeneinander abwägen.
  • In der Hands-on-Übung für ein Fallbeispiel-Team begründet ein CI-System auswählen und die drei Pipeline-Stages grob skizzieren, ganz ohne YAML.

Für wen dieses Modul ideal ist

  • • Entwickler:innen, die verstehen wollen, warum ihr Team trotz einzelner cleverer Build-Skripte an Merge-Hölle und Build-Server-Chaos leidet
  • • Team-/Build-Verantwortliche, die ein bestehendes CI-System (oft Jenkins) begründet ablösen oder ein neues Team-Setup aufbauen wollen
  • • Teams, die Pipeline-Designprinzipien (KISS/DRY/YAGNI, Container-Laufzeitumgebung) bewusst statt zufällig anwenden wollen
  • • Voraussetzung: Grundverständnis von Git-Branches und Pull-/Merge-Requests; DevOps Code-Kollaboration oder vergleichbares Vorwissen zu Workflow-Strategien hilfreich, keine Pflicht

Rahmendaten

  • • Dauer: 145 Minuten (2 Stunden 25 Minuten) live (remote oder vor Ort)
  • • Format: Input und geführtes Hands-on zur CI-Systemwahl, kein YAML-Drill
  • • Voraussetzungen: Grundverständnis von Git-Branches und Pull-/Merge-Requests, DevOps-Kurscluster-Vorwissen hilfreich

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu DevOps Code-Kollaboration (Workflow-Strategien/Governance dort, hier vorausgesetzt: Feature-Branches mit Pull-/Merge-Request-Trigger) und zu Bitbucket Pipeline Grundwissen (YAML-Syntax und Hands-on-Pipeline-Bau dort, hier bleibt es bei Konzept und Vergleich).

  2. Fallstudie BadCompany GmbH auf Build-Server-Ebene (20 min): isolierte Team-Builds, Big-Bang-Integration, ein Build-Server unter dem Schreibtisch und die fehlende reproduzierbare Umgebung.

  3. Continuous Integration als Kultur und Technik (30 min): Definition, “Mainbranch muss grün sein”, Feature-Branch und Pipeline-Trigger, die drei Pipeline-Phasen Build/Test/Deploy.

  4. Designprinzipien für Pipelines (20 min): KISS/DRY/YAGNI, Container als reproduzierbare Laufzeitumgebung, das Dilemma zwischen Zentralpipeline und Team-Hoheit.

  5. Werkzeugvergleich: Jenkins, GitLab CI/CD, GitHub Actions & Bitbucket Pipelines (30 min): Architektur, Wartungsaufwand, Rechteverwaltung, Security und Skalierung je System.

  6. Hands-on: CI-Systemwahl & Pipeline-Skizze für ein Fallbeispiel-Team (30 min): begründete Werkzeugwahl, drei Pipeline-Stages grob skizzieren – kein YAML –, Abgleich mit der Musterlösung.

  7. Fazit & Aktionsplan (5 min): Rückbezug zum CALMS-Baustein Automatisierung aus DevOps Grundlagen, Ausblick auf DevOps Code-Kollaboration und auf Toolchain-Evolution für die organisatorischen Reifestufen hinter der Werkzeugwahl.

Hands-on Inhalte (Auszug)

Fallstudie BadCompany GmbH

  • Isolierte Team-Builds mit unterschiedlichem Rhythmus, Big-Bang-Integration am Ende
  • Build-Server unter dem Schreibtisch: sporadische Wartung, keine reproduzierbare Umgebung
  • Resignation im Team: Niemand baut das Projekt mehr regelmäßig, QA gilt als fremde Aufgabe

CI als Kultur & Technik

  • “Mainbranch muss grün sein” als eiserne Regel mit höchster Priorität
  • Feature-Branch löst über Pull-/Merge-Request automatisch die Pipeline aus
  • Die drei Pipeline-Phasen: Build (Artefakt), Test (automatisiert), Deploy (Zielumgebung)

Designprinzipien & Werkzeugvergleich

  • KISS, DRY, YAGNI und Container-Images als reproduzierbare Laufzeitumgebung
  • Zentralpipeline vs. Team-Hoheit: wann zentrale Compliance-Vorgaben sinnvoll sind
  • Jenkins, GitLab CI/CD, GitHub Actions und Bitbucket Pipelines im direkten Vergleich

Hands-on: CI-Systemwahl & Pipeline-Skizze

  • Fallbeispiel-Team mit Jenkins-Server unter dem Schreibtisch
  • Begründete Systemwahl anhand Wartungsaufwand, Rechteverwaltung, Security, Skalierung
  • Drei Pipeline-Stages grob skizzieren, kein YAML, Abgleich mit der Musterlösung

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur begründeten CI-System-Wahl in der Hands-on-Übung, Qualität der skizzierten Pipeline-Stages) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen das Fallbeispiel-Team und den Werkzeugvergleich auf eure tatsächliche CI-Landschaft an.

Academy Briefing anfragen