← Alle Insights
8 Min. Lesezeit · Workflow · September 2029

CI/CD für Trading-Strategien: Continuous Integration meets Trading.

Software-Teams haben in den letzten 15 Jahren gelernt, dass Code, der nicht automatisch getestet und deployed wird, in Produktion zu Risiken führt. Trading-Teams entdecken das gerade erst — und zahlen jeden Monat dafür, dass sie es noch nicht tun. CI/CD macht in Trading-Setups oft den Unterschied zwischen „ich glaube, die Strategie läuft" und „ich weiß, dass die Strategie läuft".

Was CI/CD im Trading-Kontext heißt.

Die Akronyme zuerst:

Vollautomatisches Deployment in das Live-Trading-System ist im Retail- und Mandanten-Kontext nicht sinnvoll. Eine Strategie, die unbeobachtet vom Test- in den Live-Account wandert, ist ein Unfallrisiko. CD endet für mich am Paper-Trading-System.

Was getestet wird — drei Test-Kategorien.

Trading-Code zerfällt in Tests, die unterschiedliche Zwecke erfüllen:

Die dritte Kategorie ist die wichtigste — und die seltenste. Sie ist das Sicherheitsnetz gegen die Klasse von Bugs, bei denen die Strategie noch „läuft", aber andere Trades macht als gestern.

GitHub Actions: ein realistisches Workflow-File.

Wie das in der Praxis aussieht — eine kompakte .github/workflows/ci.yml für eine Python-Strategie: 

name: ci

on:
  push:
    branches: [main, dev]
  pull_request:
    branches: [main, dev]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip
      - name: Install
        run: pip install -e ".[dev]"
      - name: Lint
        run: ruff check .
      - name: Unit-Tests
        run: pytest tests/unit -q --cov=src --cov-report=xml
      - name: Integration-Tests (Sandbox)
        env:
          BROKER_SANDBOX_KEY: ${{ secrets.BROKER_SANDBOX_KEY }}
        run: pytest tests/integration -q
      - name: Backtest-Regression
        run: |
          python -m strategy.backtest \
            --data data/regression_2020_2024.parquet \
            --check-against baselines/regression.json

Der letzte Schritt ist der entscheidende Trading-spezifische: ein definierter Datensatz, ein definiertes Strategie-Setup, ein definierter Erwartungswert. Weicht der Backtest mehr als z. B. 0,1 % von der Baseline ab, schlägt der Job fehl.

Tägliche Backtest-Re-Runs als Health-Check.

Eine zweite, oft unterschätzte Anwendung: ein nightly job, der jeden Morgen einen kompletten Backtest mit aktuellen Marktdaten fährt und das Ergebnis ins Monitoring kippt. So sehen Sie Daten-Probleme oder Datenfeed-Bugs, bevor sie live Geld kosten: 

name: nightly-backtest

on:
  schedule:
    - cron: "0 5 * * 1-5"   # Mo-Fr 05:00 UTC
  workflow_dispatch:

jobs:
  backtest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12", cache: pip }
      - run: pip install -e ".[dev]"
      - name: Pull data
        env:
          DATA_API_KEY: ${{ secrets.DATA_API_KEY }}
        run: python -m data.refresh --days 1
      - name: Run rolling backtest
        run: python -m strategy.backtest --window 5y --report report.json
      - name: Push metrics
        env:
          PROM_PUSH_URL: ${{ secrets.PROM_PUSH_URL }}
        run: python -m monitoring.push report.json
      - uses: actions/upload-artifact@v4
        with:
          name: backtest-report
          path: report.json

Die Sharpe-Ratio, der Max-Drawdown und der Trade-Count landen in Prometheus — und ein Grafana-Alert schlägt an, wenn einer der Werte um mehr als zwei Sigma von der historischen Verteilung abweicht. Das fängt Daten-Korruption oft Tage vor dem ersten realen Schaden.

Deployment-Pipeline: dev, paper, live.

Wie eine Strategie von einer Idee bis ins Live-Konto kommt — die Stufen, die ich für Mandanten standardmäßig aufsetze:

Stufe 3 ist die wichtigste — und die, die am häufigsten übersprungen wird. Eine Strategie, die im Paper-Trading sauber lief und bei 20 % Größe live plötzlich Markt-Impact zeigt, verrät sich hier ohne großen Schaden. Bei voller Größe wäre das schon teuer geworden.

Rollback-Strategien.

Wenn etwas live schiefgeht — und das wird passieren — muss der Rollback geübt sein. Drei Stufen, in eskalierender Reihenfolge:

Wichtig: alle drei Pfade einmal pro Quartal trocken üben. Ein Rollback, den Sie zum ersten Mal um 14:30 Uhr im Live-Stress ausprobieren, ist kein Rollback — es ist ein zweites Problem zusätzlich zum ersten.

Warum CI/CD den Unterschied macht.

Ohne CI/CD läuft Strategie-Entwicklung typischerweise so: Code-Änderung, lokaler Backtest, „sieht gut aus", Deploy. Drei Wochen später wundert man sich, warum die Live-Performance abweicht. Erst nach drei Tagen Debugging fällt auf, dass eine Hilfsfunktion seit dem letzten Refactoring andere Signale liefert.

Mit CI/CD läuft es so: Code-Änderung, Push, Backtest-Regression schlägt fehl, Merge wird blockiert. Der Bug ist gefunden, bevor er live Geld kostet. Das ist nicht romantisch — aber es ist der Unterschied zwischen „ich glaube" und „ich weiß".

Bei meinen Mandanten ist das Aufsetzen der CI/CD-Pipeline meistens das erste, das ich tue. Vor neuen Strategien, vor Infrastruktur-Upgrades. Wer ohne Sicherheitsnetz iteriert, kann nicht mehr schnell iterieren — er muss vorsichtiger werden, und das bremst.

Sie iterieren Strategien manuell und merken Bugs erst, wenn das Equity-Diagramm komisch aussieht? Erstgespräch buchen — wir bauen die CI/CD, die Ihre Strategie-Entwicklung schneller und sicherer macht.