CircleCI: Grundlagen, Orbs und kontinuierliche Integration

CircleCI-Architektur: Orbs, Executors und Contexts

Die CircleCI-Architektur besteht aus drei Ebenen: Pipeline, Workflow und Job. Pipeline ist der Root-Prozess, der bei einem Commit ausgelöst wird. Eine Pipeline besteht aus Workflows — einem Graphen von Jobs, die sequenziell oder parallel ausgeführt werden können. Jeder Job wird auf einem Executor ausgeführt — einer Umgebung mit einem bestimmten Image. Ein Workflow kann Approval Gates enthalten — manuelle Bestätigung vor dem Deployment.

Orbs sind wiederverwendbare YAML-Konfigurationspakete, die über die CircleCI Orb Registry verteilt werden. Ein Orb kann Jobs, Commands, Executors und Beispiele enthalten. Beliebte Orbs: android, ios, flutter, firebase, slack. Zum Beispiel ersetzt das Hinzufügen des android-Orbs 50+ Zeilen Konfiguration durch eine einzige Zeile. Mit CircleCI CLI können Sie eigene Orbs erstellen, testen und veröffentlichen, um Pipelines in Ihrem Unternehmen zu standardisieren.

Executor-Typen

Contexts sind benannte Sets von Umgebungsvariablen, die auf Organisationsebene verfügbar sind. Zum Beispiel enthält der Kontext app-store-credentials die Apple-ID und das Passwort für die Veröffentlichung im App Store. Dies vereinfacht die Verwaltung von Secrets zwischen Projekten ohne Duplizierung.

CircleCI für Android- und iOS-Projekte einrichten

Für ein Android-Projekt verwendet CircleCI das Docker-Image cibuilds/android mit Android SDK. Ein typischer Workflow umfasst: Checkout, JDK-Installation, Gradle-Caching, Build und Testausführung. Für iOS ist ein macOS-Executor mit Xcode und Code-Signing-Einrichtung erforderlich. Beim ersten Verbinden erkennt CircleCI automatisch den Projekttyp und generiert eine Basiskonfiguration mit empfohlenen Einstellungen.

Für Flutter-Projekte stellt CircleCI den Orb circleci/flutter zur Verfügung, der Executors mit vorinstalliertem Flutter SDK für Linux und macOS enthält. Der Orb unterstützt Builds für beide Plattformen, Caching von pub-cache und Testausführung. Die Einrichtung beschränkt sich auf die Angabe der Flutter-Version und der Build-Befehle. Für benutzerdefinierte Flutter- oder Dart-Versionen kann ein Docker-Image mit dem erforderlichen SDK verwendet werden. Der Flutter-Orb unterstützt auch erweiterte Optionen — zum Beispiel Code-Analyse über dart analyze vor dem Build.

Android Orb — Schnellstart

Der Android-Orb von CircleCI bietet vorgefertigte Jobs: build-and-test, deploy-to-play-store. Der Orb konfiguriert automatisch die Umgebung, das Caching und die Signatur. Nach dem Hinzufügen des Orbs müssen Sie nur noch die SDK-Version und die Build-Befehle angeben.

iOS-Build mit macOS-Executor

Für iOS-Builds wird der Executor auf macos mit einer Xcode-Version gesetzt. CircleCI stellt Images mit Xcode 14, 15 und 16 bereit. Nach dem Checkout wird der Code über xcodebuild kompiliert und die Tests werden auf dem Simulator ausgeführt. Das Code-Signing wird über fastlane match oder manuelle Zertifikatsinstallation konfiguriert.

Caching und parallele Ausführung

Caching ist ein Schlüsselelement der Leistung in CircleCI. Der Cache-Mechanismus speichert Verzeichnisse zwischen Workflow-Läufen mit einem Schlüssel. Für Gradle wird ~/.gradle gecacht; für CocoaPods — Pods/; für npm/SPM — node_modules/.build. Wenn sich die Lock-Datei ändert, wird der Cache automatisch aktualisiert. CircleCI unterstützt separate Richtlinien: save_cache kann verzögert werden (when: always), während restore_cache obligatorisch ist.

Parallelität in Kombination mit der Resource Class ermöglicht eine Feinabstimmung der Build-Leistung. Resource Class bestimmt die CPU und RAM für einen Container: small (1 CPU, 2 GB), medium (2 CPU, 4 GB), medium+ (3 CPU, 5 GB) und large (4 CPU, 8 GB). Für iOS-Builds mit Xcode wird empfohlen, einen macOS-Executor mit medium oder größerer Resource Class zu verwenden — die Kompilierung von Swift-Code erfordert erhebliche Ressourcen.

Parallelität verteilt Tests auf mehrere Container und verkürzt die Laufzeit. Zum Beispiel: parallelism: 4 führt Tests in 4 parallelen Containern aus. CircleCI verteilt Testdateien automatisch auf die Container. Der Befehl circleci tests glob sammelt die Testliste, und circleci tests split verteilt sie gleichmäßig.

