Reading Time: 11 minutes

Continuous Integration (CI) erstellt, testet und validiert den Forschungscode automatisch bei jedem Commit. Für wissenschaftliche Software ist CI für die Reproduzierbarkeit, die frühzeitige Fehlererkennung und die Aufrechterhaltung der Qualität im Laufe der Zeit unerlässlich. Implementieren Sie CI durch: (1) Schreiben automatisierter Tests mit PyTest, (2) Einrichten einer CI-Pipeline mit GitHub-Aktionen oder GitLab CI, (3) Verwenden von Docker / Conda für die Umgebungskonsistenz, (4) Hinzufügen von Berichterstellungsberichterstattung und (5) Integration von Leistungs-Benchmarks. Behandeln Sie numerische Tests mit pytest.approx, verwenden Sie Matrixstrategien, um Python-Versionen zu testen, und Cache-Abhängigkeiten, um die Laufzeit zu reduzieren. CI wandelt Forschungscode von fragilen Skripten in vertrauenswürdige, wartbare Software um.

Einleitung: Warum Continuous Integration für die Forschung wichtig ist

Forschungssoftware ist dafür berüchtigt, lautlos zu brechen. Eine kleine Änderung in einem Teil des Codes kann subtil unterschiedliche Ergebnisse im Folgenden erzeugen, was veröffentlichte Ergebnisse ungültig macht oder monatelange Rechenzeit verschwendet. Herkömmliche manuelle Tests – von Hand einige Beispiele ausführen – skalieren nicht auf komplexe Simulationscodes mit Dutzenden von voneinander abhängigen Modulen.

Continuous Integration (CI) behebt dies, indem es automatisch eine umfassende Testsuite ausführt, wenn Code festgeschrieben wird. Aber CI ist mehr als nur Automatisierung; Es ist eine Qualitätsdisziplin, die die Reproduzierbarkeit durchsetzt und die Korrektheit kontinuierlich bestätigt. Als Best Practices for Scientific Computing Papiernotizen: „Automatisiertes Testen ist Nicht verhandelbar für vertrauenswürdige wissenschaftliche Software „(Wilson et al., 2012).

Für Forschungsteams bietet CI konkrete Vorteile:

  • Reproduzierbarkeit: CI überprüft, ob der Code konsistente Ergebnisse in Umgebungen und im Laufe der Zeit liefert.
  • Early Defekterkennung: Fehler werden Minuten nach ihrer Einführung abgefangen, nicht Wochen später während der Erstellung der Manuskripte.
  • Zuversicht in Refactor: Mit einem Sicherheitsnetz von Tests können Sie die Codestruktur verbessern, ohne Angst zu haben, etwas zu brechen.
  • Collaboration Enablement: Mehrere Mitwirkende können auf derselben Codebasis arbeiten, indem sie automatische Überprüfungen verhindern.
  • Erwartungsdokumentation: Tests dienen als ausführbare Spezifikationen, die dokumentieren, wie sich der Code verhalten soll.

Trotz dieser Vorteile fehlt vielen Forschungsprojekten CI immer noch. Häufige Ausreden sind „Unser Code ist zu komplex, um zu testen“, „Tests dauern zu lange“ oder „Wir haben keine Zeit, CI einzurichten.“ Dieser Leitfaden löst diese Einwände und bietet einen praktischen, schrittweisen Ansatz für CI, der auf wissenschaftliche Software zugeschnitten ist.

Was ist wirklich kontinuierliche Integration?

Kontinuierliche Integration ist das Zusammenführen von Codeänderungen in einem gemeinsamen Repository häufig – idealerweise mehrmals pro Tag – und die automatische Überprüfung jeder Zusammenführung mit einer automatisierten Build- und Test-Pipeline. Der „kontinuierliche“ Teil bedeutet, dass das Feedback schnell ist; Entwickler wissen innerhalb weniger Minuten, ob ihre Änderung etwas kaputt gemacht hat.

