Freigeben über

Modernisieren Sie Ihre Softwareentwicklung mit kontinuierlicher Integration

Wenn Code entwickelt, aktualisiert oder sogar entfernt wird, bietet eine intuitive und sichere Methode, diese Änderungen in den Haupt-Code-Zweig zu integrieren, Entwicklern die Möglichkeit, echten Mehrwert zu schaffen.

Als Entwickler können Sie kleine Codeänderungen vornehmen, diese Änderungen in ein Code-Repository übertragen und nahezu sofort Feedback zur Qualität, Test-Abdeckung und aufgetretenen Fehlern erhalten. Durch diesen Prozess können Sie schneller, sicherer und mit weniger Risiko arbeiten.

Continuous Integration (CI) ist eine Praxis, in der Quellcodeverwaltungssysteme und Softwarebereitstellungspipelinen integriert sind, um automatisierte Build-, Test- und Feedbackmechanismen für Softwareentwicklungsteams bereitzustellen.

Der kontinuierliche Integrationsprozess beginnt, wenn ein Ingenieur eine GitHub-Pullanforderung erstellt, um dem CI-System zu signalisieren, dass Codeänderungen zur Integration bereit sind. Im Idealfall validiert der Integrationsprozess den Code anhand mehrerer Referenzwerte und Tests. Anschließend erhält der anfordernde Ingenieur Feedback zum Status dieser Tests.

Wenn Basisüberprüfungen und Tests gut verlaufen, schafft und stellt der Integrationsprozess Ressourcen bereit, die die aktualisierte Software bereitstellen. Zu diesen Assets gehören kompilierter Code und Containerimages.

Mithilfe der folgenden Aktionen können Sie mithilfe der kontinuierlichen Integration qualitativ hochwertige Software schneller bereitstellen:

  • Führen Sie automatisierte Tests des Codes durch, um Breaking Changes frühzeitig zu erkennen.
  • Führen Sie eine Codeanalyse durch, um Codestandards, -qualität und -konfiguration sicherzustellen.
  • Führen Sie Compliance- und Sicherheitsprüfungen aus, um sicherzustellen, dass die Software keine bekannten Sicherheitsrisiken aufweist.
  • Führen Sie Abnahme- oder Funktionstests durch, um sicherzustellen, dass die Software wie erwartet funktioniert.
  • Geben Sie schnelles Feedback zu erkannten Problemen.
  • Erstellen Sie gegebenenfalls bereitstellbare Assets oder Pakete, die den aktualisierten Code enthalten.

Automatisieren der kontinuierlichen Integration mit Pipelines

Um eine kontinuierliche Integration zu erreichen, verwenden Sie Softwarelösungen, um den Prozess zu verwalten, zu integrieren und zu automatisieren. Eine gängige Vorgehensweise besteht darin, eine fortlaufende Integrationspipeline zu verwenden.

Eine fortlaufende Integrationspipeline umfasst eine Software (häufig in der Cloud gehostet), die Folgendes bereitstellt:

  • Eine Plattform zum Ausführen automatisierter Tests.
  • Compliancescans.
  • Die Berichterstellung
  • Alle anderen Komponenten, die den kontinuierlichen Integrationsprozess bilden.

In den meisten Fällen ist die Pipelinesoftware an die Quellcodeverwaltung angebunden, sodass die Continuous-Integration-Pipeline ausgeführt wird, wenn Pull-Requests erstellt oder Software in eine bestimmte Verzweigung zusammengeführt werden. Die Integration der Quellcodeverwaltung bietet außerdem die Möglichkeit, CI-Feedback direkt zu Pullanforderungen zu geben.

Viele Lösungen, wie Azure Pipelines oder GitHub Actions, bieten die Funktionen kontinuierlicher Integrationspipelines.

Integrieren von Pipelines in die Quellcodeverwaltung

Die Integration Ihrer kontinuierlichen Integrationspipeline in Ihr Quellcodeverwaltungssystem ist der Schlüssel dafür, schnelle Self-Service-Codebeiträge zu ermöglichen.

Die CI-Pipeline wird in einer neu erstellten Pullanforderung ausgeführt. Die Pipeline umfasst sämtliche Tests, Sicherheitsbewertungen und andere Prüfungen. CI-Testergebnisse werden direkt in der Pullanforderung angezeigt, um nahezu Echtzeit-Feedback zur Qualität zu ermöglichen.

