27 Verwaltung von Umgebungen und Deployments in GitLab CI/CD

Das Konfigurieren und Verwalten von Umgebungen ist ein zentraler Bestandteil des CI/CD-Prozesses in GitLab. Umgebungen wie Entwicklung, Staging und Produktion ermöglichen es, Code schrittweise bereitzustellen und dabei sicherzustellen, dass er gründlich getestet und überprüft wird, bevor er für Endbenutzer bereitgestellt wird. In diesem Artikel werden die wichtigsten Konzepte und Best Practices zur Verwaltung von Umgebungen, dynamischen Umgebungen und Review Apps in GitLab CI/CD vorgestellt.

27.1 Was sind Umgebungen in GitLab CI/CD?

Umgebungen sind spezifische Konfigurationen, in denen Anwendungen bereitgestellt oder getestet werden. Die häufigsten Umgebungen sind:

• Entwicklungsumgebung (Development): Hier arbeiten die Entwickler aktiv an neuen Features, und es finden schnelle Tests statt.
• Staging-Umgebung (Staging): Diese Umgebung dient dazu, den Code unter produktionsähnlichen Bedingungen zu testen, bevor er live geschaltet wird.
• Produktionsumgebung (Production): Hier wird der Code schließlich für die Endbenutzer bereitgestellt.

GitLab CI/CD erlaubt es, Jobs für verschiedene Umgebungen zu definieren, um so sicherzustellen, dass der Code die notwendigen Phasen der Entwicklung und des Tests durchläuft, bevor er in die Produktion gelangt.

27.2 Definition von Umgebungen in .gitlab-ci.yml

Umgebungen werden in der .gitlab-ci.yml-Datei über den Abschnitt environment definiert. Ein Job, der in einer bestimmten Umgebung ausgeführt wird, kann folgendermaßen konfiguriert werden:

stages:
  - build
  - test
  - deploy

deploy-to-production:
  stage: deploy
  script:
    - echo "Deploying to production environment"
  environment:
    name: production
    url: https://production.example.com

In diesem Beispiel wird der Job deploy-to-production in der Produktionsumgebung ausgeführt. Die URL der Produktionsumgebung wird ebenfalls definiert und ist in der GitLab-Benutzeroberfläche sichtbar.

27.3 Automatisierte vs. manuelle Deployments

GitLab CI/CD unterstützt sowohl automatisierte als auch manuelle Deployments. Dies bietet Flexibilität bei der Verwaltung von Codebereitstellungen, je nachdem, ob ein sofortiges oder kontrolliertes Deployment gewünscht ist.

27.3.1 Automatisiertes Deployment

Automatisierte Deployments erfolgen, sobald bestimmte Bedingungen erfüllt sind, wie etwa das erfolgreiche Bestehen von Tests.

deploy-staging:
  stage: deploy
  script:
    - echo "Deploying to staging"
  environment:
    name: staging
  when: on_success

In diesem Beispiel wird das Deployment automatisch durchgeführt, wenn die vorhergehenden Phasen erfolgreich waren.

27.3.2 Manuelles Deployment

Manuelle Deployments erfordern eine explizite Freigabe durch einen Benutzer, was besonders in Produktionsumgebungen wichtig ist, um zusätzliche Kontrolle zu gewährleisten.

deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production"
  environment:
    name: production
  when: manual

Der Job deploy-production wird nur dann ausgeführt, wenn er manuell ausgelöst wird. Dies ist nützlich für Produktionsumgebungen, in denen eine zusätzliche Kontrolle über die Freigabe erforderlich ist.

27.4 Dynamische Umgebungen

Dynamische Umgebungen sind temporäre Umgebungen, die automatisch basierend auf bestimmten Ereignissen wie Branches oder Merge Requests erstellt werden. Diese Umgebungen sind besonders nützlich, um Änderungen in einer isolierten Umgebung zu testen, ohne die Hauptumgebung zu beeinflussen. Dynamische Umgebungen bieten Flexibilität und sind ideal für agile Entwicklungsteams, die schnellen Zugriff auf realistische Testumgebungen benötigen.