Eine CI-Pipeline enthält typischerweise:

  1. Checkout: Das CI-System ruft den neuesten Code ab.
  2. Umgebungs-Setup: Abhängigkeiten werden installiert (häufig innerhalb eines Containers).
  3. Statische Analyse: Der Code ist für Stilprobleme und potenzielle Fehler furchtbar.
  4. Einheitstests: Einzelne Funktionen und Module werden isoliert getestet.
  5. Integrationstests: Mehrere Komponenten werden zusammen getestet.
  6. Coverage-Reporting: Der Anteil des Codes, der durch Tests ausgeübt wird, wird gemessen.
  7. Artefact Building: Dokumentation, Pakete oder Binärdateien werden generiert.
  8. Performance-Benchmarks (optional): Ausführungsgeschwindigkeit und Speichernutzung werden verfolgt.

Für Forschungssoftware fügen wir hinzu:

  • Numerische Validierung: Tests, die Gleitkommatoleranzen und stochastische Variationen berücksichtigen.
  • Überprüfungen der Reproduzierbarkeit: Überprüfung, dass die Ergebnisse innerhalb akzeptabler Grenzen übereinstimmen.
  • Datenvalidierung: Gewährleistung der Integrität der Eingabe- und Ausgabedaten.

Kernkomponenten: Aufbau einer forschungsbereiten CI-Pipeline

Eine robuste CI-Pipeline für wissenschaftliche Python-Projekte sollte diese Komponenten enthalten, die jeweils einen bestimmten Qualitätsaspekt ansprechen.

Automatisiertes Testen mit PyTest

Die Stiftung ist eine umfassende Testsuite mit pytest. PyTest ist der De-facto-Standard für Python-Tests aufgrund seiner Einfachheit, leistungsstarken Geräte und reichhaltigen Ökosystems.

Für den wissenschaftlichen Kodex konzentrieren Sie sich auf:

  • Einheitstests für einzelne Funktionen (z. B. berechnet ein Diffusionslöser korrekt auf einem einfachen Netz?).
  • Regressionstests, die die Ergebnisse mit bekannten guten Ergebnissen vergleichen (wesentlich für PDE-Solver).
  • Eigenschaftsbasierte Tests mit Hypothese, um zufällige Eingaben zu generieren und Invarianten zu überprüfen.

Der Einheitentest für den wissenschaftlichen Codeentwurf (in Bearbeitung) behandelt PYTest-Strategien in der Tiefe, einschließlich der numerischen Präzision.

Umgang mit numerischen Vergleichen

Der wissenschaftliche Code befasst sich mit Gleitkomma-Arithmetik, bei der eine exakte Gleichheit aufgrund von Rundungsfehlern oft nicht möglich ist. PYTEST bietet pytest.approx für ungefähre Vergleiche:

def test_diffusion_result():
    result = run_simulation()
    expected = 0.123456
    assert result == pytest.approx(expected, rel=1e-6)  # 0.1% tolerance

Verwenden Sie für Arrays numpy.testing.assert_allclose:

import numpy.testing as npt

def test_field_solution():
    computed = solve_pde()
    reference = load_reference_solution()
    npt.assert_allclose(computed, reference, rtol=1e-5, atol=1e-10)

Wählen Sie Toleranzen basierend auf der Physik und der Diskretisierungsgenauigkeit. Dokumentieren Sie, warum bestimmte Toleranzen ausgewählt wurden.

Codeabdeckungsmessung

Die Codeabdeckung misst, wie viel von Ihrer Codebasis während der Tests ausgeführt wird. Während eine 100% ige Abdeckung nicht immer erforderlich (oder erreichbar) ist, hilft die Verfolgung, ungetestete Codepfade zu identifizieren.

Verwenden Sie pytest-cov, um Berichterstattungsberichte zu erstellen:

pytest --cov=src/ --cov-report=xml --cov-report=html

Integrieren Sie Codecov oder coveralls, um die Abdeckung im Laufe der Zeit zu verfolgen und die Mindestgrenzwerte in CI zu erzwingen.

Das Wissenschaftliches Python-Entwicklungshandbuch enthält detaillierte Beispiele für die Konfiguration der Abdeckung.

Statische Analyse und Fusseln