Eine weitere beliebte Vorgehensweise ist das Erstellen kleiner Berichte oder Badges, die in der Quellcodeverwaltung angezeigt werden können, um den aktuellen Build-Status sichtbar zu machen.

Das folgende Bild zeigt die Integration zwischen GitHub und einer Azure DevOps-Pipeline. In diesem Beispiel löst die Erstellung einer Pullanforderung eine Azure DevOps-Pipeline aus. Der Pipelinestatus wird in der Pullanforderung angezeigt.

Screenshot eines Azure DevOps-Statussignals in einem GitHub-Repository.

Integrieren automatisierter Tests

Ein Schlüsselelement der kontinuierlichen Integration ist das kontinuierliche Erstellen und Testen von Code, während Entwickler Codebeiträge leisten. Das Testen von Pullanforderungen, während sie erstellt werden, gibt schnelles Feedback, dass der Commit keine grundlegenden Änderungen eingeführt hat. Der Vorteil besteht darin, dass die Tests in der kontinuierlichen Integrationspipeline dieselben Tests sein können, die während der testgesteuerten Entwicklung ausgeführt werden.

Der folgende Codeausschnitt zeigt einen Testschritt aus einer Azure DevOps-Pipeline. Der Schritt umfasst zwei Aufgaben:

  • Die erste Aufgabe verwendet ein beliebtes Python-Testframework zum Ausführen von CI-Tests. Diese Tests befinden sich zusammen mit dem Python-Code in der Quellcodeverwaltung. Die Testergebnisse gehen zu einer Datei mit dem Namen test-results.xml.
  • Die zweite Aufgabe nutzt die Testergebnisse und veröffentlicht sie als integrierten Bericht in der Azure DevOps-Pipeline.
- script: |
    pip3 install pytest
    pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
    continueOnError: true

- task: PublishTestResults@2
    displayName: 'Publish Test Results'
    inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Python $(python.version)'

Die folgende Abbildung zeigt Testergebnisse, die im Azure DevOps-Portal angezeigt werden.

Screenshot der Azure DevOps-Pipelinetests im Azure DevOps-Portal.

Fehlgeschlagene Tests

Fehlgeschlagene Tests sollten eine Bereitstellung vorübergehend blockieren und zu einer gründlicheren Analyse des Geschehens führen. Fehlgeschlagene Tests sollten außerdem entweder zu einer Verfeinerung der Tests oder zu einer Verbesserung der Änderung führen, die zum Fehlschlagen der Tests geführt hat.

Buildstatus veröffentlichen

Viele Entwickler zeigen, dass ihre Codequalität hoch ist, indem ein Statussignal in ihrem Repository angezeigt wird. Die folgende Abbildung zeigt ein Azure Pipelines-Signal, das in der Readme-Datei für ein Open-Source-Projekt in GitHub angezeigt wird.

Screenshot eines Azure Pipelines-Badges in einer Infodatei in GitHub.

Optimieren von Buildzeiten

