Modernisierung von CI/CD: Migration von Bitbucket Pipelines zu GitHub Actions

In früheren Artikeln haben wir uns mit der Migration von Repositorys aus Bitbucket Cloud, die sichere Aktualisierung von Projektabhängigkeiten sowie die Modernisierung von CI/CD-Workflows durch die Umstellung von Jenkins- und Bash-basierten Pipelines auf GitHub Actions. Auf dieser Grundlage besteht der letzte Schritt darin, native Bitbucket-Pipelines zu migrieren und den Übergang zu einem vollständig einheitlichen CI/CD-System abzuschließen.

Dieser Artikel befasst sich mit der Umsetzung von YAML-basierten Bitbucket-Pipelines in GitHub-Actions-Workflows. Auf diese Weise folgen alle Pipelines projektübergreifend demselben Ausführungsmodell, was die Konsistenz, Wartbarkeit und langfristige Skalierbarkeit verbessert.

Die Struktur von Bitbucket Pipelines verstehen

Bitbucket Pipelines werden in einer Datei namens „bitbucket-pipelines.yml“ definiert, die sich im Stammverzeichnis des Repositorys befindet. Diese Datei steuert das Verhalten von CI/CD-Workflows, darunter:

• Wenn Pipelines ausgelöst werden
• Welche Schritte oder Aufgaben werden ausgeführt?
• Auftragsabwicklung und Abhängigkeiten
• Erstellung und Wiederverwendung von Artefakten zwischen einzelnen Schritten

Vor der Umstellung auf GitHub Actions ist es unerlässlich, das Verhalten der bestehenden Pipeline genau zu verstehen, damit sie präzise nachgebildet werden kann.

Beispiel für eine Bitbucket-Pipeline-Konfiguration

Nachfolgend finden Sie ein Beispiel für eine Bitbucket-Pipeline, die in diesem Projekt verwendet wird:

definitions:
  commonItems:
    &setupEnvironment |
      export COMMIT=$(echo $BITBUCKET_COMMIT | cut -b 1-8)
      git submodule update --init --recursive
      echo "#define REVISION_NUMBER 0x$COMMIT" > src/revision.h

  git:
    &gitSubmoduleUpdate |
      git submodule update --init

verify_release_version: &verify_release_version
  step:
    name: Verify release version
    script:
      - git submodule update --init
      - ./scripts/check_release_version.sh

cpplint: &cpplint
  step:
    name: Lint code
    image: my-registry/lint-image:latest
    script:
      - *gitSubmoduleUpdate
      - ./scripts/lint.sh

test: &test
  step:
    name: Run tests
    runs-on:
      - self.hosted
      - linux
    script:
      - *setupEnvironment
      - make test