Statische Analysetools fangen Fehler ab und erzwingen die Stilkonsistenz, bevor der Code zusammengeführt wird:

  • Flake8: PEP 8 Style Guide Durchsetzung und grundlegende Fehlerprüfung.
  • MyPy: statische Typprüfung (graduelle Eingabe ist auch im Forschungscode wertvoll).
  • Schwarz: Automatische Codeformatierung (eliminiert Stildebatten).
  • Pylint: Eine tiefere Analyse der Codequalität (vorsichtig anwenden; einige Regeln sind möglicherweise zu streng für den Forschungscode).

Führen Sie diese als separate CI-Jobs aus, damit Fehler nicht blockieren.

Umgebungskonsistenz mit Docker oder Conda

Eine der größten Herausforderungen für die Reproduzierbarkeit ist die Hölle der Abhängigkeit – verschiedene Versionen von Bibliotheken führen zu unterschiedlichen Ergebnissen. CI beseitigt dies durch die Installation von Abhängigkeiten in einer sauberen, kontrollierten Umgebung.

Option A: Docker (empfohlen für CI)

Docker bietet vollständige Containerisierung auf Systemebene. a Dockerfile definiert die genaue Umgebung:

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

BOETTIGER. (2015) argumentiert, dass Docker „das Beste ist, was jemals mit wissenschaftlicher Reproduzierbarkeit passiert“ ist, da es den gesamten Software-Stack vom Betriebssystem zu Bibliotheken sperrt.

Option B: Conda-Umgebungen

Wenn Ihr Projekt auf Nicht-Python-Abhängigkeiten (z. B. HDF5, MPI) angewiesen ist, verwenden Sie Conda:

# environment.yml
name: research-ci
dependencies:
  - python=3.11
  - numpy>=1.24
  - scipy
  - pip:
    - pytest
    - pytest-cov

CI-Systeme können diese Umgebung mit conda env create -f environment.yml erstellen und aktivieren.

Wichtig: Docker garantiert Reproduzierbarkeit nicht warnt davor, dass selbst Container subtile Unterschiede haben können (Zeitstempel, zufällig Samen). Fixieren Sie für maximale Reproduzierbarkeit auch Bibliotheksversionen und Seeds.

Dokumentationsaufbau

Fügen Sie einen Schritt zum Erstellen von Dokumentationen (Sphinx, Mkdocs) hinzu und stellen Sie diese optional bereit. Documentation-as-Code stellt sicher, dass die Dokumente mit dem Code synchron bleiben. Der Entwurf der Dokumentation Best Practices für wissenschaftliche Python-Pakete erläutert dies im Detail.

Leistungs-Benchmarks

Überwachen Sie für rechnerisch intensive Forschungssoftware die Leistung, um Regressionen abzufangen. Tools wie ASV (Airspeed Velocity) führen Benchmarks automatisch durch und vergleichen sie mit früheren Läufen.

Waller et al. (2015) beschreiben einschließlich Leistungs-Benchmarks in CI , um Leistungseinbußen frühzeitig zu erkennen. Dies ist besonders wichtig für PDE-Solver, bei denen algorithmische Änderungen die Laufzeit drastisch beeinflussen können.

Plattformvergleich: GitHub-Aktionen gegen GitLab CI

Es gibt zwei dominante CI-Plattformen: GitHub-Aktionen und GitLab CI. Beide sind ausgereift und produktionsbereit. Die Wahl hängt häufig davon ab, wo Ihr Code gehostet wird.

GitHub-Aktionen

Stärken:

  • Tiefe Integration mit GitHub (Pull Request Checks, Marktplatz der Aktionen).
  • Einfachere Konfigurationssyntax für gängige Workflows.
  • Größere Community und mehr Aktionen von Drittanbietern.
  • Kostenlos für öffentliche Repositories; Großzügige kostenlose Stufe für private Repos.

Schwächen:

  • Weniger leistungsfähig für komplexe Workflows als GitLab.
  • Eingeschränkte integrierte Funktionen für das Abhängigkeits-Caching in frühen Versionen (jetzt verbessert).
  • an das GitHub-Ökosystem gebunden.

Adoption: 33% der Organisationen nutzen GitHub-Aktionen (JetBrains, 2026).

Gitlab CI

Stärken:

  • Mehr funktionsreiche Out of the Box (alles in einer Plattform).
  • Leistungsstarke Matrixstrategien und Eltern-Kind-Pipelines.
  • Bessere Unterstützung für Monorepos.
  • Selbst-Hosting-Option für luftübergreifende Forschungsumgebungen.

Schwächen:

  • steilere Lernkurve.
  • Kleinere Community als GitHub-Aktionen.
  • Die Benutzeroberfläche kann sich weniger poliert anfühlen.

Adoption: 19% der Organisationen (JetBrains, 2026).

Empfehlung

Wenn sich Ihr Code auf GitHub befindet, verwenden Sie GitHub-Aktionen, um die Einfachheit und die Integration des Ökosystems zu gewährleisten. Wenn Sie GitLab sind oder erweiterte Pipeline-Funktionen benötigen, wählen Sie GitLab CI. Betrachten Sie in luftgegappten HPC-Umgebungen selbst gehostetes GitLab.

Beide Plattformen können die gleichen Ergebnisse erzielen; Unterschiede sind meistens Workflow-Präferenz. Die folgenden Beispiele verwenden GitHub-Aktionen aufgrund ihrer Popularität, aber GitLab CI-Äquivalente sind einfach zu konstruieren.

CI einrichten: Ein vollständiger GitHub-Aktions-Workflow

Dieser Abschnitt bietet einen produktionsbereiten GitHub-Aktions-Workflow für ein wissenschaftliches Python-Paket. Passen Sie es an Ihre Projektstruktur an.

Voraussetzungen

  1. Tests existieren (tests/ Verzeichnis).
  2. Anforderungen werden angeheftet (requirements.txt oder environment.yml).
  3. Optional, aber empfohlen: Dockerfile für die Reproduzierbarkeit der Umgebung.
  4. Das Code-Repository befindet sich auf GitHub.

Grundlegender Workflow

.github/workflows/ci.yml erstellen:

name: CI

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

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        python-version: ["3.9", "3.10", "3.11", "3.12"]

    steps:
    - uses: actions/checkout@v4

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v5
      with:
        python-version: ${{ matrix.python-version }}
        cache: 'pip'
        cache-dependency-path: 'requirements.txt'

    - name: Install dependencies
      run: |
        pip install --upgrade pip
        pip install -r requirements.txt
        pip install pytest pytest-cov

    - name: Run tests with coverage
      run: |
        pytest --cov=src/ --cov-report=xml --cov-report=term-missing --junitxml=test-results.xml

    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v4
      with:
        file: ./coverage.xml
        flags: unittests
        name: codecov-umbrella

    - name: Upload test results
      if: always()
      uses: actions/upload-artifact@v4
      with:
        name: test-results-${{ matrix.python-version }}
        path: test-results.xml

Schlüsselfunktionen:

  • Matrix-Strategie: Die Tests werden auf Python 3.9–3.12 parallel ausgeführt, wodurch Kompatibilitätsprobleme frühzeitig auftreten.
  • Caching: actions/setup-python Zwischenspeichert PIP-Pakete, wodurch die Installationszeit drastisch verkürzt wird.
  • Coverage: Terminalausgabe und XML für CodeCov.
  • Artefakte: Testergebnisse werden hochgeladen, auch wenn die Tests fehlschlagen, wodurch Beweise erhalten bleiben.

Docker in CI verwenden

Wenn Sie eine Dockerfile haben, verwenden Sie diese, um die Konsistenz der Umgebung sicherzustellen:

    - name: Build Docker image
      run: docker build -t myproject-ci -f Dockerfile.ci .

    - name: Run tests in Docker
      run: |
        docker run --rm 
          -v ${{ github.workspace }}:/app 
          myproject-ci 
          pytest --cov=src/ --cov-report=xml

Umgang mit langjährigen Tests

Wissenschaftliche Simulationen können Stunden dauern. CI-Läufer haben Zeitlimits (oft 6 Stunden). Strategien:

  1. Separate schnelle und langsame Tests: Verwenden Sie PYTest-Marker.
# In test file
import pytest