Um schnellere Builds auszuführen, haben Sie folgende Möglichkeiten:

  • Wählen Sie Agents aus, die Ihren Leistungsanforderungen entsprechen: Beschleunigen Sie Ihre Builds, indem Sie die richtigen Buildcomputer auswählen. Schnelle Computer können den Unterschied zwischen Stunden und Minuten machen. Wenn Sich Ihre Pipelines in Azure-Pipelines befinden, können Sie Ihre Aufträge mit einem von Microsoft gehosteten Agent ausführen. Wenn Sie von Microsoft gehostete Agents verwenden, werden Wartungs- und Upgrades für Sie erledigt. Weitere Informationen finden Sie unter Von Microsoft gehostete Agents.

  • Optimieren Sie den Standort des Buildservers: Wenn Sie Ihren Code erstellen, werden Daten über das Netzwerk gesendet. Eingaben für die Builds werden aus einem Quellcodeverwaltungs-Repository und dem Artefakt-Repository abgerufen. Die Ausgabe des Buildprozesses muss kopiert werden, einschließlich der kompilierten Artefakte, Testberichte, Codeabdeckungsergebnisse und Debugsymbole. Es ist wichtig, dass diese Kopieraktionen schnell ausgeführt werden. Wenn Sie Ihren eigenen Buildserver verwenden, stellen Sie sicher, dass sich der Buildserver in der Nähe der Quellen und eines Zielspeicherorts befindet. Schnelle Uploads und Downloads können die Gesamtbuildzeit reduzieren.

  • Skalieren von Buildservern: Ein einzelner Buildserver reicht möglicherweise für ein kleines Produkt aus. Da die Größe und der Umfang des Produkts und die Anzahl der teams, die an dem Produkt arbeiten, steigt, reicht ein einzelner Server möglicherweise nicht aus. Skalieren Sie Ihre Infrastruktur horizontal über mehrere Computer, wenn Sie den Grenzwert erreichen. Weitere Informationen finden Sie unter Erstellen und Verwalten von Agentpools.

  • Optimieren Sie den Build:

    • Fügen Sie parallele Aufträge hinzu, um den Buildprozess zu beschleunigen. Weitere Informationen finden Sie unter Konfigurieren und Bezahlen für parallele Aufträge.

    • Aktivieren Sie parallele Testsuiteausführungen, die häufig eine große Zeit sparen, insbesondere beim Ausführen von Integrations- und UI-Tests. Weitere Informationen finden Sie unter "Parallele Ausführung von Tests für jeden Testläufer".

    • Verwenden Sie den Begriff eines Multiplikators, in dem Sie Ihre Builds über mehrere Build-Agents skalieren können. Weitere Informationen finden Sie unter Angeben von Aufträgen in Ihrer Pipeline.

    • Erwägen Sie das Verschieben von Integrations-, UI- und Rauchtests in eine Releasepipeline. Der Wechsel zu einer Releasepipeline verbessert die Buildgeschwindigkeit und die Geschwindigkeit der Buildfeedbackschleife.

    • Veröffentlichen Sie die Buildartefakte in einer Paketverwaltungslösung, z. B. NuGet oder Maven. Mit der Veröffentlichung in einer Paketverwaltungslösung können Sie Ihr Buildartefakt einfacher wiederverwenden.

Implementierung von Build-Typen für Ihre Workflows

Ihre Organisation kann verschiedene Arten von Builds erstellen, um Buildzeiten zu optimieren. Mögliche Builds sind:

  • Continuous Integration (CI)-Build: Der Zweck dieses Builds besteht darin, sicherzustellen, dass Code kompiliert wird und Komponententests ausgeführt werden. Dieser Build wird bei jedem Commit ausgelöst. Sie dient als Takt des Projekts und liefert dem Team im_imagestely qualitätsbezogenes Feedback. Weitere Informationen finden Sie unter Angeben von Ereignissen, die Pipelines auslösen.

  • Nightly Build: Der Zweck eines nächtlichen Builds besteht nicht nur darin, den Code zu kompilieren, sondern auch, um sicherzustellen, dass alle größeren Testsammlungen, die ineffizient sind, in regelmäßigen Abständen für jeden Build ausgeführt werden. In der Regel umfassen diese Tests Integrations-, Benutzeroberflächen- oder Rauchtests. Weitere Informationen finden Sie unter Konfigurieren von Zeitplänen für Pipelines.

  • Release-Build: Zusätzlich zum Kompilieren und Ausführen von Tests umfasst dieser Build auch das Erstellen der API-Dokumentation, der Compliance-Berichte, der Codesignatur und anderer Schritte, die nicht jedes Mal erforderlich sind, wenn der Code erstellt wird. Dieser Build stellt die Masterkopie bereit, die in die Releasepipeline übertragen wird, um schließlich in der Produktionsumgebung eingesetzt zu werden.

Die Typen von Builds, die von Ihrer Organisation benötigt werden, hängen von Faktoren ab, einschließlich der Reife Ihres Teams und der Organisation, der Art des Produkts, an dem Sie arbeiten, und Ihrer Bereitstellungsstrategie.

Erfahren Sie, wie Sie eine fortlaufende Integrationspipeline mithilfe von GitHub oder Azure DevOps erstellen:

Erfahren Sie, wie Sie Abzeichen in Ihren Repositories anzeigen: