[{"data":1,"prerenderedAt":771},["ShallowReactive",2],{"/de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments":3,"navigation-de-de":44,"banner-de-de":447,"footer-de-de":457,"blog-post-authors-de-de-Olivier Dupré":662,"blog-related-posts-de-de-using-child-pipelines-to-continuously-deploy-to-five-environments":677,"assessment-promotions-de-de":721,"next-steps-de-de":761},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":29,"isFeatured":12,"meta":30,"navigation":31,"path":32,"publishedDate":20,"seo":33,"stem":37,"tagSlugs":38,"__hash__":43},"blogPosts/de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments",[7],"olivier-dupr",null,"engineering",{"slug":11,"featured":12,"template":13},"using-child-pipelines-to-continuously-deploy-to-five-environments",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22,"updatedDate":28},"Kontinuierliche Bereitstellung in fünf Umgebungen mithilfe von untergeordneten Pipelines","Erfahre, wie du die kontinuierliche Bereitstellung in verschiedenen Umgebungen – darunter temporäre, sofort einsatzbereite Sandboxes – mit einem minimalistischen GitLab-Workflow verwalten kannst.",[18],"Olivier Dupré","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","2024-09-26","Manchmal brauchen DevSecOps-Teams die Möglichkeit, die kontinuierliche Bereitstellung über mehrere Umgebungen übergreifend zu verwalten, ohne dabei ihre Workflows zu verändern. Die [DevSecOps-Plattform von GitLab](https://about.gitlab.com/de-de/) macht dies mit einem minimalistischen Ansatz möglich, unter anderem für temporäre, sofort einsatzbereite Sandboxes. In diesem Artikel erfährst du, wie du die kontinuierliche Bereitstellung der Infrastruktur mit Terraform in verschiedenen Umgebungen ausführen kannst.\n\n> **Nahezu 100 % Uptime: NVIDIA skaliert mit GitLab global – ohne Ausfallzeiten** Verteilte Teams bei NVIDIA profitieren mit GitLab Geo von schneller verfügbaren Repositories, häufigeren Upgrades ohne Ausfallzeiten und global-synchronen sowie -sicheren Projekten. Erfahre, wie GitLab Premium hilft, Stabilität, Transparenz und Effizienz zu verbessern. **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/nvidia/)**\n\nDiese Strategie kann einfach auf andere Projekte umgesetzt werden, egal, ob es sich um Infrastructure as Code (IaC), die auf einer anderen Technologie wie [Pulumi](https://www.pulumi.com/) oder [Ansible](https://www.ansible.com/) basiert, um Quellcode in beliebigen Sprachen oder ein Monorepo handelt, bei dem viele Sprachen gemischt verwendet werden.\n\nDie letzte Pipeline, die du am Ende dieses Tutorials hast, stellt Folgendes bereit:\n\n* Eine temporäre **Review-Umgebung** für jeden Feature-Branch.\n* Eine **Integrationsumgebung**, die einfach zu löschen und vom Haupt-Branch aus bereitzustellen ist.\n* Eine **QA-Umgebung**, die ebenfalls von dem Haupt-Branch bereitgestellt wird, um Qualitätssicherungsschritte durchzuführen.\n* Eine **Staging-Umgebung**, die für jedes Tag bereitgestellt wird. Dies ist die letzte Runde vor der Produktion.\n* Eine **Produktionsumgebung**, die direkt nach der Staging-Umgebung folgt. Diese wird zur Demonstration manuell ausgelöst, kann aber auch kontinuierlich bereitgestellt werden.\n\n>Hier findest du die Legende für die Flussdiagramme in diesem Artikel:\n> * Runde Boxen sind die GitLab-Branches.\n> * Eckige Boxen sind die Umgebungen.\n> * Der Text auf den Pfeilen sind die Aktionen, die von einem Feld zum nächsten fließen sollen.\n> * Eckige Quadrate sind Entscheidungsschritte.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\nBei jedem Schritt erfährst du das [Warum](#why) und das [Was](#what), bevor du zum [Wie](#how) übergehst. Dies wird dir helfen, dieses Tutorial vollständig zu verstehen und zu replizieren.\n\n## Warum\n\n* [Kontinuierliche Integration](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-integration-ci) ist fast ein De-facto-Standard. Die meisten Unternehmen haben CI-Pipelines implementiert oder sind bereit, ihre Arbeitsweise zu standardisieren.\n\n* [Kontinuierliche Bereitstellung](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-delivery-cd), wobei Artefakte in ein Repository oder eine Registry am Ende der CI-Pipeline gepusht werden, ist ebenfalls beliebt.\n\n* Kontinuierliche Bereitstellung, die weiter geht und diese Artefakte automatisch bereitstellt, ist allerdings weniger verbreitet. Wenn, dann wird sie vor allem im Bereich von Anwendungen implementiert. Wenn es um die kontinuierliche Bereitstellung von Infrastruktur geht, scheint das Bild weniger klar zu sein und es dreht sich vieles um das Management mehrerer Umgebungen. Im Gegensatz dazu scheint das Testen, Sichern und Überprüfen des Infrastruktur-Codes schwieriger zu sein. Dies ist eines der Felder, in denen DevOps noch nicht ausgereift ist. Ein anderer Anwendungsbereich ist, die Sicherheit im Vorfeld zu kontrollieren und Sicherheitsteams sowie – was noch wichtiger ist – Sicherheitsbedenken früher in den Lebenszyklus der Bereitstellung zu integrieren und so von DevOps auf ***DevSecOps*** upzugraden.\n\nAngesichts dessen wirst du in diesem Tutorial eine einfache und doch effiziente Möglichkeit erarbeiten, DevSecOps für deine Infrastruktur zu implementieren, indem du beispielsweise Ressourcen in fünf Umgebungen bereitstellst und dich schrittweise von der Entwicklung bis zur Produktion vorarbeitest.\n\n__Hinweis:__ Auch wenn ich einen FinOps-Ansatz und eine Reduktion der Umgebungen befürworte, gibt es manchmal gute Gründe, mehr als nur Entwicklung, Staging und Produktion aufrechtzuerhalten. Bitte passe die folgenden Beispiele an deine Bedürfnisse an.\n\n## Was\n\nDer Aufstieg der Cloud-Technologie hat die Nutzung von IaC vorangetrieben. Ansible und Terraform gehörten in diesem Bereich zu den Pionieren. OpenTofu, Pulumi, AWS CDK, Google Deploy Manager und viele andere folgten.\n\nIaC gilt als perfekte Lösung, um sich bei der Bereitstellung von Infrastruktur sicher zu fühlen. Du kannst sie testen, bereitstellen und immer wieder abspielen, bis du dein Ziel erreicht hast.\n\nLeider sehen wir oft, dass Unternehmen für jede ihrer Zielumgebungen mehrere Branches oder sogar Repositories unterhalten. Und hier beginnen die Probleme. Sie setzen einen Prozess nicht mehr durch. Sie stellen nicht mehr sicher, dass Änderungen in der Produktions-Codebase in früheren Umgebungen genauestens getestet wurden. Und sie beginnen, Drifts von einer Umgebung in die andere zu erleben.\n\nMir wurde klar, dass dieses Tutorial notwendig war, als auf einer Konferenz alle Teilnehmenden sagten, dass sie keinen Workflow haben, der durchsetzt, dass Infrastruktur genau getestet wird, bevor sie für die Produktion bereitgestellt wird. Und sie waren sich alle einig, dass sie manchmal den Code direkt in die Produktion patchen. Klar geht das schnell, aber ist es auch sicher? Wie meldet man an frühere Umgebungen zurück? Wie stellt man sicher, dass es keine Nebeneffekte gibt? Wie kontrolliert man, ob man das Unternehmen in Gefahr bringt, wenn neue Sicherheitslücken zu schnell in die Produktion gepusht werden?\n\nDie Frage, *warum* DevOps-Teams direkt in die Produktion implementieren, ist hier entscheidend. Liegt es daran, dass die Pipeline effizienter oder schneller sein könnte? Gibt es keine Automatisierung? Oder, noch schlimmer, gibt es *keine Möglichkeit, außerhalb der Produktion genau zu testen*?\n\nIm nächsten Abschnitt erfährst du, wie du Automatisierung für deine Infrastruktur implementieren und sicherstellen kannst, dass dein DevOps-Team effektiv testet, bevor etwas in eine Umgebung gepusht wird, die sich auf andere auswirkt. Du wirst sehen, wie dein Code gesichert und seine Bereitstellung durchgehend kontrolliert wird.\n\n## Wie\n\nWie bereits erwähnt, gibt es heutzutage viele Programmiersprachen für IaC, und wir können ganz einfach nicht *alle* in einem einzigen Artikel behandeln. Ich werde mich also auf einen grundlegenden Terraform-Code konzentrieren, der auf Version 1.4 läuft. Bitte fixiere dich nicht auf die Programmiersprache für IaC selbst, sondern auf den Prozess, den du für dein eigenes Ökosystem umsetzen kannst.\n\n### Der Terraform-Code\n\nBeginnen wir mit einem grundlegenden Terraform-Code.\n\nWir werden auf AWS bereitstellen, eine virtuelle private Cloud (VPC), die ein virtuelles Netzwerk ist. In dieser VPC werden wir ein öffentliches und ein privates Subnetz bereitstellen. Wie der Name schon sagt, handelt es sich um Subnetze der Haupt-VPC. Abschließend fügen wir eine EC2-Instanz (Elastic Cloud Compute; eine virtuelle Maschine) zum öffentlichen Subnetz hinzu.\n\nDies zeigt, wie vier Ressourcen bereitgestellt werden können, ohne zu komplex zu werden. Die Idee ist, sich auf die Pipeline zu konzentrieren, nicht auf den Code.\n\nHier ist das Ziel, das wir für dein Repository erreichen möchten.\n\n![Ziel für Repository](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\nGehen wir Schritt für Schritt vor.\n\nZuerst deklarieren wir alle Ressourcen in der Datei `terraform/main.tf`:\n\n```terraform\nprovider \"aws\" {\n  region = var.aws_default_region\n}\n\nresource \"aws_vpc\" \"main\" {\n  cidr_block = var.aws_vpc_cidr\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\nresource \"aws_subnet\" \"public_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_public_subnet_cidr\n\n  tags = {\n    Name = \"Public Subnet\"\n  }\n}\nresource \"aws_subnet\" \"private_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_private_subnet_cidr\n\n  tags = {\n    Name = \"Private Subnet\"\n  }\n}\n\nresource \"aws_instance\" \"sandbox\" {\n  ami           = var.aws_ami_id\n  instance_type = var.aws_instance_type\n\n  subnet_id = aws_subnet.public_subnet.id\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n```\n\nWie du sehen kannst, sind für diesen Code einige Variablen erforderlich, die wir also in der Datei `terraform/variables.tf` deklarieren:\n\n```terraform\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\n\nvariable \"aws_instance_type\" {\n  description = \"The instance type of the VM being deployed.\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\n\nvariable \"aws_public_subnet_cidr\" {\n  description = \"The CIDR of the public subnet.\"\n  type        = string\n  default     = \"10.0.1.0/24\"\n}\n\nvariable \"aws_private_subnet_cidr\" {\n  description = \"The CIDR of the private subnet.\"\n  type        = string\n  default     = \"10.0.2.0/24\"\n}\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n```\n\nAuf der IaC-Seite sind wir damit auch schon fast fertig. Was fehlt, ist eine Möglichkeit, die Terraform-Zustände zu teilen. Für diejenigen, die es nicht wissen: Terraform funktioniert schematisch wie folgt:\n\n* `plan` überprüft die Unterschiede zwischen dem aktuellen Status der Infrastruktur und dem, was im Code definiert ist. Dann gibt es die Unterschiede aus.\n* `apply` wendet die Unterschiede im `plan` an und aktualisiert den Status.\n\nIn der ersten Runde ist der Status leer, dann wird er mit den Details (ID usw.) der von Terraform angewendeten Ressourcen gefüllt.\n\nDas Problem ist: Wo wird dieser Zustand gespeichert? Wie können wir ihn teilen, damit mehrere Entwickler(innen) am Code zusammenarbeiten können?\n\nDie Lösung ist ziemlich einfach: Nutze GitLab, um den Status über ein [Terraform-HTTP-Backend](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html) zu speichern und freizugeben.\n\nDer erste Schritt bei der Verwendung dieses Backends besteht darin, die einfachste Datei, nämlich `terraform/backend.tf` zu erstellen. Der zweite Schritt erfolgt in der Pipeline.\n\n```terraform\nterraform {\n  backend \"http\" {\n  }\n}\n```\n\nEt voilà! Wir haben einen minimalen Terraform-Code, um diese vier Ressourcen bereitzustellen. Wir werden die Variablenwerte zur Laufzeit bereitstellen, also machen wir das später.\n\n### Der Workflow\n\nDer Workflow, den wir jetzt implementieren werden, sieht folgendermaßen aus:\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n1. Erstelle einen **Feature-Branch**. Dadurch werden alle Scanner kontinuierlich auf dem Code ausgeführt, um sicherzustellen, dass er immer konform und gesichert bleibt. Dieser Code wird kontinuierlich in der temporären Umgebung `review/feature_branch` mit dem Namen des aktuellen Branches bereitgestellt. Dies ist eine sichere Umgebung, in der die Entwickler(innen) und IT-Betriebsteams ihren Code ohne Auswirkungen auf andere testen können. Hier setzen wir auch den Prozess durch, z. B. indem Code Reviews durchgesetzt und Scanner ausgeführt werden, damit die Qualität und Sicherheit des Codes akzeptabel sind und deine Assets nicht gefährdet werden. Die von diesem Branch bereitgestellte Infrastruktur wird automatisch zerstört, wenn der Branch geschlossen wird. So behältst du dein Budget unter Kontrolle.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\u003C/pre>\n\n2. Nach der Genehmigung wird der Feature-Branch mit dem Main-Branch **zusammengeführt**. Dies ist ein [geschützter Branch](https://docs.gitlab.com/ee/user/project/protected_branches.html), in den niemand pushen kann. Dies ist obligatorisch, um sicherzustellen, dass jede Änderungsanfrage an die Produktion gründlich getestet wird. Dieser Branch wird auch kontinuierlich bereitgestellt. Das Ziel hier ist die Umgebung `integration`. Damit diese Umgebung etwas stabiler bleibt, wird das Löschen nicht automatisiert, sondern kann manuell ausgelöst werden.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\n3. Von dort aus ist eine manuelle Genehmigung erforderlich, um die nächste Bereitstellung auszulösen. Dadurch wird der Haupt-Branch in der Umgebung `qa` bereitgestellt. Hier habe ich eine Regel festgelegt, um das Löschen aus der Pipeline zu verhindern. Diese Umgebung sollte ziemlich stabil sein (schließlich ist es bereits die dritte Umgebung), und ich möchte das versehentliche Löschen verhindern. Du kannst die Regeln gerne an deine Prozesse anpassen.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\n4. Um fortzufahren, müssen wir den Code **taggen**. Wir setzen hier auf [geschützte Tags](https://docs.gitlab.com/ee/user/project/protected_tags.html), um sicherzustellen, dass nur eine bestimmte Gruppe von Benutzer(inne)n in diese letzten beiden Umgebungen bereitstellen darf. Dadurch wird sofort eine Bereitstellung in der Umgebung `staging` ausgelöst.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|tag| G(X.Y.Z)\n    F[qa] -->|validate| G\n\n    G -->|auto deploy| H[staging]\n\u003C/pre>\n\n\n5. Schließlich landen wir bei `production`. Wenn es um Infrastruktur geht, ist es oft schwierig, sie schrittweise bereitzustellen (10 %, 25 % usw.), sodass wir gleich die gesamte Infrastruktur bereitstellen werden. Dennoch steuern wir diese Bereitstellung, indem dieser letzte Schritt manuell ausgelöst wird. Und um maximale Kontrolle über diese hochkritische Umgebung zu erzwingen, werden wir sie als [geschützte Umgebung](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) kontrollieren.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n### Die Pipeline\n\nUm den oben genannten [Workflow](#the-workflow) zu implementieren, implementieren wir jetzt eine Pipeline mit zwei [Downstream-Pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\n#### Die Haupt-Pipeline\n\nBeginnen wir mit der Haupt-Pipeline. Dies ist diejenige, die automatisch bei jedem **Push zu einem Feature-Branch**, jedem Zusammenführen zum Standard-Branch** oder jedem **Tag** ausgelöst wird. *Die Pipeline*, die eine echte **kontinuierliche Bereitstellung** in den folgenden Umgebungen durchführt: `dev`, `integration` und `staging`. Und das wird in der Datei `.gitlab-ci.yml` im Stamm deines Projekts deklariert.\n\n![Repository-Ziel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n```yml\nStages:\n  - test\n  - environments\n\n.environment:\n  stage: environments\n  variables:\n    TF_ROOT: terraform\n    TF_CLI_ARGS_plan: \"-var-file=../vars/$variables_file.tfvars\"\n  trigger:\n    include: .gitlab-ci/.first-layer.gitlab-ci.yml\n    strategy: depend             # Wait for the triggered pipeline to successfully complete\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nreview:\n  extends: .environment\n  variables:\n    environment: review/$CI_COMMIT_REF_SLUG\n    TF_STATE_NAME: $CI_COMMIT_REF_SLUG\n    variables_file: review\n    TF_VAR_aws_resources_name: $CI_COMMIT_REF_SLUG  # Used in the tag Name of the resources deployed, to easily differenciate them\n  rules:\n    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n\nintegration:\n  extends: .environment\n  variables:\n    environment: integration\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nstaging:\n  extends: .environment\n  variables:\n    environment: staging\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_TAG\n\n#### TWEAK\n# This tweak is needed to display vulnerability results in the merge widgets.\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\n# Until then, the SAST IaC scanners will run in the downstream pipelines, but their results will not be available directly in the merge request widget, making it harder to track them.\n# Note: This workaround is perfectly safe and will not slow down your pipeline.\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n```\n\nDiese Pipeline läuft nur in zwei Phasen: `test` und `environments`. Erstere wird benötigt, damit der *TWEAK* Scanner ausführen kann. Zweitere löst eine untergeordnete Pipeline mit einem anderen Satz von Variablen für jeden oben definierten Fall aus (Push zum Branch, Zusammenführen zum Standard-Branch oder Tag).\n\nWir fügen hier eine Abhängigkeit mit dem Schlüsselwort [strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy) zu unserer untergeordneten Pipeline hinzu, sodass die Pipeline-Ansicht in GitLab erst aktualisiert wird, wenn die Bereitstellung abgeschlossen ist.\n\nWie du hier sehen kannst, definieren wir einen Basisjob, [hidden](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs), und erweitern ihn um bestimmte Variablen und Regeln, um nur eine Bereitstellung für jede Zielumgebung auszulösen.\n\nNeben den [vordefinierten Variablen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) verwenden wir zwei neue Einträge, die wir definieren müssen:\n1. [Die für jede Umgebung spezifischen Variablen](#the-variable-definitions): `../vars/$variables_file.tfvars`\n2. [Die untergeordnete Pipeline](#the-child-pipeline), definiert in `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\nBeginnen wir mit dem kleinsten Teil, den Variablendefinitionen.\n\n### Die Variablendefinitionen\n\nWir werden hier zwei Lösungen mischen, um Terraform Variablen zur Verfügung zu stellen:\n\n* Die erste nutzt [.tfvars-Dateien](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files) für alle nicht sensiblen Eingaben, die in GitLab gespeichert werden sollten.\n\n![Lösung 1 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n* Die zweite verwendet [Umgebungsvariablen](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables) mit dem Präfix `TF_VAR`. Diese zweite Möglichkeit, Variablen zu injizieren, die mit der GitLab-Fähigkeit verbunden sind, [Variablen zu maskieren](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable), [sie zu schützen](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) und [sie in Umgebungen zu übertragen](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable), ist eine leistungsstarke Lösung, um **Datenlecks sensibler Informationen zu verhindern**. (Wenn du das private CIDR deiner Produktion als sehr sensibel betrachtest, könntest du es so schützen, indem du sicherstellst, dass es nur für die Umgebung `production` verfügbar ist, für Pipelines, die gegen geschützte Branches und Tags ausgeführt werden, und dass sein Wert in den Protokollen des Jobs maskiert ist.)\n\n![Lösung 2 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\nDarüber hinaus sollte jede Variablendatei über eine [Datei `CODEOWNERS`](https://docs.gitlab.com/ee/user/project/codeowners/) gesteuert werden, um festzulegen, wer sie ändern darf.\n\n```text\n[Production owners] vars/production.tfvars @operations-group\n\n[Staging owners]\nvars/staging.tfvars @odupre @operations-group\n\n[CodeOwners owners]\nCODEOWNERS @odupre\n```\n\nDieser Artikel ist kein Terraform-Training, daher halten wir das kurz und zeigen hier einfach die Datei `vars/review.tfvars`. Die nachfolgenden Umgebungsdateien sind sich natürlich sehr ähnlich. Lege hier einfach die nicht-sensiblen Variablen und ihre Werte fest.\n\n```shell\naws_vpc_cidr = \"10.1.0.0/16\"\naws_public_subnet_cidr = \"10.1.1.0/24\"\naws_private_subnet_cidr = \"10.1.2.0/24\"\n```\n\n#### Die untergeordnete Pipeline\n\nHier wird die eigentliche Arbeit erledigt. Sie ist also etwas komplexer als die erste Pipeline. Es gibt aber auch hier keine Schwierigkeit, die wir nicht gemeinsam überwinden können!\n\nWie wir bei der Definition der [Haupt-Pipeline](#the-main-pipeline) gesehen haben, wird diese Downstream-Pipeline in der Datei `.gitlab-ci/.first-layer.gitlab-ci.yml` deklariert.\n\n![In Datei deklarierte Downstream-Pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\nZerlegen wir sie in kleine Stücke. Am Ende sehen wir dann das große Ganze.\n\n##### Terraform-Befehle ausführen und den Code sichern\n\nZuerst wollen wir eine Pipeline für Terraform ausführen. GitLab ist Open Source. Unsere Terraform-Vorlage ist also auch Open Source. Du kannst sie einfach einbeziehen. Dies erreichst du mit folgendem Code-Schnipsel:\n\n```yml\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\nDiese Vorlage führt für dich die Terraform-Prüfungen für die Formatierung durch und validiert deinen Code, bevor er geplant und angewendet wird. Es ermöglicht dir auch, das zu zerstören, was du bereitgestellt hast.\n\nDa GitLab eine vereinheitlichte DevSecOps-Plattform ist, fügen wir dieser Vorlage automatisch zwei Sicherheitsscanner hinzu, um potenzielle Bedrohungen in deinem Code zu finden und dich zu warnen, bevor du ihn in den nächsten Umgebungen bereitstellst.\n\nJetzt, da wir unseren Code überprüft, gesichert, erstellt und bereitgestellt haben, folgen ein paar Tricks.\n\n##### Zwischenspeicher zwischen Jobs teilen\n\nWir werden Job-Ergebnisse zwischenspeichern, um sie in folgenden Pipeline-Jobs wiederzuverwenden. Dies ist einfach, denn du musst nur den folgenden Code hinzufügen:\n\n```yml\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\n```\n\nHier definieren wir einen anderen Zwischenspeicher für jeden Commit und greifen bei Bedarf auf den Namen des Haupt-Branchs zurück.\n\nWenn wir uns die Vorlagen, die wir verwenden, genau ansehen, stellen wir fest, dass sie einige Regeln haben, die zu kontrollieren sind, wenn Jobs ausgeführt werden. Wir wollen alle Kontrollen (sowohl QA als auch Sicherheit) in allen Branchen ausführen. Wir werden diese Einstellungen also überschreiben.\n\n##### Kontrollen in allen Branches ausführen\n\nGitLab-Vorlagen sind eine leistungsstarke Funktion, bei der man auch nur einen Teil der Vorlage überschreiben kann. Hier wollen wir die Regeln einiger Jobs überschreiben, um immer Qualitäts- und Sicherheitskontrollen durchzuführen. Alles andere, was für diese Jobs definiert ist, bleibt wie in der Vorlage definiert.\n\n```yml\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - when: always\n\niac-sast:\n  rules:\n    - when: always\n```\n\nDa wir nun die Qualitäts- und Sicherheitskontrollen durchgesetzt haben, wollen wir unterscheiden, wie sich die Hauptumgebungen (Integration und Staging) im [Workflow](#the-workflow) und Review-Umgebungen verhalten. Beginnen wir mit der Definition des Verhaltens der Hauptumgebung. Wir werden dann diese Konfiguration für die Review-Umgebungen optimieren.\n\n##### CD für Integration und Staging\n\nWie zuvor definiert, möchten wir den Haupt-Branch und die Tags in diesen beiden Umgebungen bereitstellen. Wir fügen Regeln hinzu, um das sowohl bei den Jobs `build` als auch `deploy` zu kontrollieren. Dann wollen wir `destroy` nur für `integration` aktivieren, da wir definiert haben, dass `staging` zu kritisch ist, um mit einem einzigen Klick gelöscht zu werden. Das ist fehleranfällig, was wir nicht wollen.\n\nSchließlich verknüpfen wir den Job `deploy` mit dem Job `destroy`, damit wir die Umgebung direkt von der GitLab-GUI aus mit `stop` stoppen können.\n\nDie `GIT_STRATEGY` soll verhindern, dass der Code beim Zerstören aus dem Quell-Branch im Runner abgerufen wird. Dies würde fehlschlagen, wenn der Branch manuell gelöscht wurde. Daher verlassen wir uns auf den Zwischenspeicher, um alles zu erhalten, was wir zum Ausführen der Terraform-Anweisungen benötigen.\n\n```yml\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment:   environment:     name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n```\n\nWie gesagt müssen diese Matches in `integration` und `staging` bereitstellen. Uns fehlt jedoch immer noch eine temporäre Umgebung, in der die Entwickler(innen) ihren Code ohne Auswirkungen auf andere erleben und validieren können. Hier findet die Bereitstellung in der Umgebung `review` statt.\n\n##### CD für Review-Umgebungen\n\nDie Bereitstellung in der Review-Umgebung unterscheidet sich nicht allzu sehr von der Bereitstellung in `integration` und `staging`. Wir werden also erneut die Möglichkeit von GitLab nutzen, hier nur Teile der Jobdefinition zu überschreiben.\n\nZuerst legen wir Regeln fest, um diese Jobs nur in Feature-Branches auszuführen.\n\nDann verknüpfen wir den Job `deploy_review` mit `destroy_review`. Dies ermöglicht es uns, die Umgebung **manuell** von der GitLab-Bedienoberfläche aus zu stoppen und – was noch wichtiger ist – es wird **automatisch die Zerstörung der Umgebung ausgelöst**, wenn der Feature-Branch geschlossen wird. Dies ist eine gute FinOps-Praxis, um dir zu helfen, deine Betriebsausgaben zu kontrollieren.\n\nDa Terraform eine Plandatei benötigt, um eine Infrastruktur zu zerstören (genau wie es eine solche Datei benötigt, um eine Infrastruktur aufzubauen), fügen wir eine Abhängigkeit von `destroy_review` zu `build_review` hinzu, um Artefakte abzurufen.\n\nSchließlich sehen wir hier, dass der Name der Umgebung auf `$environment` festgelegt ist. Es wurde in der [Haupt-Pipeline](#the-main-pipeline) auf `review/$CI_COMMIT_REF_SLUG` gesetzt und mit der Anweisung `trigger:forward:yaml_variables:true` an diese untergeordnete Pipeline weitergeleitet.\n\n```yml\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n```\n\nZusammenfassend können wir also sagen, dass wir jetzt eine Pipeline haben, die Folgendes kann:\n\n* Temporäre Review-Umgebungen bereitstellen, die automatisch gelöscht werden, wenn der Feature-Branch geschlossen wird\n* Den **Standard-Branch** kontinuierlich auf `integration` bereitstellen\n* Die **Tags** kontinuierlich auf `staging` bereitstellen\n\nFügen wir nun eine zusätzliche Ebene hinzu, auf der wir diesmal mit einem manuellen Auslöser in den Umgebungen `qa` und `production` bereitstellen werden.\n\n##### Kontinuierliche Bereitstellung in QA und Produktion\n\nDa nicht jedes Unternehmen kontinuierlich in der Produktion bereitstellen möchte, fügen wir den nächsten beiden Bereitstellungen eine manuelle Validierung hinzu. Aus einer reinen **CD**-Perspektive würden wir diesen Auslöser nicht hinzufügen, aber betrachte dies als Gelegenheit, zu lernen, wie man Jobs von anderen Auslösern aus ausführt.\n\nBisher haben wir eine [untergeordnete Pipeline](#the-child-pipeline) aus der [Haupt-Pipeline](#the-main-pipeline) gestartet, um alle Bereitstellungen auszuführen.\n\nDa wir andere Bereitstellungen aus dem Standard-Branch und den Tags ausführen möchten, fügen wir eine weitere Ebene für diese zusätzlichen Schritte hinzu. Hier gibt es nichts Neues. Wir wiederholen einfach genau das, was wir nur für die [Haupt-Pipeline](#the-main-pipeline) gemacht haben. Auf diese Weise kannst du so viele Ebenen bearbeiten, wie du brauchst. Ich habe schon einmal bis zu neun Umgebungen gesehen.\n\nWir wollen hier nicht über die Vorteile diskutieren, die es mit sich bringt, weniger Umgebungen zu haben. Der hier verwendete Prozess macht es jedenfalls sehr einfach, die gleiche Pipeline von der Anfangsphase bis zur endgültigen Lieferung zu implementieren, während deine Pipeline-Definition einfach und in kleine, einfach zu wartende Teile aufgeteilt bleibt.\n\nUm hier Variablenkonflikte zu vermeiden, verwenden wir nur neue Variablennamen, um den Terraform-Status und die Eingabedatei zu identifizieren.\n\n```yml\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Andernfalls schlagen alle Pipelines fehl, wenn eine Pipeline-Zeitüberschreitung vor der Bereitstellung auf die 2. Ebene erreicht wurde.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\n**Ein wichtiger Trick ist hier die Strategie, die für die neue Downstream-Pipeline verwendet wird.** Wir belassen `trigger:strategy` auf ihrem Standardwert. Andernfalls würde die [Haupt-Pipeline](#the-main-pipeline) warten, bis deine [Pipeline der zweiten Ebene](#the-grand-child-pipeline) abgeschlossen ist. Bei einem manuellen Auslöser kann dies sehr lange dauern und das Lesen und Verstehen deines Pipeline-Dashboards erschweren.\n\nDu hast dich wahrscheinlich schon gefragt, was der Inhalt der Datei `.gitlab-ci/.second-layer.gitlab-ci.yml` ist, die wir hier anführen. Wir gehen im nächsten Abschnitt darauf ein.\n\n##### Vollständige Pipeline-Definition auf der ersten Ebene\n\nWenn du eine vollständige Ansicht dieser ersten Ebene möchtest (gespeichert in `.gitlab-ci/.first-layer.gitlab-ci.yml`), erweitere einfach den Abschnitt unten.\n\n```yml\nvariables:\n  TF_VAR_aws_ami_id: $AWS_AMI_ID\n  TF_VAR_aws_instance_type: $AWS_INSTANCE_TYPE\n  TF_VAR_aws_default_region: $AWS_DEFAULT_REGION\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n  - cleanup\n  - 2nd_layer       # Use to deploy a 2nd environment on both the main branch and on the tags\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\niac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\n###########################################################################################################\n## Integration env. and Staging. env\n##  * Auto-deploy to Integration on merge to main.\n##  * Auto-deploy to Staging on tag.\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n##  * Destroy of next env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment:     name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Dev env.\n##  * Temporary environment. Lives and dies with the Merge Request.\n##  * Auto-deploy on push to feature branch.\n##  * Auto-destroy on when Merge Request is closed.\n###########################################################################################################\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Second layer\n##  * Deploys from main branch to qa env.\n##  * Deploys from tag to production.\n###########################################################################################################\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n###########################################################################################################\n```\n\nIn dieser Phase stellen wir bereits sicher in drei Umgebungen bereit. Das ist meine persönliche Idealempfehlung. Wenn du jedoch mehr Umgebungen benötigst, füge diese deiner CD-Pipeline hinzu.\n\nDu hast sicherlich schon bemerkt, dass wir eine Downstream-Pipeline mit dem Stichwort `trigger:include` einbinden. Dazu gehört die Datei `.gitlab-ci/.second-layer.gitlab-ci.yml`. Da wir fast die gleiche Pipeline ausführen wollen, ist ihr Inhalt offensichtlich sehr ähnlich zu dem, den wir oben detailliert beschrieben haben. Der Hauptvorteil bei der Definition dieser [Pipeline der zweiten Ebene](#the-grand-child-pipeline) ist, dass sie allein besteht, was die Definition von Variablen und Regeln erleichtert.\n\n### Die Pipeline der zweiten Ebene\n\nDiese Pipeline der zweiten Ebene ist eine brandneue Pipeline. Daher muss es die Definition der ersten Ebene nachahmen mit:\n\n* [Aufnahme der Terraform-Vorlage](#run-terraform-commands-and-secure-the-code).\n* [Durchsetzung von Sicherheitskontrollen](#run-controls-on-all-branches). Bei der Terraform-Validierung handelt es sich um Duplikate der ersten Ebene. Sicherheitsscanner können jedoch Bedrohungen finden, die noch nicht vorhanden waren, als die Scanner zuvor ausgeführt wurden (z. B. wenn du einige Tage nach der Bereitstellung im Staging in der Produktion bereitstellst).\n* [Überschreiben von Build- und Bereitstellungs-Jobs, um spezifische Regeln festzulegen](#cd-to-review-environments). Beachte bitte, dass die Phase `destroy` nicht mehr automatisiert ist, um zu schnelle Löschvorgänge zu verhindern.\n\nWie oben erläutert, wurden `TF_STATE_NAME` und `TF_CLI_ARGS_plan` von der [Haupt-Pipeline](# the-main-pipeline) zur [untergeordneten Pipeline](#the-child-pipeline) bereitgestellt. Wir brauchten einen weiteren Variablennamen, um diese Werte von der [untergeordneten Pipeline](#the-child-pipeline) hierher, also an die [Pipeline der zweiten Ebene](#the-grand-child-pipeline), zu übergeben. Deshalb werden sie in der untergeordneten Pipeline mit dem Postfix `_2` versehen und der Wert wird während des `before_script` hier zurück in die entsprechende Variable kopiert.\n\nDa wir oben bereits jeden Schritt aufgeschlüsselt haben, können wir hier direkt auf die breite Ansicht der globalen Definition der zweiten Ebene zoomen (gespeichert in `.gitlab-ci/.second-layer.gitlab-ci.yml`).\n\n```yml\n# Use to deploy a second environment on both the default branch and the tags.\n\ninclude:\n  template: Terraform.gitlab-ci.yml\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n\nfmt:\n  rules:\n    - when: never\n\nvalidate:\n  rules:\n    - when: never\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: always\n\n###########################################################################################################\n## QA env. and Prod. env\n##  * Manually trigger build and auto-deploy in QA\n##  * Manually trigger both build and deploy in Production\n##  * Destroy of these env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:\n    name: $TF_STATE_NAME_2\n    action: prepare\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - when: manual\n\ndeploy: # terraform apply\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:     name: $TF_STATE_NAME_2\n    action: start\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG && $TF_AUTO_DEPLOY == \"true\"\n    - if: $CI_COMMIT_TAG\n      when: manual\n###########################################################################################################\n```\n\nEt voilà. **Wir sind bereit.** Du kannst die Art und Weise ändern, wie du deine Jobausführungen kontrollierst, indem du bspw. die Möglichkeit von GitLab nutzt, [einen Job zu verzögern](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay), bevor du ihn in der Produktion bereitstellst.\n\n## Probiere es selbst\n\nWir haben endlich unser Ziel erreicht. Wir sind jetzt in der Lage, **Bereitstellungen in fünf verschiedenen Umgebungen** zu kontrollieren, wobei nur die **Feature-Branches**, der **Haupt-Branch** und **Tags** verwendet werden.\n* Wir verwenden Open-Source-Vorlagen von GitLab intensiv wieder, um Effizienz und Sicherheit in unseren Pipelines zu gewährleisten.\n* Wir nutzen GitLab-Vorlagen, um nur die Blöcke zu überschreiben, die eine benutzerdefinierte Kontrolle benötigen.\n* Wir haben die Pipeline in kleine Teile aufgeteilt und kontrollieren die Downstream-Pipelines so, dass sie genau dem entsprechen, was wir brauchen.\n\nAb hier gehört die Bühne ganz dir. Du kannst beispielsweise die Haupt-Pipeline einfach aktualisieren, um Downstream-Pipelines für deinen Software-Quellcode mit dem Schlüsselwort [trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges) auszulösen. Und verwende je nach den aufgetretenen Änderungen eine andere [Vorlage](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/). Aber das ist eine andere Geschichte.",[23,24,25,26,27],"CI/CD","CI","CD","DevSecOps platform","tutorial","2024-11-05","yml",{},true,"/de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},"https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","https://about.gitlab.com","article","de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",[39,40,41,42,27],"cicd","ci","cd","devsecops-platform","AgKDw9w0cnW79ezbl_gvT4CjQbOZjVc_duJeenHr73s",{"data":45},{"logo":46,"freeTrial":51,"sales":56,"login":61,"items":66,"search":374,"minimal":409,"duo":427,"pricingDeployment":437},{"config":47},{"href":48,"dataGaName":49,"dataGaLocation":50},"/de-de/","gitlab logo","header",{"text":52,"config":53},"Kostenlose Testversion anfordern",{"href":54,"dataGaName":55,"dataGaLocation":50},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":57,"config":58},"Vertrieb kontaktieren",{"href":59,"dataGaName":60,"dataGaLocation":50},"/de-de/sales/","sales",{"text":62,"config":63},"Anmelden",{"href":64,"dataGaName":65,"dataGaLocation":50},"https://gitlab.com/users/sign_in/","sign in",[67,94,189,194,295,355],{"text":68,"config":69,"cards":71},"Plattform",{"dataNavLevelOne":70},"platform",[72,78,86],{"title":68,"description":73,"link":74},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":75,"config":76},"Erkunde unsere Plattform",{"href":77,"dataGaName":70,"dataGaLocation":50},"/de-de/platform/",{"title":79,"description":80,"link":81},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":82,"config":83},"Lerne GitLab Duo kennen",{"href":84,"dataGaName":85,"dataGaLocation":50},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":87,"description":88,"link":89},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":90,"config":91},"Mehr erfahren",{"href":92,"dataGaName":93,"dataGaLocation":50},"/de-de/why-gitlab/","why gitlab",{"text":95,"left":31,"config":96,"link":98,"lists":102,"footer":171},"Produkt",{"dataNavLevelOne":97},"solutions",{"text":99,"config":100},"Alle Lösungen anzeigen",{"href":101,"dataGaName":97,"dataGaLocation":50},"/de-de/solutions/",[103,127,149],{"title":104,"description":105,"link":106,"items":111},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":107},{"icon":108,"href":109,"dataGaName":110,"dataGaLocation":50},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[112,115,118,123],{"text":23,"config":113},{"href":114,"dataGaLocation":50,"dataGaName":23},"/de-de/solutions/continuous-integration/",{"text":79,"config":116},{"href":84,"dataGaLocation":50,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":50,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatisierte Softwarebereitstellung",{"href":109,"dataGaLocation":50,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":50,"icon":134},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Application Security Testing",{"href":132,"dataGaName":139,"dataGaLocation":50},"Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":50,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":50},"/de-de/solutions/software-compliance/",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":50},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":50,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":50,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":50,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":50,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":50,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":50,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":50,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":282},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":50},"/de-de/resources/",[203,236,254],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":50},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":50},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":50,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":50},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":50},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":50},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,249],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":50},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":248,"dataGaLocation":50},"/de-de/blog/","blog",{"text":250,"config":251},"Remote",{"href":252,"dataGaName":253,"dataGaLocation":50},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":255,"items":256},"Vernetzen",[257,262,267,272,277],{"text":258,"config":259},"GitLab-Services",{"href":260,"dataGaName":261,"dataGaLocation":50},"/de-de/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":50},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":50},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Veranstaltungen",{"href":275,"dataGaName":276,"dataGaLocation":50},"/events/","events",{"text":278,"config":279},"Partner",{"href":280,"dataGaName":281,"dataGaLocation":50},"/de-de/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":287,"config":288},"the source promo card",{"src":289},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":291,"config":292},"Lies die News",{"href":293,"dataGaName":294,"dataGaLocation":50},"/de-de/the-source/","the source",{"text":296,"config":297,"lists":299},"Unternehmen",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"Über",{"href":305,"dataGaName":306,"dataGaLocation":50},"/de-de/company/","about",{"text":308,"config":309,"footerGa":312},"Karriere",{"href":310,"dataGaName":311,"dataGaLocation":50},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":50},{"text":316,"config":317},"Geschäftsführung",{"href":318,"dataGaName":319,"dataGaLocation":50},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":50},"/company/team/","team",{"text":326,"config":327},"Handbuch",{"href":328,"dataGaName":329,"dataGaLocation":50},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor Relations",{"href":333,"dataGaName":334,"dataGaLocation":50},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":50},"/de-de/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":50},"/de-de/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":50},"/company/contact/#contact-forms","newsletter",{"text":351,"config":352},"Presse",{"href":353,"dataGaName":354,"dataGaLocation":50},"/press/","press",{"text":356,"config":357,"lists":358},"Kontakt",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":57,"config":362},{"href":59,"dataGaName":363,"dataGaLocation":50},"talk to sales",{"text":365,"config":366},"Support-Portal",{"href":367,"dataGaName":368,"dataGaLocation":50},"https://support.gitlab.com","support portal",{"text":370,"config":371},"Kundenportal",{"href":372,"dataGaName":373,"dataGaLocation":50},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Schließen",{"text":377,"link":378},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":379,"config":380},"gitlab.com",{"href":64,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Vorschläge",[386,388,393,395,400,405],{"text":79,"config":387},{"href":84,"dataGaName":79,"dataGaLocation":382},{"text":389,"config":390},"Code Suggestions (KI)",{"href":391,"dataGaName":392,"dataGaLocation":382},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":23,"config":394},{"href":114,"dataGaName":23,"dataGaLocation":382},{"text":396,"config":397},"GitLab auf AWS",{"href":398,"dataGaName":399,"dataGaLocation":382},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":401,"config":402},"GitLab auf Google Cloud",{"href":403,"dataGaName":404,"dataGaLocation":382},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":406,"config":407},"Warum GitLab?",{"href":92,"dataGaName":408,"dataGaLocation":382},"Why GitLab?",{"freeTrial":410,"mobileIcon":415,"desktopIcon":420,"secondaryButton":423},{"text":411,"config":412},"Kostenlos testen",{"href":413,"dataGaName":55,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLab-Symbol",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":204,"config":424},{"href":425,"dataGaName":426,"dataGaLocation":414},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":428,"mobileIcon":433,"desktopIcon":435},{"text":429,"config":430},"Erfahre mehr über GitLab Duo",{"href":431,"dataGaName":432,"dataGaLocation":414},"/de-de/gitlab-duo/","gitlab duo",{"altText":416,"config":434},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":436},{"src":422,"dataGaName":419,"dataGaLocation":414},{"freeTrial":438,"mobileIcon":443,"desktopIcon":445},{"text":439,"config":440},"Zurück zur Preisübersicht",{"href":192,"dataGaName":441,"dataGaLocation":414,"icon":442},"back to pricing","GoBack",{"altText":416,"config":444},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":446},{"src":422,"dataGaName":419,"dataGaLocation":414},{"title":448,"button":449,"config":454},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":450,"config":451},"GitLab Transcend jetzt ansehen",{"href":452,"dataGaName":453,"dataGaLocation":50},"/de-de/events/transcend/virtual/","transcend event",{"layout":455,"icon":456},"release","AiStar",{"data":458},{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":654},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":461,"config":462},"Quelltext der Seite anzeigen",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Diese Seite bearbeiten",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"Beteilige dich",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,560,587,621],{"title":68,"links":483,"subMenu":488},[484],{"text":485,"config":486},"DevSecOps-Plattform",{"href":77,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":190,"links":490},[491,495,500],{"text":492,"config":493},"Tarife anzeigen",{"href":192,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Vorteile von Premium",{"href":498,"dataGaName":499,"dataGaLocation":465},"/de-de/pricing/premium/","why premium",{"text":501,"config":502},"Vorteile von Ultimate",{"href":503,"dataGaName":504,"dataGaLocation":465},"/de-de/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Lösungen",[508,513,516,518,523,528,532,535,538,543,545,547,550,555],{"text":509,"config":510},"Digitale Transformation",{"href":511,"dataGaName":512,"dataGaLocation":465},"/de-de/topics/digital-transformation/","digital transformation",{"text":514,"config":515},"Sicherheit und Compliance",{"href":132,"dataGaName":139,"dataGaLocation":465},{"text":124,"config":517},{"href":109,"dataGaName":110,"dataGaLocation":465},{"text":519,"config":520},"Agile Entwicklung",{"href":521,"dataGaName":522,"dataGaLocation":465},"/de-de/solutions/agile-delivery/","agile delivery",{"text":524,"config":525},"Cloud-Transformation",{"href":526,"dataGaName":527,"dataGaLocation":465},"/de-de/topics/cloud-native/","cloud transformation",{"text":529,"config":530},"SCM",{"href":121,"dataGaName":531,"dataGaLocation":465},"source code management",{"text":23,"config":533},{"href":114,"dataGaName":534,"dataGaLocation":465},"continuous integration & delivery",{"text":162,"config":536},{"href":164,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/de-de/solutions/gitops/","gitops",{"text":175,"config":544},{"href":177,"dataGaName":178,"dataGaLocation":465},{"text":180,"config":546},{"href":182,"dataGaName":183,"dataGaLocation":465},{"text":548,"config":549},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"dataGaLocation":465},{"text":551,"config":552},"Bildungswesen",{"href":553,"dataGaName":554,"dataGaLocation":465},"/de-de/solutions/education/","education",{"text":556,"config":557},"Finanzdienstleistungen",{"href":558,"dataGaName":559,"dataGaLocation":465},"/de-de/solutions/finance/","financial services",{"title":195,"links":561},[562,564,566,568,571,573,575,577,579,581,583,585],{"text":207,"config":563},{"href":209,"dataGaName":210,"dataGaLocation":465},{"text":212,"config":565},{"href":214,"dataGaName":215,"dataGaLocation":465},{"text":217,"config":567},{"href":219,"dataGaName":220,"dataGaLocation":465},{"text":222,"config":569},{"href":224,"dataGaName":570,"dataGaLocation":465},"docs",{"text":245,"config":572},{"href":247,"dataGaName":248,"dataGaLocation":465},{"text":240,"config":574},{"href":242,"dataGaName":243,"dataGaLocation":465},{"text":250,"config":576},{"href":252,"dataGaName":253,"dataGaLocation":465},{"text":258,"config":578},{"href":260,"dataGaName":261,"dataGaLocation":465},{"text":263,"config":580},{"href":265,"dataGaName":266,"dataGaLocation":465},{"text":268,"config":582},{"href":270,"dataGaName":271,"dataGaLocation":465},{"text":273,"config":584},{"href":275,"dataGaName":276,"dataGaLocation":465},{"text":278,"config":586},{"href":280,"dataGaName":281,"dataGaLocation":465},{"title":296,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":303,"config":590},{"href":305,"dataGaName":298,"dataGaLocation":465},{"text":308,"config":592},{"href":310,"dataGaName":311,"dataGaLocation":465},{"text":316,"config":594},{"href":318,"dataGaName":319,"dataGaLocation":465},{"text":321,"config":596},{"href":323,"dataGaName":324,"dataGaLocation":465},{"text":326,"config":598},{"href":328,"dataGaName":329,"dataGaLocation":465},{"text":331,"config":600},{"href":333,"dataGaName":334,"dataGaLocation":465},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":465},"/sustainability/",{"text":606,"config":607},"Vielfalt, Inklusion und Zugehörigkeit",{"href":608,"dataGaName":609,"dataGaLocation":465},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":611},{"href":338,"dataGaName":339,"dataGaLocation":465},{"text":346,"config":613},{"href":348,"dataGaName":349,"dataGaLocation":465},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":465},{"text":617,"config":618},"Transparenzerklärung zu moderner Sklaverei",{"href":619,"dataGaName":620,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Nimm Kontakt auf",[624,627,632,634,639,644,649],{"text":625,"config":626},"Sprich mit einem Experten/einer Expertin",{"href":59,"dataGaName":60,"dataGaLocation":465},{"text":628,"config":629},"Support",{"href":630,"dataGaName":631,"dataGaLocation":465},"/support/","get help",{"text":370,"config":633},{"href":372,"dataGaName":373,"dataGaLocation":465},{"text":635,"config":636},"Status",{"href":637,"dataGaName":638,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":640,"config":641},"Nutzungsbedingungen",{"href":642,"dataGaName":643,"dataGaLocation":465},"/terms/","terms of use",{"text":645,"config":646},"Datenschutzerklärung",{"href":647,"dataGaName":648,"dataGaLocation":465},"/de-de/privacy/","privacy statement",{"text":650,"config":651},"Cookie-Einstellungen",{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":31},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,660],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":465},{"text":645,"config":659},{"href":647,"dataGaName":648,"dataGaLocation":465},{"text":650,"config":661},{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":31},[663],{"id":664,"title":665,"body":8,"config":666,"content":668,"description":8,"extension":29,"meta":672,"navigation":31,"path":673,"seo":674,"stem":675,"__hash__":676},"blogAuthors/en-us/blog/authors/olivier-dupr.yml","Olivier Dupr",{"template":667},"BlogAuthor",{"name":18,"config":669},{"headshot":670,"ctfId":671},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713474/cj6odchlpoqxbibenvye.png","4VIckvQsyfNxEtz4pM42aP",{},"/en-us/blog/authors/olivier-dupr",{},"en-us/blog/authors/olivier-dupr","KYUHajPcOeVlPPyPD8D4H56u7iQpJSPInWLi38Y1NA0",[678,692,706],{"content":679,"config":690},{"category":9,"tags":680,"body":682,"date":683,"heroImage":684,"authors":685,"title":688,"description":689},[27,681,23],"git","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/ee/user/permissions.html) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[686,687],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":31,"template":13,"slug":691},"migration-from-azure-devops-to-gitlab",{"content":693,"config":704},{"heroImage":694,"title":695,"description":696,"authors":697,"date":699,"category":9,"tags":700,"body":703},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","Wie wir die größte GitLab-Instanz 12-mal täglich bereitstellen","Systematische Deployment-Pipeline mit mehrstufigen Rollouts, Canary-Strategie (5% Traffic) und Datenbank-Migrationen für Millionen Entwickler(innen) weltweit.",[698],"John Skarbek","2025-12-01",[701,702],"product","inside GitLab","GitLab führt täglich bis zu 12 Code-Bereitstellungen auf der weltweit größten GitLab-Instanz – GitLab.com – ohne Ausfallzeiten durch. Diese Bereitstellungen nutzen GitLabs eigene CI/CD-Plattform und betreffen Millionen Entwickler(innen) weltweit. Die hohe Bereitstellungsfrequenz dient als primäres Qualitätstor und Belastungstest. Organisationen, die auf GitLab für ihre DevOps-Workflows setzen, nutzen eine auf der eigenen Infrastruktur im Enterprise-Maßstab bewährte Plattform.\n\nIn regulierten Branchen wie dem Finanzwesen und der Automobilproduktion sind Zero-Downtime-Bereitstellungen keine Option, sondern Voraussetzung. Die NIS2-Richtlinie fordert in Artikel 21 systematische Risikoanalyse und Business-Continuity-Management – genau das, was GitLab.coms progressive Rollout-Strategie in der Praxis demonstriert. Durch mehrstufige Validierung mit isoliertem Canary-Traffic (5% aller Anfragen) werden potenzielle Probleme erkannt, bevor Millionen Nutzer(innen) betroffen sind.\n\n## Die Herausforderung: Frequenz trifft Skalierung\n\n**Für GitLab:** Bereitstellungsfrequenz ist geschäftskritisch. Schnelle Deployment-Zyklen ermöglichen Reaktion auf Kundenfeedback innerhalb von Stunden, sofortige Security-Patches und Validierung neuer Features in Production vor Skalierung.\n\n**Für Kund(inn)en:** Jede Bereitstellung auf GitLab.com validiert die Deployment-Praktiken, die GitLab seinen Nutzer(inne)n empfiehlt. Features werden auf der weltweit größten GitLab-Instanz getestet, bevor sie Kundenumgebungen erreichen. Dies liefert:\n\n* Neueste Features sofort verfügbar (Stunden statt Wochen)\n* Bewährte Zuverlässigkeit im Maßstab\n* Zero-Downtime-Bereitstellungen garantieren durchgängigen Zugriff\n* Dokumentation basiert auf tatsächlichen Production-Praktiken\n\n## Code-to-Production-Architektur\n\nDie Deployment-Pipeline durchläuft strukturierte Phasen, wobei jede Phase als Checkpoint auf dem Weg zur Production-Bereitstellung fungiert:\n\n```mermaid\n    graph TD\n        A[Code Proposed] --> B[Merge Request Created]\n        B --> C[Pipeline Triggered]\n        C --> D[Build & Test]\n        D --> E{Spec/Integration/QA Tests Pass?}\n        E -->|No| F[Feedback Loop]\n        F --> B\n        E -->|Yes| G[Merge to default branch]\n        G -->|Periodically| H[Auto-Deploy Branch]\n\n        subgraph \"Deployment Pipeline\"\n            H --> I[Package Creation]\n            I --> K[Canary Environment]\n            K --> L[QA Validation]\n            L --> M[Main Environment]\n\n        end\n```\n\n## Progressive Rollout-Strategie\n\n### Build und Paket-Erstellung\n\nGitLab erstellt sowohl Omnibus-Pakete als auch Cloud Native GitLab (CNG) Images. Omnibus-Pakete werden auf der Gitaly-Flotte bereitgestellt (Git-Storage-Layer), während CNG-Images alle anderen Komponenten als containerisierte Workloads ausführen. Eine geplante Pipeline sucht regelmäßig nach dem jüngsten Commit mit erfolgreicher Pipeline und erstellt daraus einen Auto-Deploy-Branch.\n\n```mermaid\n    graph LR\n        A[Create branch] --> B[Build]\n        B --> C[Choose Built package]\n        C --> D[Start Deploy Pipeline]\n```\n\n### Canary-Strategie und mehrstufige Validierung\n\nGitLabs QA-Prozess arbeitet Hand in Hand mit der Canary-Strategie durch umgebungsbasierte Validierung. [Etwa 5% des gesamten Traffics durchlaufen die Canary-Stage](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage). Dieser Ansatz erhöht die Komplexität von Datenbankmigrationen, gewährleistet aber nahtlose Bereitstellung eines zuverlässigen Produkts.\n\n**Progressive Rollout-Phasen:**\n\n1. **Staging Canary:** Initiale Validierungsumgebung\n2. **Production Canary:** Limitierter Production-Traffic\n3. **Staging Main:** Vollständige Staging-Umgebung\n4. **Production Main:** Vollständiger Production-Rollout\n\n```mermaid\n    graph TD\n        C[Staging Canary Deploy]\n        C --> D[QA Smoke Main Stage Tests]\n        C --> E[QA Smoke Canary Stage Tests]\n        D --> F\n        E --> F{Tests Pass?}\n        F -->|Yes| G[Production Canary Deploy]\n        G --> S[QA Smoke Main Stage Tests]\n        G --> T[QA Smoke Canary Stage Tests]\n        F -->|No| H[Issue Creation]\n        H --> K[Fix & Backport]\n        K --> C\n\n        S --> M[Canary Traffic Monitoring]\n        T --> M[Canary Traffic Monitoring baking period]\n        M --> U[Production Safety Checks]\n        U --> N[Staging Main]\n        N --> V[Production Main]\n```\n\nQA-Validierung erfolgt an mehreren Checkpoints: nach jeder Canary-Bereitstellung und nach Post-Deploy-Migrationen. Weitere Details zur [GitLab-Teststrategie](https://handbook.gitlab.com/handbook/engineering/testing/) finden sich im Handbook.\n\n## Deployment-Pipeline-Stages\n\nGitLab.com repräsentiert reale Deployment-Komplexität im Maßstab. Als größte bekannte GitLab-Instanz nutzen Bereitstellungen denselben offiziellen GitLab Helm Chart und dasselbe Linux-Paket wie Kund(inn)en. Mehr zur [GitLab.com-Architektur](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture) im Handbook.\n\n**Dogfooding im Maßstab:** GitLab nutzt dieselben Verfahren, die für [Zero-Downtime-Upgrades](https://docs.gitlab.com/update/zero_downtime/) dokumentiert sind. Was bei GitLab nicht reibungslos funktioniert, wird Kund(inn)en nicht empfohlen.\n\nFolgende Stages laufen für alle Environment- und Stage-Upgrades:\n\n```mermaid\n    graph LR\n        a[prep] --> c[Regular Migrations - Canary stage only]\n        a --> f[Assets - Canary stage only]\n        c --> d[Gitaly]\n        d --> k8s\n\n        subgraph subGraph0[\"VM workloads\"]\n          d[\"Gitaly\"]\n        end\n\n        subgraph subGraph1[\"Kubernetes workloads\"]\n          k8s[\"k8s\"]\n        end\n\n        subgraph fleet[\"fleet\"]\n          subGraph0\n          subGraph1\n        end\n```\n\n**Stage-Details:**\n\n* **Prep:** Validiert Deployment-Bereitschaft und führt Pre-Deployment-Checks durch\n* **Migrations:** Führt reguläre Datenbankmigrationen aus (nur Canary-Stage)\n* **Assets:** Lädt statische Assets in GCS-Bucket hoch (nur Canary-Stage)\n* **Gitaly:** Aktualisiert Gitaly-VM-Storage-Layer via Omnibus-Paket\n* **Kubernetes:** Deployed containerisierte GitLab-Komponenten via Helm Chart\n\n### Multi-Version-Kompatibilität: Die versteckte Herausforderung\n\nWährend der Bereitstellung existiert eine Zeitspanne, in der das Datenbankschema dem Code voraus ist, den die Main-Stage kennt. Dies geschieht, weil die Canary-Stage bereits neuen Code deployed und reguläre Datenbankmigrationen ausführt, während die Main-Stage noch die vorherige Code-Version ausführt.\n\n**Beispiel:** Bei Hinzufügen eines neuen `merge_readiness`-Felds zu Merge Requests laufen manche Server mit Code, der dieses Feld erwartet, während andere nichts davon wissen. Schlechte Handhabung würde GitLab.com für Millionen Nutzer(innen) unterbrechen. Gute Handhabung bleibt unbemerkt.\n\nMit wenigen Ausnahmen läuft die Mehrheit der Services für eine gewisse Zeit in leicht neuerer Version in Canary. Diese Szenarien sind transiente Zustände, können aber mehrere Stunden oder Tage in Live-Production-Umgebung persistieren. Daher müssen sie mit derselben Sorgfalt wie permanente Zustände behandelt werden.\n\n## Datenbank-Operationen\n\nDatenbankmigrationen stellen eine besondere Herausforderung im Canary-Deployment-Modell dar. Schemaänderungen müssen neue Features unterstützen und gleichzeitig Rollback-Fähigkeit bewahren:\n\n* **Regular Migrations:** Laufen während Canary-Stage, rückwärtskompatibel, nur reversible Änderungen\n* **Post-Deploy-Migrations:** \"Point of no Return\"-Migrationen, die erst nach mehreren erfolgreichen Bereitstellungen laufen\n\n```mermaid\n    graph LR\n        A[Regular Migrations] --> B[Canary Stage Deploy]\n        B --> C[Main Stage Deploy]\n        C --> D[Post Deploy Migrations]\n```\n\nPost-Deploy-Migrationen enthalten oft Änderungen, die nicht einfach rückgängig gemacht werden können – Datentransformationen, Column-Drops oder strukturelle Änderungen, die ältere Code-Versionen unterbrechen würden. Durch Ausführung nach Erlangung von Vertrauen durch mehrere erfolgreiche Bereitstellungen wird sichergestellt:\n\n1. Neuer Code ist stabil, Rollback unwahrscheinlich\n2. Performance-Charakteristiken in Production verstanden\n3. Edge Cases erkannt und adressiert\n4. Blast Radius minimiert, falls etwas schiefgeht\n\nDieser Ansatz bietet optimale Balance: schnelle Feature-Bereitstellung durch Canary-Releases bei gleichzeitiger Rollback-Fähigkeit bis Vertrauen in Deployment-Stabilität besteht.\n\n**Expand-Migrate-Contract-Pattern:** Datenbank-, Frontend- und Anwendungskompatibilitäts-Änderungen folgen einem sorgfältig orchestrierten dreiphasigen Ansatz:\n\n1. **Expand:** Neue Strukturen hinzufügen, alte funktional belassen\n2. **Migrate:** Neuen Application-Code deployen, der neue Strukturen nutzt\n3. **Contract:** Alte Strukturen in Post-Deploy-Migrationen entfernen\n\n**Beispiel für `merge_readiness`-Column:**\n\n1. **Expand:** Neue Column mit Default-Value hinzufügen; bestehender Code ignoriert sie\n2. **Migrate:** Code deployen, der neue Column liest und schreibt, alten Ansatz weiter unterstützt\n3. **Contract:** Nach mehreren erfolgreichen Bereitstellungen alte Column in Post-Deploy-Migration entfernen\n\nAlle Datenbank-Operationen, Application-Code und Frontend-Code unterliegen Guidelines, dokumentiert in der [Multi-Version-Compatibility-Dokumentation](https://docs.gitlab.com/development/multi_version_compatibility/).\n\n## Ergebnisse und Auswirkungen\n\n**Für GitLab:**\n\n* Bis zu 12 Bereitstellungen täglich auf GitLab.com\n* Zero-Downtime-Bereitstellungen für Millionen Entwickler(innen)\n* Security-Patches erreichen Production innerhalb von Stunden\n* Neue Features in Production im Maßstab validiert vor General Availability\n\n**Für Kunden:**\n\n* Bewährte Deployment-Patterns für eigene Anwendungen\n* Features auf weltweit größter GitLab-Instanz getestet vor Erreichen der Kundenumgebung\n* Dokumentation reflektiert tatsächliche Production-Praktiken\n* Vertrauen, dass GitLabs empfohlene Upgrade-Prozeduren in jedem Maßstab funktionieren\n\n## Erkenntnisse für Engineering-Teams\n\nDie hier beschriebenen Muster – von Expand-Migrate-Contract für Datenbankmigrationen bis zur Multi-Version-Kompatibilität – sind auf kleinere Deployments übertragbar. Nicht jede Organisation benötigt 12 Bereitstellungen täglich, aber die systematische Herangehensweise an Rollback-Fähigkeit und Validierungspunkte gilt unabhängig von der Skalierung.\n\nGitLabs Deployment-Pipeline repräsentiert ein ausgereiftes System, das Deployment-Geschwindigkeit mit operationaler Zuverlässigkeit ausbalanciert. Das progressive Deployment-Modell, umfassende Testing-Integration und robuste Rollback-Fähigkeiten bieten Grundlage für zuverlässige Software-Auslieferung im Maßstab.\n\n**Zentrale Überlegungen für Engineering-Teams:**\n\n* **Automatisiertes Testing:** Umfassende Test-Coverage durch Deployment-Pipeline\n* **Progressive Rollouts:** Gestufte Bereitstellungen zur Risikominimierung und schnellen Wiederherstellung\n* **Monitoring-Integration:** Umfassende Observability über alle Deployment-Stages\n* **Incident Response:** Schnelle Erkennungs- und Lösungsfähigkeiten für Deployment-Probleme\n\nGitLabs Architektur demonstriert, wie moderne CI/CD-Systeme Komplexität großskaliger Bereitstellungen managen und gleichzeitig Geschwindigkeit für wettbewerbsfähige Software-Entwicklung bewahren.\n\n## Vollständige technische Dokumentation\n\nDieser Artikel beschreibt die Deployment-Patterns und systematische Herangehensweise für GitLab.com. Für vollständige Implementierungsdetails, spezifische Konfigurationsbeispiele und tiefergehende technische Architekturbeschreibungen siehe die [englische Originalversion](https://about.gitlab.com/blog/continuously-deploying-the-largest-gitlab-instance/).\n\nWeitere Dokumentation zu Auto-Deploy und Verfahren:\n\n* [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n* [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n* [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)\n\n## Weitere Ressourcen\n\n* [How we decreased GitLab repo backup times from 48 hours to 41 minutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n* [How we supercharged GitLab CI statuses with WebSockets](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n* [How we reduced MR review time with Value Stream Management](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)",{"featured":31,"template":13,"slug":705},"continuously-deploying-the-largest-gitlab-instance",{"content":707,"config":719},{"title":708,"description":709,"authors":710,"heroImage":712,"date":713,"category":9,"tags":714,"body":718},"MR-Review-Zeit mit Value Stream Management reduzieren","GitLab Engineering nutzt VSM zur Identifikation von Engpässen im MR-Review-Prozess. Systematische Analyse mit Custom Stages.",[711],"Haim Snir","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097876/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097875817.png","2025-10-30",[701,715,26,716,717],"features","workflow","solutions architecture","Das GitLab Engineering-Team nutzt die eigenen Produkte intern – eine Praxis, die im Englischen als \"Dogfooding\" bezeichnet wird. Diese Selbstnutzung hat zu Verbesserungen bei der Beschleunigung der Software-Delivery-Zyklen für Kunden geführt. Dieser Artikel beleuchtet einen spezifischen Anwendungsfall, bei dem [GitLab Value Stream Management (VSM)](https://about.gitlab.com/solutions/value-stream-management/) Verbesserungen für unser Engineering-Team ermöglicht hat. Es wird gezeigt, wie VSM dabei half, zwei zentrale Herausforderungen anzugehen: die Messung des Wegs von der Idee bis zur Fertigstellung eines Merge Requests und die Optimierung der Deployment-Workflows.\n\nValue Stream Management ist in der deutschen Industrie als Wertstromanalyse etabliert – insbesondere in der Fertigung und Automobilbranche wird diese Lean-Methode zur Identifikation von Verschwendung eingesetzt. GitLabs VSM-Funktionen übertragen diesen systematischen Ansatz auf Software-Entwicklungsprozesse und ermöglichen die Unterscheidung zwischen wertschöpfenden und nicht-wertschöpfenden Aktivitäten im Entwicklungsworkflow.\n\n## Die Herausforderung: Engpässe in MR-Reviews identifizieren\n\nTrotz gut definierter Workflows stellte ein Team fest, dass Merge Requests länger als erwartet brauchten, um geprüft und gemerged zu werden. Die Herausforderung bestand nicht nur in den Verzögerungen selbst, sondern darin zu verstehen, wo im Review-Prozess diese Verzögerungen auftraten und warum.\n\nDas Ziel des Teams war klar:\n\n- Identifizieren, wo Zeit vom initialen Konzept bis zum finalen Merge eines MR verbracht wurde\n- Spezifische Engpässe im Review-Prozess lokalisieren\n- Verstehen, wie MR-Größe, Komplexität oder Dokumentationsqualität die Review-Zeit beeinflussen\n\n## Der Ansatz: MR-Review-Zeit in GitLab Value Stream Analytics messen\n\nValue Stream Analytics (VSA) ermöglicht es Organisationen, ihren gesamten Workflow von der Idee bis zur Auslieferung abzubilden und dabei zwischen wertschöpfenden Aktivitäten (VA) und nicht-wertschöpfenden Aktivitäten (NVA) im Prozessfluss zu unterscheiden. Durch die Berechnung des Verhältnisses von wertschöpfender Zeit zur gesamten Lead Time kann das Team verschwenderische Aktivitäten identifizieren, die zu Verzögerungen bei MR-Reviews führen.\n\nUm die notwendigen Metriken zu erhalten, passte das Team GitLab VSA an, um bessere Sichtbarkeit in den MR-Review-Prozess zu erhalten.\n\n### 1. Custom Stage für MR-Review einrichten\n\nDas Team fügte eine [neue Custom Stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#value-stream-stage-events) in VSA mit dem Namen **Review Time to Merge** hinzu, um spezifisch die Zeit vom ersten Zuweisen eines Reviewers bis zum Merge des MR zu tracken.\n\n- Start-Event: MR first reviewer assigned\n- End-Event: MR merged\n\nDurch die Definition dieser Stage begann VSA, die Dauer des MR-Review-Prozesses zu messen und lieferte präzise Daten darüber, wo Zeit verbracht wurde.\n\n![Defining stage of VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097883929.png)\n\n### 2. Total Time Chart für Klarheit nutzen\n\nMit der Custom Stage eingerichtet, nutzte das Team das [**Total Time Chart** auf der VSA Overview-Seite](https://about.gitlab.com/blog/value-stream-total-time-chart/) (**Analyze > Value Stream**), um zu visualisieren, wie viel Zeit während der neuen MR-Review-Stage verbracht wurde. Durch den Vergleich der Werte, die durch jeden Bereich im Chart dargestellt wurden, konnte das Team schnell identifizieren, wie diese Stage zur gesamten Software-Delivery-Lifecycle-Zeit (SDLC) beitrug.\n\n![total time chart for VSA](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097884/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097883930.png)\n\n### 3. Für tiefere Erkenntnisse detailliert analysieren\n\nUm spezifische Verzögerungen zu untersuchen, nutzte das Team die **Stage Navigation Bar**, um tiefer in die MR-Review-Stage einzutauchen. Diese Ansicht ermöglichte:\n\n- MRs nach Review-Zeit sortieren: Die Stage-Tabelle zeigte alle zugehörigen MRs sortiert nach Review-Dauer, sodass langsame MRs leicht erkennbar waren\n- Individuelle MRs analysieren: Für jeden MR konnte das Team Faktoren wie Verzögerungen bei der Reviewer-Zuweisung, mehrere Feedback-Runden, Leerlaufzeit nach Approval und MR-Größe/Komplexität untersuchen\n\n## Das Ergebnis: Umsetzbare Erkenntnisse und Verbesserungen\n\nDurch die Anpassung von VSA zur Verfolgung der [MR-Review-Zeit](https://docs.gitlab.com/user/project/merge_requests/reviews/) deckte das Team mehrere zentrale Erkenntnisse auf:\n\n- **Verzögerungen bei Reviewer-Zuweisung:** Einige MRs erfuhren Verzögerungen, weil Reviewer spät zugewiesen wurden oder Reviewer zu viele MRs in ihrer Queue hatten\n- **Langsame Review-Start-Zeiten:** Selbst nach Zuweisung lagen bestimmte MRs untätig, bevor Reviews begannen – oft aufgrund von Kontextwechseln oder konkurrierenden Prioritäten\n- **Mehrere Feedback-Schleifen:** Größere MRs erforderten oft mehrere Feedback-Runden, was die Review-Zeit erheblich verlängerte\n- **Leerlaufzeit nach Approval:** Einige MRs wurden approved, aber nicht zeitnah gemerged – oft aufgrund von Deployment-Koordinationsproblemen\n\nFür den Engineering Manager im Team erwies sich VSA als wertvoll für die Verwaltung des Team-Workflows: \"Ich habe VSA genutzt, um zu begründen, wo wir Zeit bei der MR-Fertigstellung verbrachten. Wir haben VSA auf unsere Bedürfnisse angepasst, und es war sehr hilfreich für unsere Untersuchungen nach Verbesserungsmöglichkeiten.\"\n\nAus dieser Dogfooding-Erfahrung entwickeln wir nun eine wichtige Erweiterung zur Verbesserung der Sichtbarkeit in den Review-Prozess. Wir fügen ein neues Event zu VSA hinzu – [Merge request last approved at](https://gitlab.com/gitlab-org/gitlab/-/issues/503754) – das eine Stage erzeugt, die MR-Review-Schritte noch granularer aufschlüsselt.\n\n## Die Kraft datengestützter Entscheidungen\n\nDurch die Nutzung von GitLabs VSA haben wir nicht nur Engpässe identifiziert – wir erhielten umsetzbare Erkenntnisse, die zu Verbesserungen bei der MR-Review-Zeit und der allgemeinen Entwickler-Produktivität führten. Wir optimierten Merge-Request-Review-Zyklen und erhöhten den Entwickler-Durchsatz, was unser Commitment zu kontinuierlicher Verbesserung durch Messung bestätigt.\n\n> Möchtest du erfahren, wie VSA deinem Team helfen kann? [Starte eine kostenlose GitLab Ultimate-Testversion](https://about.gitlab.com/free-trial/), passe deine Value Streams an und sieh, wie du Verbesserungen im gesamten SDLC für deine Teams erreichen kannst. [Teile dann dein Feedback und deine Erfahrungen in diesem Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/520962).\n\n## Weiterführende Informationen\n\n- [Optimize value stream efficiency to do more with less, faster](https://about.gitlab.com/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/)\n- [New Scheduled Reports Generation tool simplifies value stream management](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Value stream analytics documentation](https://docs.gitlab.com/user/group/value_stream_analytics/)\n- [Value stream management: Total Time Chart simplifies top-down optimization flow](https://about.gitlab.com/blog/value-stream-total-time-chart/)\n",{"slug":720,"featured":12,"template":13},"how-we-reduced-mr-review-time-with-value-stream-management",{"promotions":722},[723,737,749],{"id":724,"categories":725,"header":727,"text":728,"button":729,"image":734},"ai-modernization",[726],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":730,"config":731},"Get your AI maturity score",{"href":732,"dataGaName":733,"dataGaLocation":248},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":738,"categories":739,"header":741,"text":728,"button":742,"image":746},"devops-modernization",[701,740],"devsecops","Are you just managing tools or shipping innovation?",{"text":743,"config":744},"Get your DevOps maturity score",{"href":745,"dataGaName":733,"dataGaLocation":248},"/assessments/devops-modernization-assessment/",{"config":747},{"src":748},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":750,"categories":751,"header":753,"text":728,"button":754,"image":758},"security-modernization",[752],"security","Are you trading speed for security?",{"text":755,"config":756},"Get your security maturity score",{"href":757,"dataGaName":733,"dataGaLocation":248},"/assessments/security-modernization-assessment/",{"config":759},{"src":760},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":762,"blurb":763,"button":764,"secondaryButton":769},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":765,"config":766},"Kostenlosen Test starten",{"href":767,"dataGaName":55,"dataGaLocation":768},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":57,"config":770},{"href":59,"dataGaName":60,"dataGaLocation":768},1772652050944]