@pytest.mark.slow
def test_large_simulation():
    # Takes >5 minutes
    pass

in ci:

    - name: Run quick tests
      run: pytest -m "not slow"

    - name: Run slow tests (optional, separate job)
      if: github.event_name == 'schedule'  # Only on schedule, not on every PR
      run: pytest -m slow
  1. Testauswahl: Führen Sie nur Tests durch, die von der Codeänderung betroffen sind, indem pytest --last-failed oder pytest -k "test_name".
  2. Parallelize: Aufteilen von Tests auf mehrere CI-Jobs mit pytest-xdist.

Caching-Abhängigkeiten

Über das Caching von Python-Paketen hinaus, kompilierte Erweiterungen im Cache und große Datendateien:

    - name: Cache pip packages
      uses: actions/cache@v4
      with:
        path: ~/.cache/pip
        key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
        restore-keys: |
          ${{ runner.os }}-pip-

    - name: Cache pytest
      uses: actions/cache@v4
      with:
        path: .pytest_cache
        key: ${{ runner.os }}-pytest-${{ hashFiles('**/*.py') }}

Fusseln hinzufügen

Fügen Sie einen separaten Job hinzu, damit Stilprobleme die Testausführung nicht blockieren:

  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-python@v5
      with:
        python-version: "3.11"
    - run: pip install flake8 black mypy
    - run: flake8 src/ tests/
    - run: black --check src/ tests/
    - run: mypy src/

Häufige Fallstricke und wie man sie vermeidet

Basierend auf den Herausforderungen von CI / CD, die in der Forschungssoftware identifiziert wurden ( testmu AI, 2026 ), finden Sie hier häufige Fehler und Lösungen.

Fallfall 1: Tests, die abblättern

Flaky-Tests bestehen manchmal und scheitern andere und untergraben das Vertrauen in CI. Sie sind besonders häufig mit:

  • Rennbedingungen in parallelen Tests.
  • Timing-Annahmen (z. B. „Warte 1 Sekunde“).
  • Zufälligkeit ohne feste Samen.

Lösung: Alles bestimmen. Verwenden Sie pytest Fixtures mit scope="session" für gemeinsam genutzte Ressourcen. Setzen Sie zu Beginn jedes Tests zufällige Samen:

import random
import numpy as np

def setup_function():
    random.seed(42)
    np.random.seed(42)

Fallfall 2: CI das dauert zu lange

Wenn Ihre Pipeline Stunden dauert, werden die Entwickler sie umgehen.

Lösung:

  • Geteilt in schnelle (bei jedem Commit) und langsame (nächtliche) Jobs.
  • Cache aggressiv (PIP, Docker-Layer, Testdaten).
  • Parallelisieren Sie mithilfe von Matrixstrategien.
  • Markieren Sie bekannte langsame Tests mit @pytest.mark.slow und führen Sie sie separat aus.

Fallfall 3: Umgebungsabweichung zwischen CI und Entwicklung

Tests bestehen in CI, scheitern jedoch lokal, da sich die Umgebungen unterscheiden.

Lösung: Verwenden Sie überall dieselbe Umgebungsdefinition. Docker ist ideal: Entwickler führen docker-compose run test lokal aus und CI verwendet das gleiche Dockerfile. Alternativ können Sie tox verwenden, um mehrere Umgebungen konsistent zu verwalten.

Fallfall 4: Fehlende oder veraltete Abhängigkeiten

CI schlägt fehl, weil eine Abhängigkeit Upstream aktualisiert wurde und die Kompatibilität unterbrochen wurde.

Lösung: PIN-Abhängigkeiten exakt in requirements.txt (package==1.2.3), nicht mit Bereichen (>=1.0). Verwenden Sie eine Abhängigkeitssperrdatei (pip freeze > requirements.txt). Aktualisieren Sie regelmäßig Abhängigkeiten kontrolliert (z. B. wöchentlich dependabot PRS).

Fallfall 5: Keine Leistungsüberwachung

Der Code wird mit der Zeit langsamer, aber Sie bemerken nur, wenn er katastrophal ist.

