Pipeline Automation for Branch-Based Environment Management

Einführung

In unserem vorherigen Artikel haben wir drei Modelle zur Verwaltung von Deployment-Umgebungen in der Versionskontrolle untersucht: Branches, Forked Repositories und Trunk-Based Development (TBD). In diesem Beitrag tauchen wir tief in die Pipeline-Automatisierung für das Branching-Modell ein – den traditionellsten Ansatz – unter Verwendung von Tools wie GitHub Actions und GitLab CI/CD.

Rückblick: Environment Branching

• Modell: Alle Umgebungen (develop, staging, main) sind Branches in einem einzigen Repository.

• Deployment-Ablauf:

  1. Entwickler erstellen Feature-Branches und öffnen Pull Requests auf develop.
  2. Nach Integration und Tests wird develop in staging gemergt.
  3. Wenn bereit, wird staging in main für die Produktion gemergt.

• Promotionen sind Merges, die leicht an einem Ort nachverfolgt werden können.

Prinzipien der Pipeline-Automatisierung (CI/CD)

• Deployments basierend auf Branch auslösen:

  • develop → Entwicklungs-/Testumgebung
  • staging → Staging
  • main → Produktion

• Konfiguration und Zugangsdaten isolieren mittels Umgebungsvariablen oder Secrets.

• Benachrichtigungen automatisieren bei PR-Erstellung/Merge, sowie bei Erfolg/Fehlschlag eines Deployments.

Beispiel: GitHub Actions Workflow

 1# .github/workflows/deploy.yml
 2name: Deploy on Branch
 3
 4on:
 5  push:
 6    branches:
 7        - develop
 8        - staging
 9        - main
10
11jobs:
12  deploy:
13    runs-on: ubuntu-latest
14    steps:
15      - uses: actions/checkout@v3
16      - name: Deploy
17        env:
18          ENV_NAME: ${{ github.ref_name }}
19        run: ./deploy.sh $ENV_NAME

• Das Deploy-Skript passt sich dem auslösenden Branch an.
• Verwenden Sie GitHub Secrets für umgebungsspezifische Schlüssel.

Beispiel: GitLab CI/CD

 1stages:
 2  - deploy
 3
 4deploy:
 5  stage: deploy
 6  variables:
 7    ENV_NAME: "${CI_COMMIT_REF_NAME}"
 8  script:
 9    - ./deploy.sh $ENV_NAME
10  only:
11    - develop
12    - staging
13    - main

Best Practices

• Machen Sie Umgebungs-Konfigurationen explizit – nutzen Sie Konfigurationsdateien, Secrets und Variablen, die eindeutig pro Branch sind.
• Verwenden Sie manuelle Genehmigungen in der Pipeline für Production-Merges/Deployments.
• Benachrichtigen Sie Teams über Deployments mit Integrationen in Slack, Teams, E-Mail usw.

Fazit

Branch-basiertes CI/CD ist für die meisten Teams weiterhin leicht zu visualisieren, zu automatisieren und zu skalieren – insbesondere für jene, die noch nicht bereit für TBD sind. Allerdings können Merge-Overhead und Konfigurationsabweichungen echte Herausforderungen darstellen. In einem kommenden Beitrag zeigen wir, wie Trunk-Based Development Deployments mit noch weniger Reibung automatisieren kann.