Beispiel für Gradle-Caching

- restore_cache:
    keys:
      - v1-gradle-{{ checksum "build.gradle" }}
      - v1-gradle-

- run: ./gradlew assembleDebug

- save_cache:
    key: v1-gradle-{{ checksum "build.gradle" }}
    paths:
      - ~/.gradle/caches
      - ~/.gradle/wrapper

Beispielkonfiguration .circleci/config.yml

Betrachten wir eine vollständige CircleCI-Konfiguration für ein Android-Projekt mit zwei Jobs: build und test. Die Konfiguration umfasst einen Docker-Executor mit Android SDK, Gradle-Caching und parallele Testausführung. Artefakte werden zum Herunterladen gespeichert. Der Workflow build-and-test führt beide Jobs bei jedem Push in den Hauptzweig aus.

version: 2.1

orbs:
  android: circleci/android@2.5.0

jobs:
  build:
    executor: android/default
    steps:
      - checkout
      - android/restore-gradle-cache
      - run: ./gradlew assembleRelease
      - android/save-gradle-cache
      - store_artifacts:
          path: app/build/outputs/apk/release
      - store_test_results:
          path: app/build/reports/tests

  test:
    executor: android/default
    parallelism: 4
    steps:
      - checkout
      - android/restore-gradle-cache
      - run:
          command: |
            cd app
            ./gradlew test

workflows:
  version: 2
  build-and-test:
    jobs:
      - build
      - test

Orbs: vorgefertigte CI/CD-Lösungen

Bei der Wahl zwischen CircleCI und Alternativen — wenn Ihr Team GitHub verwendet, ist GitHub Actions möglicherweise die einfachere Wahl. CircleCI ist für Teams zu bevorzugen, die flexible parallele Testausführung, benutzerdefinierte Executor-Umgebungskonfiguration und detaillierte Build-Statistiken benötigen. CircleCI Insights bietet ein Dashboard mit Pipeline-Leistungsmetriken: durchschnittliche Build-Zeit, Trends und Engpässe. Insights hilft, langlaufende Jobs zu identifizieren und zu optimieren. Die CircleCI-API ermöglicht die programmgesteuerte Verwaltung von Pipelines, das Auslösen von Builds und das Abrufen von Metriken.

Für die sichere Verwaltung von Secrets unterstützt CircleCI Contexts — benannte Sets von Umgebungsvariablen auf Organisationsebene. Contexts sind durch rollenbasierten Zugriff geschützt: Nur bestimmte Teams können einen bestimmten Kontext verwenden. Zum Beispiel enthält der Kontext production-deploy App Store Connect-Schlüssel und ist nur für Lead-Entwickler verfügbar. In Kombination mit Approval Gates entsteht so ein umfassendes CI/CD-Sicherheitssystem.

Die CircleCI Orb Registry enthält Hunderte von vorgefertigten Paketen für verschiedene CI/CD-Aufgaben. Für die mobile Entwicklung gehören zu den wichtigsten Orbs: circleci/android, circleci/ios, circleci/flutter, laurencerussell/firebase-app-distribution. Jeder Orb ist versioniert und dokumentiert. Orbs können öffentlich (für alle verfügbar) oder privat (nur für Ihre Organisation) sein.

Die Verwendung von Orbs reduziert die Konfiguration um das 5- bis 10-fache. Zum Beispiel stellt der Orb circleci/android den Executor android/default mit vorinstalliertem SDK und den Befehlen restore-gradle-cache, save-gradle-cache bereit. Der Orb circleci/ios enthält einen Executor mit Xcode und Befehle für Code-Signing über fastlane. Orbs lassen sich einfach kombinieren: Fügen Sie einen android-Orb für den Build und einen slack-Orb für Benachrichtigungen hinzu.

CircleCI bietet auch integrierte Testbericht-Unterstützung. Store_test_results analysiert und visualisiert automatisch Testergebnisse aus JUnit, XCTest und anderen Formaten. Für mobile Projekte bedeutet dies eine zentrale Ansicht fehlgeschlagener Tests, Laufzeittrends und Build-Stabilitätsverlauf, was die Code-Qualitätswartung vereinfacht.

Beispiel mit iOS-Orb

orbs:
  ios: circleci/ios@2.0.0

jobs:
  build-and-test:
    executor: ios/default
    steps:
      - checkout
      - ios/install-dependencies
      - ios/build-and-test

Veröffentlichung eines benutzerdefinierten Orbs ist über CircleCI CLI möglich. Die Befehle circleci orb create und circleci orb publish laden den Orb in die Registry hoch. Dies ist nützlich zur Standardisierung von CI/CD innerhalb einer Organisation — einmal erstellen, in allen Projekten verwenden.