Lösung: Fügen Sie CI mit ASV Benchmarks hinzu. Konfigurieren Sie es so, dass es fehlschlägt, wenn die Leistung über einen Schwellenwert hinausgeht (z. B. 5% langsamer). Die Implementierung finden Sie unter Python Speed’s Guide.

Fallfall 6: Ignorieren der numerischen Validierung

Tests verwenden == bei Floats und fehlen intermittierend oder schlimmer noch, nicht korrekt.

Lösung: Verwenden Sie überall pytest.approx und numpy.testing.assert_allclose. Wählen Sie Toleranzen basierend auf der numerischen Analyse (z. B. Diskretisierungsfehler sollte O (H²) für Methoden zweiter Ordnung sein). Begründung der Dokumenttoleranz in Test-DocStrings.

Entscheidungsleitfaden: Wann verwenden Sie was?

Plattformauswahl

Lage Empfohlene Plattform
Code auf GitHub gehostet GitHub-Aktionen
Code auf GitLab gehostet Gitlab CI
Brauchen Sie selbst gehostete Läufer (Luft Gapped) Gitlab CI (selbsthosted)
will einfachste Einrichtung GitHub-Aktionen
Komplexe Multiprojekt-Pipelines GitLab CI (Parent-Child-Pipelines)

Teststrategie

Codetyp Empfohlener Ansatz
Reine Python-Funktionen Unit-Tests mit Pytest, Ziel mit hoher Abdeckung (> 90%)
PDE-Solver Regressionstests gegen Referenzlösungen, eigenschaftsbasierte Tests
Stochastische Algorithmen Zufälliger Samen + statistische Tests (Mittelwert, Varianz)
Große Simulationen (> 5 min) Trennen Sie langsame Tests, laufen Sie jede Nacht; Verwenden Sie @pytest.mark.slow
Mehrkomponentenkopplung Integrationstests mit kleinen Testfällen, Kopplungskorrektheit validieren

Containerwahl

Notwendigkeit Empfehlung
Maximale Reproduzierbarkeit, einschließlich DEPs auf Betriebssystemebene Docking
Nur Python, einfacheres Management Conda-Umgebung
HPC mit MPI-Bibliotheken Conda (oder Docker mit --network=host und --ipc=host)
luftgedeckte Umgebung Conda Pack oder Docker speichern / laden

Integration von CI in Forschungs-Workflows

CI existiert nicht isoliert. Es verbindet sich mit anderen Tools und Praktiken.

Integration von Issue-Tracking

Der CI-Status wird bei GitHub/GitLab Pull-Anforderungen automatisch angezeigt. Configure branch protection rules to require CI passing before merge. Dadurch wird sichergestellt, dass nur validierter Code in den Hauptzweig eintritt.

Die bestehenden Beiträge von Matforge auf Issue-Tracking und Technische Schulden ergänzen CI, indem sie die Art und Weise der Verwaltung von Problemen definieren. CI bietet eine automatische Überprüfung, dass Probleme ordnungsgemäß behoben werden.

Reproduzierbarkeitsverbindung

Wie in Reproduzierbarkeit und seiner Rolle beim Debuggen erläutert, ist CI ein Eckpfeiler der reproduzierbaren Forschung. Jeder Commit, die CI übergibt, kann darauf vertrauen, dass auf jeder Maschine mit derselben Umgebung dieselben Ergebnisse erzielt werden. Dies ist unerlässlich für:

  • Papierreproduzierbarkeit: Wenn Rezensenten nach Code fragen, können Sie auf ein bestimmtes Commit verweisen, das CI bestanden und die Zahlen erstellt hat.
  • Kollaboration: Externe Mitwirkende können die gleichen Tests lokal durchführen.
  • Long-Term Maintenance: Jahre später können Sie die Ergebnisse eines CI-validierten Commits immer noch neu erstellen.

Code-Review-Workflow

CI mit obligatorischer Code-Überprüfung paaren:

  1. Entwickler pusht Branch, CI läuft.
  2. Wenn CI übergeht, öffnen Sie eine Pull-Anforderung.
  3. Prüfer überprüfen die Codelogik und stellen sicher, dass die Tests angemessen sind.
  4. Nur nach CI-Pässen zusammenführen und Überprüfung genehmigt.

