Pipeline-Entscheidung

GitLab CI, GitHub Actions oder Azure DevOps: Welche Pipeline zu deinem Unternehmen passt

Liegt der Quellcode ohnehin auf GitHub, ist GitHub Actions die schnellste und meistens auch die richtige Antwort. GitLab CI zieht vorbei, sobald Selbstbetrieb, Datenhaltung in Deutschland oder ein prüffähiger Nachweis gefordert sind. Azure DevOps lohnt dort, wo Entra ID und Azure-Abonnements die Landschaft bereits bestimmen. Entschieden wird die Frage nicht am YAML, sondern an Identitäten, Artefaktlager und Nachweispflichten.

5 Kapitel mit allen Befehlen
Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Diese Entscheidung hält länger als jedes Werkzeug darin

Eine CI/CD-Plattform wird einmal ausgewählt und danach jahrelang benutzt. Sie trägt nicht nur die Pipelines, sondern auch die Zugangsdaten zur Cloud, die Artefaktregistrierung, die Freigabeprozesse und die Prüfspur für Auditoren. Wer nach zwei Jahren wechselt, schreibt nicht ein paar YAML-Dateien um, sondern baut Berechtigungen, Umgebungsfreigaben und Release-Historie neu auf. Deshalb lohnt es sich, vor der ersten Zeile Pipeline-Code drei Fragen zu klären: Wo liegen die Identitäten, wo darf ein Build laufen, und wer muss das später nachweisen können.

Laufzeitminuten wirken günstig, solange nur ein Team baut. Die Rechnung dreht sich schnell, wenn Container-Images ohne Zwischenspeicher gebaut werden, wenn jeder Merge Request eine Matrix über vier Betriebssysteme startet oder wenn überholte Läufe einfach weiterlaufen. GitHub rechnet Windows-Minuten doppelt und macOS-Minuten zehnfach, was einzelne Jobs zum größten Posten macht. Eigene Runner senken den Minutenpreis, verlagern die Kosten aber in Instanzen, Speicher und Wartung, die dann in der IT-Kostenstelle auftauchen statt auf der Plattformrechnung.

Der dritte Punkt ist die Lieferkette. Pipelines ziehen fremde Actions, Container-Images und Templates aus dem Netz und führen sie mit vollem Zugriff auf die hinterlegten Secrets aus. Der Angriff auf die weit verbreitete Action tj-actions/changed-files im März 2025, geführt als CVE-2025-30066, hat genau das ausgenutzt und Zugangsdaten in die Build-Logs geschrieben. Wer Fremdcode nicht auf einen Commit-Hash festnagelt und die erlaubten Quellen nicht einschränkt, hat eine offene Tür in jede Umgebung, in die deployt wird.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Sechs Kriterien, die die Plattform entscheiden

  1. 01 Identitäten: Entra ID, GitLab oder GitHub
  2. 02 Selbstbetrieb nötig für Behörde oder KRITIS
  3. 03 Laufzeitminuten gegen eigene Runner rechnen
  4. 04 Artefakte und Registry an einem Ort halten
  5. 05 Fremdcode einschränken und auf Commit festnageln
  6. 06 Jenkins-Bestand in Wellen einfrieren und ablösen
Was du mitnimmst

Die drei Plattformen, ehrlich einsortiert

Alle drei bauen, testen und rollen aus. Der Unterschied liegt im Betriebsmodell, in der Anbindung an eure Identitäten und darin, was ihr im Zweifel selbst in der Hand behalten müsst.

GitLab CI

Die Wahl, wenn Selbstbetrieb ein Muss ist. Quellcode, Registry, Pipelines, Umgebungen und Freigaben liegen in einem Produkt, das komplett im eigenen Rechenzentrum laufen kann. Für Behörden, KRITIS-Betreiber und Auftragsverarbeitung ist das oft der einzige Weg, der eine Prüfung übersteht. Der Preis dafür ist echter Betriebsaufwand für Anwendung, Datenbank und Runner-Flotte.

GitHub Actions

Der schnellste Start und das mit Abstand größte Ökosystem an fertigen Bausteinen. Wer sein Repository dort hat, bekommt Pipelines ohne zweites System. Für regulierte Häuser gibt es in GitHub Enterprise Cloud die Datenresidenz in der EU, und eigene Runner lassen sich im eigenen Netz betreiben. Dafür brauchst du eine Regel, welche fremden Actions überhaupt erlaubt sind.

Azure DevOps

Stark dort, wo Entra ID die Identitäten liefert und Azure-Abonnements die Ziele sind. Service Connections, Umgebungsfreigaben und Boards greifen sauber ineinander, und AZ-400 beschreibt genau diesen Weg. Bedenke, dass Microsoft neue Funktionen zuerst in GitHub baut und dass das kostenlose Kontingent für private Projekte beantragt werden muss.

Jenkins im Bestand

Jenkins verschwindet selten schlagartig, und das muss er auch nicht. Sinnvoll ist ein Stichtag, ab dem keine neuen Jobs mehr dort entstehen, dazu eine Liste der verbliebenen Jobs mit Eigentümer und Ablösetermin. Was bleibt, wird eingefroren: Plugins nur noch für Sicherheitskorrekturen, keine neuen Abhängigkeiten mehr.

Runner sind der eigentliche Kostenhebel

Ob gehostet oder selbst betrieben entscheidet über Laufzeit, Rechnung und Netzzugriff. Eigene Runner brauchen eine automatische Skalierung nach unten, sonst zahlst du nachts und am Wochenende für Leerlauf. Gehostete Runner sind bequem, kommen aber ohne Sonderaufwand nicht an interne Datenbanken und Artefaktspeicher heran.

Zugang zur Cloud ohne hinterlegte Schlüssel

Der häufigste Fund in Pipeline-Reviews ist ein langlebiger Cloud-Schlüssel in den CI-Variablen. Alle drei Plattformen können das seit Jahren besser: Der Job weist sich mit einem kurzlebigen Token aus und übernimmt damit eine Rolle in der Cloud. Wer das zur Bedingung macht, streicht eine ganze Klasse von Zugangsdaten aus dem Betrieb, unabhängig davon, welche Plattform am Ende gewinnt.

Tutorial

Von der Bestandsaufnahme bis zur abgeschalteten Jenkins-Instanz

Liegt der Quellcode ohnehin auf GitHub, ist GitHub Actions meistens die richtige Antwort, und erst Selbstbetrieb, Datenhaltung in Deutschland oder ein prüffähiger Nachweis drehen die Entscheidung Richtung GitLab. Um das zu belegen, misst du zuerst die eigene Landschaft, siehst denselben Build in allen drei Dialekten und löst die Anmeldung an der Cloud ohne gespeicherte Schlüssel, bevor Runner-Rechnung und Ablösung des Bestands folgen. Die Beispiele nutzen GitLab und GitHub, die Entsprechung in Azure DevOps steht jeweils daneben.

01

Schritt 1: Die eigene Landschaft messen statt schätzen

Vor dem Produktvergleich stehen drei Zahlen: wie viele Pipelines wirklich laufen, wie lange sie brauchen und woher sie ihre Zugangsdaten nehmen. Die holst du dir aus den Systemen, nicht aus dem Gedächtnis der Kollegen.

Bestand aus den drei Plattformen ziehen
# GitHub: Workflows und die Laeufe der letzten Wochen
gh api /repos/plattform/app/actions/workflows --jq '.workflows[].path'
gh api '/repos/plattform/app/actions/runs?per_page=100' \
  --jq '.workflow_runs[] | [.name, .conclusion, .run_started_at] | @tsv'

# GitLab: Pipelines je Projekt
glab api 'projects/plattform%2Fapp/pipelines?per_page=100' \
  | jq -r '.[] | [.id, .status, .created_at] | @tsv'

# Azure DevOps: Definitionen und letzte Laeufe
az pipelines list --organization https://dev.azure.com/beispiel \
  --project Plattform -o table
az pipelines runs list --organization https://dev.azure.com/beispiel \
  --project Plattform --top 50 -o table

Vier Werte zählen: Anzahl aktiver Pipelines, mittlere Laufzeit, Anteil der Läufe auf gehosteten Runnern und die Zahl der hinterlegten Secrets. Aus den ersten drei entsteht die Kostenrechnung, aus dem vierten der Migrationsaufwand.

Zähle die Secrets ernsthaft durch, auch die in alten Jobs. Jeder langlebige Cloud-Schlüssel, der in einer Pipeline liegt, wird beim Plattformwechsel entweder mitgeschleppt oder ersetzt, und Ersetzen ist die einzige gute Antwort. Notiere außerdem, welche Jobs interne Systeme erreichen müssen, also Datenbanken, Artefaktspeicher oder Lizenzserver. Diese Liste entscheidet später, ob gehostete Runner überhaupt in Frage kommen oder ob du eigene Maschinen im Netz betreiben musst.

Woran sich die Wahl tatsächlich entscheidet

KriteriumWoran du es misstWohin es die Wahl kippt
IdentitätenWoher kommen Anmeldung und Gruppen heuteEntra ID im Haus spricht für Azure DevOps oder GitHub Enterprise
BetriebsmodellDarf die Plattform außerhalb des Hauses laufenHarte Vorgaben führen zu GitLab im eigenen Rechenzentrum
ZielumgebungenWohin wird deployt, nach AWS, Azure oder beidesAlle drei können beides, entscheidend ist die Föderation der Rollen
NetzzugriffBrauchen Jobs interne DiensteInterner Zugriff erzwingt eigene Runner, egal bei welchem Anbieter
NachweispflichtWer verlangt Freigaben und PrüfspurUmgebungsfreigaben mit Vier-Augen-Prinzip gibt es überall, nur anders benannt
BestandWie viele Jenkins-Jobs mit welchen PluginsViele exotische Plugins verlängern die Ablösung um Monate
02

Schritt 2: Derselbe Build in drei Dialekten

Die Grundstruktur ist überall gleich: Auslöser, Job, Schritte, Artefakt. Unterschiede gibt es beim Zwischenspeicher, bei der Weitergabe von Artefakten zwischen Jobs und bei der Frage, wie privilegiert der Container ist, in dem gebaut wird.

.gitlab-ci.yml
stages: [build, test]

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build:
  stage: build
  image: quay.io/buildah/stable:v1.38
  script:
    - buildah login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
    - buildah bud --format docker -t "$IMAGE" .
    - buildah push "$IMAGE"
  interruptible: true

test:
  stage: test
  image: golang:1.24
  script:
    - go test ./...
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths: [.cache/go-build]

Buildah statt Docker-in-Docker spart den privilegierten Runner. interruptible: true beendet überholte Läufe, sobald ein neuer Push kommt, und ist einer der wirksamsten Kostenhebel überhaupt.

.github/workflows/build.yml
name: build
on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write

concurrency:
  group: build-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/plattform/app:${{ github.sha }}

Der Block permissions gehört in jeden Workflow. Ohne ihn bekommt das automatisch erzeugte Token die Standardrechte der Organisation, und die sind fast überall weiter gefasst als nötig.

azure-pipelines.yml
trigger:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-24.04

steps:
  - task: Docker@2
    inputs:
      containerRegistry: 'acr-plattform'
      repository: 'app'
      command: 'buildAndPush'
      Dockerfile: '**/Dockerfile'
      tags: '$(Build.SourceVersion)'

Die Service Connection acr-plattform hält die Anmeldung an der Registry. Lege sie mit Workload Identity Federation an, dann liegt kein dauerhafter Schlüssel im Projekt.

03

Schritt 3: In die Cloud ohne hinterlegte Zugangsdaten

Der häufigste Fund in Pipeline-Reviews ist ein langlebiger Cloud-Schlüssel in den CI-Variablen. Alle drei Plattformen können das seit Jahren besser: Der Job holt sich ein kurzlebiges Token, die Cloud tauscht es gegen eine Rolle.

AWS: Vertrauensstellung für GitHub Actions
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com

cat > trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:plattform/app:ref:refs/heads/main"
      }
    }
  }]
}
JSON

aws iam create-role --role-name ci-deploy \
  --assume-role-policy-document file://trust.json

Der Anbieter wird je Konto einmal angelegt, die Rolle je Anwendung. Entscheidend ist die Bedingung auf den sub-Claim, denn sie bindet die Rolle an genau ein Repository und genau einen Branch.

Azure: föderierte Anmeldeinformation für GitLab CI
az ad app create --display-name ci-gitlab-plattform
APP_ID=$(az ad app list --display-name ci-gitlab-plattform --query '[0].appId' -o tsv)

cat > fed.json <<'JSON'
{
  "name": "gitlab-main",
  "issuer": "https://gitlab.example.de",
  "subject": "project_path:plattform/app:ref_type:branch:ref:main",
  "audiences": ["https://gitlab.example.de"]
}
JSON

az ad app federated-credential create --id "$APP_ID" --parameters fed.json
az role assignment create --assignee "$APP_ID" --role Contributor \
  --scope /subscriptions/<abo-id>/resourceGroups/rg-plattform

Im Job forderst du das Token über id_tokens an und meldest dich damit an. Es lebt nur für die Dauer des Jobs, ein Diebstahl aus den Logs bringt danach nichts mehr.

Denselben Weg gehst du für die Registry und für alles, was danach kommt. Steht die Föderation, ist die nächste Frage, woher die Artefakte stammen, die deine Pipeline erzeugt, und wie das Zielsystem ihre Herkunft prüft. Wie du Stücklisten im Build erzeugst, Images signierst und die Prüfung im Cluster erzwingst, steht unter Software-Lieferkette absichern.

04

Schritt 4: Runner, Minuten und die Rechnung dahinter

Gehostete Runner kosten pro Minute, eigene Runner kosten pro Stunde Laufzeit plus Wartung. Welche Variante günstiger ist, hängt weniger am Listenpreis als daran, wie diszipliniert eure Pipelines laufen.

Eigener GitLab-Runner mit Docker-Executor
curl -L --output /usr/local/bin/gitlab-runner \
  https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
chmod +x /usr/local/bin/gitlab-runner

gitlab-runner register --non-interactive \
  --url https://gitlab.example.de/ \
  --token glrt-XXXXXXXXXXXXXXXXXXXX \
  --executor docker \
  --docker-image alpine:3.21 \
  --docker-volumes /cache

# /etc/gitlab-runner/config.toml
# concurrent = 4
# check_interval = 3

Seit GitLab 16 wird je Runner ein eigener Token erzeugt, erkennbar am Präfix glrt-. Gemeinsame Registrierungstoken für ganze Gruppen gibt es nicht mehr, und das ist gut so, denn sie waren der bequemste Weg, fremde Maschinen in fremde Projekte zu hängen.

Fünf Kostenfallen, die in keiner Kalkulation stehen

  • Windows- und macOS-Jobs getrennt kalkulierenGitHub rechnet Windows-Minuten doppelt und macOS-Minuten zehnfach. Ein einziger macOS-Job in jedem Merge Request wird schnell teurer als der komplette Linux-Anteil des Monats.
  • Eigene Runner nachts und am Wochenende herunterfahrenEine feste Flotte steht rund zwei Drittel der Woche ohne Arbeit da. Ohne Skalierung nach unten ist Selbstbetrieb regelmäßig teurer als gehostete Minuten, obwohl der Minutenpreis niedriger aussieht.
  • Aufbewahrungsfristen für Artefakte und Logs setzenOhne Ablauffrist wächst der Speicher jahrelang unbemerkt mit und schlägt bei GitLab direkt auf das Kontingent des Namespace durch. Betroffen sind meist Testberichte, die niemand je wieder öffnet.
  • Abhängigkeiten und Container-Layer zwischenspeichernEin Build, der bei jedem Lauf sämtliche Pakete neu lädt, kostet Minuten und Datenverkehr gleichzeitig. Ein wirksamer Zwischenspeicher halbiert die Laufzeit typischer Builds und damit die Rechnung.
  • Überholte Läufe automatisch abbrechenOhne interruptible bei GitLab oder concurrency bei GitHub laufen veraltete Pipelines zu Ende und verbrauchen Minuten für Ergebnisse, die niemand mehr ansieht.
05

Schritt 5: Jenkins ablösen, ohne den Releasebetrieb anzuhalten

Eine Umstellung im großen Schwung scheitert zuverlässig. Was funktioniert, ist Parallelbetrieb mit klarer Reihenfolge und einem Stichtag, ab dem in Jenkins nichts Neues mehr entsteht.

Die Reihenfolge, die sich bewährt hat

  • Alle Jobs inventarisieren, je Job Eigentümer, Auslöser und verwendete Plugins notieren
  • Stichtag setzen: ab diesem Datum entstehen neue Jobs ausschließlich auf der neuen Plattform
  • Einen unkritischen Dienst vollständig umziehen und daraus die Vorlage für alle weiteren bauen
  • Beide Pipelines eine Weile parallel laufen lassen und die erzeugten Artefakte vergleichen
  • Erst danach den Jenkins-Job auf reines Anstoßen reduzieren und zuletzt abschalten
Übergangsphase: Jenkins stößt die neue Pipeline an
# GitLab-Pipeline aus einem bestehenden Jenkins-Job ausloesen
curl --fail --request POST \
  --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  --form "ref=main" \
  "https://gitlab.example.de/api/v4/projects/1234/pipeline"

# GitHub Actions anstossen und auf das Ergebnis warten
gh workflow run build.yml --ref main --repo plattform/app
gh run watch --repo plattform/app

In dieser Phase bleibt Jenkins der Auslöser, die Arbeit passiert schon auf der Zielplattform. Der Vorteil: Zeitpläne, Freigaben und Benachrichtigungen ändern sich für die Fachbereiche erst im letzten Schritt.