Merkmale dynamischer Umgebungen: - Isolierte Testumgebung: Jede dynamische Umgebung ist eine abgeschottete Umgebung, die nur für die spezifischen Änderungen gilt, die in einem Branch oder Merge Request enthalten sind. - Automatisierte Bereitstellung und Zerstörung: Dynamische Umgebungen werden automatisch erstellt, sobald ein Branch erstellt oder ein Merge Request geöffnet wird, und sie werden nach der Überprüfung oder dem Merge automatisch entfernt. - Automatische Benennung: GitLab kann den Namen dynamischer Umgebungen automatisch basierend auf Branch-Namen oder Merge Requests generieren.

Beispiel für die Definition einer dynamischen Umgebung:

deploy_review:
  stage: deploy
  script:
    - ./deploy.sh
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_COMMIT_REF_SLUG.example.com
  only:
    - branches
    - merge_requests

In diesem Beispiel wird für jede Änderung in einem Branch oder Merge Request eine eigene dynamische Umgebung erzeugt, die basierend auf dem Branch-Namen automatisch benannt wird. Die dynamische Umgebung ist über eine URL erreichbar, die ebenfalls dynamisch generiert wird.

27.5 Review Apps

Review Apps sind eine spezifische Implementierung dynamischer Umgebungen. Sie ermöglichen es, die Änderungen eines Merge Requests in einer separaten Umgebung zu überprüfen. Entwickler und Reviewer können den aktuellen Stand der Änderungen testen, bevor sie in die Haupt- oder Produktionsumgebung integriert werden.

Vorteile von Review Apps: - Schnelleres Feedback: Änderungen können in einer realistischen Umgebung überprüft werden, was schnelleres und präziseres Feedback ermöglicht. - Automatisierte Bereitstellung: Review Apps werden automatisch erstellt, sobald ein Merge Request erstellt oder aktualisiert wird. - Verbesserte Zusammenarbeit: Alle Beteiligten können die Review App nutzen, um Änderungen zu testen und Feedback zu geben, bevor sie final gemergt werden.

Beispiel für die Einrichtung einer Review App:

review_app:
  stage: deploy
  script:
    - ./deploy_review_app.sh
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://review.$CI_COMMIT_REF_SLUG.example.com
  only:
    - merge_requests

In diesem Beispiel wird eine Review App erstellt, die auf einem Merge Request basiert. Die App ist über eine dynamisch generierte URL erreichbar und bietet eine Umgebung, in der die Änderungen des Merge Requests überprüft werden können.

27.6 Regeln für umgebungsspezifische Jobs

Mit dem rules-Schlüsselwort kann gesteuert werden, wann bestimmte Jobs in bestimmten Umgebungen ausgeführt werden. Dies ermöglicht es, Jobs beispielsweise nur für spezielle Branches oder unter bestimmten Bedingungen laufen zu lassen.

deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production"
  environment:
    name: production
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

In diesem Beispiel wird der deploy-production Job nur ausgeführt, wenn der aktuelle Branch der main-Branch ist.

27.7 Verwendung von Umgebungs-URLs

GitLab bietet die Möglichkeit, URLs für jede Umgebung zu definieren, sodass Benutzer direkt auf die bereitgestellten Anwendungen zugreifen können. Dies ist besonders nützlich, um sicherzustellen, dass Reviewer oder Tester auf die entsprechenden Umgebungen zugreifen können.

staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com

27.8 Einsatzszenarien und Best Practices für dynamische Umgebungen und Review Apps

Dynamische Umgebungen und Review Apps eignen sich besonders für Teams, die schnellen Zugriff auf isolierte Testumgebungen benötigen, um Änderungen effizient zu testen. Best Practices umfassen:

• Automatisierung: Automatisiere die Erstellung und Zerstörung dynamischer Umgebungen, um sicherzustellen, dass Ressourcen effizient genutzt werden und veraltete Umgebungen regelmäßig entfernt werden.
• Eindeutige Namensgebung: Nutze branch- oder commit-basierte Namenskonventionen für Umgebungen und URLs, um Verwechslungen zu vermeiden und eine klare Zuordnung von Änderungen zu ermöglichen.
• Einsatz von Umgebungs-URLs: Stelle sicher, dass dynamische Umgebungen über leicht zugängliche URLs erreichbar sind, sodass Reviewer und Tester direkten Zugriff auf die Änderungen haben.

Weitere Informationen zur Verwaltung von Umgebungen in GitLab finden sich in der offiziellen Dokumentation.