Dieser Workflow ist in der Industrie Standard, in der Forschung jedoch immer noch selten. Die Implementierung erhöht die Softwarequalität dramatisch.

Fortgeschrittene Themen

Matrixtest für mehrere Abhängigkeiten

Wissenschaftliche Pakete hängen oft von numpy/scipy mit versionsspezifischem Verhalten ab. Testen Sie über eine Matrix von Python- und Abhängigkeitsversionen:

strategy:
  matrix:
    python-version: ["3.9", "3.10", "3.11"]
    numpy-version: ["1.24", "1.25", "1.26"]

Installieren Sie die spezifische Numpy-Version im Schritt Install dependencies:

    - run: |
        pip install "numpy==${{ matrix.numpy-version }}" scipy

Damit werden Kompatibilitätsprobleme frühzeitig behoben.

Leistungsregressionserkennung

Verwenden Sie ASV, um die Leistung im Laufe der Zeit zu verfolgen:

    - name: Run benchmarks
      run: |
        asv run --quick --show-stderr
      # asv compares against previous commits and reports regressions

Konfigurieren Sie ASV so, dass der CI-Job fehlschlägt, wenn ein Benchmark >10% langsamer als der vorherige Lauf ist. Weitere Informationen finden Sie in Pythonspeeds Artikel.

Kontinuierliche Bereitstellung der Dokumentation

CI kann die Dokumentation automatisch auf GitHub-Seiten bereitstellen:

  deploy-docs:
    needs: test  # Only run after tests pass
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - run: pip install -r requirements-docs.txt
    - run: sphinx-build -b html docs/ public/
    - uses: peaceiris/actions-gh-pages@v3
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        publish_dir: ./public

Dadurch wird die Dokumentation mit Codeänderungen synchronisiert.

Verwandte Anleitungen

Zusammenfassung und nächste Schritte

Continuous Integration verwandelt Forschungssoftware aus fragilen, undokumentierten Skripten in zuverlässige, wartbare Assets. Die Kernschritte sind:

  1. Schreiben Sie mit PyTest automatisierte Tests mit pytest.approx für numerische Vergleiche.
  2. Richten Sie eine CI-Pipeline (GitHub-Aktionen oder GitLab CI) ein, die bei jeder Push- und Pull-Anforderung ausgeführt wird.
  3. Verwenden Sie Docker oder Conda, um die Konsistenz der Umgebung zwischen CI und Entwicklung sicherzustellen.
  4. Fügen Sie Berichterstattungsberichterstattung, Fusting und Dokumentationserstellung hinzu.
  5. Überwachen Sie die Leistung mit Benchmarks, um Regressionen abzufangen.
  6. Integrieren Sie CI in Ihre bestehenden Prozesse zur Problemverfolgung und Codeüberprüfung.

Sofortaktionen:

  • Wenn Sie keine Tests haben, schreiben Sie zunächst einige für die kritischsten Funktionen. Sogar 20% Deckung ist besser als keine.
  • Erstellen Sie eine grundlegende CI-Konfigurationsdatei (.github/workflows/ci.yml wie oben gezeigt) und iterieren Sie.
  • Beheben Sie flockige Tests sofort – sie untergraben das Vertrauen.
  • Fügen Sie Ihrer Readme ein „Badge“ hinzu, das den CI-Status anzeigt (z. B. ci).

Wann sucht Beratung: Wenn es sich bei Ihrem Projekt um komplexe Abhängigkeiten (MPI, GPU-Code, proprietäre Bibliotheken) oder um 10.000 Codezeilen handelt, sollten Sie eine professionelle Überprüfung Ihres CI-Setups in Betracht ziehen. Wir bieten benutzerdefinierte CI / CD-Implementierungsdienste für Forschungsteams an.

Referenzen und Weiterlesen

Wortanzahl: ~2,200
Lesezeit: ~10 Minuten
Zielpublikum: Forscher, Doktoranden und Entwickler, die an wissenschaftlichen Python-Projekten arbeiten, die eine zuverlässige, automatisierte Qualität etablieren müssen Zusicherung