Trenne beim Umbau sauber zwischen Bauen und Ausrollen. Eine Pipeline, die per kubectl apply direkt in die Produktion schreibt, braucht dauerhaft weitreichende Cluster-Rechte und hinterlässt keine nachvollziehbare Soll-Ist-Spur. Der übliche Weg ist stattdessen, dass die Pipeline nur einen Manifest-Stand schreibt und ein Agent im Cluster ihn abholt. Welche Werkzeuge dafür in Frage kommen und worin sie sich unterscheiden, klärt Argo CD oder Flux.

Gut zu wissen

Häufige Fragen zu CI/CD-Pipelines

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Welche der drei Plattformen ist am günstigsten?
Der Listenpreis entscheidet selten. Bei kleinen Teams mit wenigen Builds gewinnt fast immer die Plattform, die ihr ohnehin habt, weil kein zweites System betrieben werden muss. Ab etwa zwanzigtausend Laufzeitminuten im Monat lohnt die Rechnung mit eigenen Runnern, unabhängig vom Anbieter. Der größte Hebel liegt allerdings nicht beim Anbieter, sondern in der Pipeline selbst: Zwischenspeicher, das Abbrechen überholter Läufe und der Verzicht auf unnötige Matrixläufe sparen mehr als jeder Tarifwechsel.
Können wir GitHub Actions nutzen und trotzdem in der EU bleiben?
Ja, mit Einschränkungen. GitHub Enterprise Cloud bietet Datenresidenz in der Europäischen Union, sodass Repository-Inhalte und Metadaten dort gespeichert werden. Für die Ausführung selbst kannst du eigene Runner im eigenen Rechenzentrum oder in einer EU-Region betreiben, dann verlässt kein Build-Inhalt deine Umgebung. Prüfe trotzdem den Auftragsverarbeitungsvertrag und die Liste der Unterauftragsverarbeiter, denn Telemetrie und Support laufen davon unabhängig. Wo eine Aufsicht vollständigen Selbstbetrieb verlangt, bleibt GitLab im eigenen Haus die sauberere Antwort.
Wie gefährlich sind fremde Actions und Templates wirklich?
Gefährlich genug, dass es dafür einen dokumentierten Ernstfall gibt. Bei CVE-2025-30066 wurde eine sehr verbreitete Action manipuliert, sodass sie Zugangsdaten in die Build-Logs schrieb. Wirksam schützen drei Regeln: Fremdcode immer auf einen vollständigen Commit-Hash festnageln statt auf ein bewegliches Tag, die erlaubten Quellen auf Organisationsebene einschränken und Secrets nur an Umgebungen binden, die eine Freigabe verlangen. Damit reicht ein manipuliertes Paket allein nicht mehr aus, um in die Produktion zu gelangen.
Lohnt sich Azure DevOps für ein neues Projekt noch?
In Microsoft-Häusern ja, überall sonst eher nicht. Wo Entra ID die Identitäten liefert, Azure die Ziele stellt und Freigaben über Umgebungen laufen sollen, ist der Weg kurz und gut dokumentiert, und AZ-400 bildet ihn ab. Microsoft baut neue Funktionen allerdings zuerst in GitHub, und viele Häuser betreiben beides parallel, mit Boards auf der einen und Pipelines auf der anderen Seite. Für ein grünes Feld ohne Microsoft-Bindung ist GitHub Actions die geradlinigere Wahl.
Wie lange dauert die Ablösung einer gewachsenen Jenkins-Landschaft?
Rechne mit einem halben bis einem ganzen Tag je einfachem Job und mit deutlich mehr für alles, was an exotischen Plugins oder handgeschriebenen Groovy-Bibliotheken hängt. Bei hundert Jobs sind das mehrere Monate im Nebenher-Betrieb. Der Aufwand sinkt spürbar, wenn ihr die Build-Logik in Skripte auslagert, die auf jeder Plattform laufen, und das YAML nur noch als Aufrufhülle nutzt. Setze früh einen Stichtag für neue Jobs, sonst wächst der Bestand schneller, als ihr ihn abbaut.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Plattform gewählt, jetzt die Pipelines dahinter

Wenn die Entscheidung steht, bringen wir dein Team auf den Stand: Continuous Integration und Delivery mit GitLab für den Selbstbetrieb, AZ-400 für den Microsoft-Weg und DevOps Engineering on AWS für Pipelines Richtung AWS. Für den Bestand gibt es den Jenkins Grundkurs, für die Grundlagen den Git-Intensivkurs. Bist du noch unentschieden, sprich uns an, wir sehen uns eure Ausgangslage gemeinsam an.