build: &build
  step:
    name: Build project
    runs-on:
      - self.hosted
      - linux
    script:
      - *setupEnvironment
      - make build
    artifacts:
      - build/**

upload: &upload
  step:
    name: Upload build output
    script:
      - export DESTINATION=builds/$BITBUCKET_BRANCH
      - mkdir -p $DESTINATION
      - cp -r build/* $DESTINATION/
      - scp -r builds user@remote-server:/path/to/storage

Die wichtigsten Merkmale der Bitbucket-Pipeline

Dabei fallen einige wichtige Verhaltensweisen besonders auf:

• Wiederverwendbare Skripte mit YAML-Ankern (&setupEnvironment)
• Parallele Ausführung von Schritten zur Beschleunigung von Builds
• Artefakte, die in einem Schritt erstellt und später wiederverwendet werden
• Zweig-spezifische Pipelines, die steuern, welche Jobs auf „main“, „feature/*“ oder „release/*“ ausgeführt werden

Es ist entscheidend, diese Muster zu verstehen, bevor die Pipeline auf GitHub Actions portiert wird.

Zuordnung von Bitbucket Pipelines zu GitHub Actions

GitHub-Actions-Workflows werden unter .github/workflows/ definiert, in der Regel mit einem Workflow pro Datei. Jeder Workflow legt Folgendes fest:

• Auslöser, die steuern, wann der Workflow ausgeführt wird
• Aufträge als Arbeitseinheiten
• Abhängigkeiten zwischen Aufträgen mithilfe von „needs“
• Zwischen Jobs übergebene Artefakte

Beispiel für einen migrierten GitHub-Actions-Workflow

Nachfolgend finden Sie den migrierten Workflow, der das Verhalten der Bitbucket-Pipeline widerspiegelt:

name: CI Workflow

on:
  push:
    branches:
      - main
      - 'feature/*'
      - 'release/*'

env:
  BUCKET: example-bucket
  AWS_REGION: region-value

jobs:
  lint:
    name: Lint code
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - run: ./scripts/lint.sh

  test:
    name: Run tests
    runs-on: [ "self-hosted", "ap-southeast-2", "ubuntu", "x64" ]
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - run: ./scripts/setup_environment.sh
      - run: make test

  build:
    name: Build project
    runs-on: [ "self-hosted", "ap-southeast-2", "ubuntu", "x64" ]
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - run: ./scripts/setup_environment.sh
      - run: make build
      - uses: actions/upload-artifact@v4
        with:
          name: build-artifacts
          path: build/

  release:
    name: Release build
    runs-on: ubuntu-latest
    needs: [build]
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - uses: actions/download-artifact@v4
        with:
          name: build-artifacts
          path: build/
      - run: |
          mkdir -p deploy/${GITHUB_REF_NAME}
          tar -czf deploy/${GITHUB_REF_NAME}/artifacts.tar.gz -C build .
          echo "{\"artifact\":\"artifacts.tar.gz\",\"revision\":\"${GITHUB_SHA}\"}" > deploy/${GITHUB_REF_NAME}/release_info.json
      - name: Upload to S3
        run: |
          aws s3 sync deploy "s3://${BUCKET}/" \
            --region $AWS_REGION \
            --acl private

Wichtige Konzepte im migrierten Workflow

Workflow-Auslöser

Der Workflow wird automatisch bei Pushes in die Zweige „main“, „feature/*“ und „release/*“ ausgeführt und bildet damit die verzweigbasierten Pipelines von Bitbucket nach.

Jobs und parallele Ausführung

Aufgaben wie „lint“ und „test“ können parallel ausgeführt werden, während andere auf die Erfüllung von Abhängigkeiten warten.

Aufgabenabhängigkeiten

Das Schlüsselwort „needs“ stellt sicher, dass der Release-Job erst gestartet wird, nachdem der Build erfolgreich abgeschlossen wurde.

Umgang mit Artefakten

Artefakte werden im Build-Job hochgeladen und im Release-Job mithilfe der nativen Artefakt-Aktionen von GitHub heruntergeladen.

Umgebungsvariablen und S3-Uploads

Umgebungsvariablen legen die Werte für Bucket und Region fest, und Artefakte werden mithilfe von Standardbefehlen der AWS-CLI hochgeladen. Auf Wunsch kann für S3-Uploads auch eine eigene GitHub-Action verwendet werden.

Abschluss der CI/CD-Migration

Nachdem die nativen Bitbucket-Pipelines erfolgreich auf GitHub Actions migriert wurden, laufen nun alle CI/CD-Workflows auf einer einzigen, einheitlichen Automatisierungsplattform. Dies gewährleistet ein einheitliches Verhalten über alle Projekte hinweg, vereinfacht die Wartung und bietet eine sichere und skalierbare Grundlage für die weitere Entwicklung.

Dieser Migrationsprozess zeigt einen praktischen Weg auf, wie Repositorys verschoben, Abhängigkeiten gesichert und Pipelines modernisiert werden können – wobei die gesamte Automatisierung auf strukturierte und wartungsfreundliche Weise unter GitHub Actions zusammengefasst wird.

Weitere Blogbeiträge findest duhier.