Kontinuierliche Integration mit GitHub-Aktionen

Einführung

In Lab 8 von DPS909 habe ich die Leistungsfähigkeit von Continuous Integration (CI) erkundet, insbesondere durch GitHub Actions. Dieses Labor war eine großartige Gelegenheit, mein Projekt zu verbessern, indem ich Tests automatisierte, die Qualitätskontrolle sicherstellte und lernte, Arbeitsabläufe in reale Entwicklungspraktiken zu integrieren.

CI stellt sicher, dass der Code bei jeder Änderung funktionsfähig und fehlerfrei bleibt. Es verhindert, dass der Standardzweig durch kontinuierliche Ausführung von Tests unterbrochen wird. Für dieses Labor habe ich CI nicht nur in mein eigenes Projekt integriert, sondern auch Tests zum Projekt meines Partners beigetragen. Dieser Blogbeitrag reflektiert meine Reise durch diese Aufgaben.

---

Einrichten von GitHub-Aktionen für mein Projekt

Um CI in meinem Projekt einzurichten, habe ich einen GitHub Actions Workflow erstellt. Dieser Workflow wurde immer dann ausgelöst:

• Es wurde ein Push zur Hauptniederlassung durchgeführt.
• Es wurde eine Pull-Anfrage erstellt, die auf den Hauptzweig abzielt.

YAML-Workflow-Konfiguration

Unten ist die YAML-Datei, die ich für meinen GitHub Actions-Workflow verwendet habe:

name: CI Workflow

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up C++
        uses: actions/setup-cpp@v1
        with:
          compiler: gcc

      - name: Build the project
        run: |
          mkdir build
          cd build
          cmake ..
          make

      - name: Run Tests
        run: |
          cd build
          ctest

Dieser Workflow überprüft mein Repository, erstellt das Projekt mit CMake und führt die Tests aus, die ich in Lab 7 geschrieben habe.

---

CI mit einem Pull Request testen

Um sicherzustellen, dass der Arbeitsablauf wie erwartet funktionierte, habe ich:

1. Neuen Zweig erstellt, weitere Tests hinzufügen.
2. Neue Tests für eine andere Funktion in meinem Projekt hinzugefügt.
3. Ich habe den Zweig in mein Repository verschoben und eine Pull-Anfrage für den Hauptzweig geöffnet.

Der CI-Workflow verlief wie erwartet:

• Anfangs habe ich einen der Tests absichtlich abgebrochen, um einen Fehler festzustellen. Die Protokolle zeigten das Problem deutlich, was das Debuggen vereinfachte.
• Nachdem der Test behoben wurde, bestand das CI den Erfolg und bestätigte damit den Erfolg des Workflows.

Das Zusammenführen dieser Pull-Anfrage im Hauptzweig gab mir die Gewissheit, dass mein Projekt vor unbeabsichtigten Fehlern geschützt war.

---

Mitwirken an Tests zum Projekt eines Partners

Im zweiten Teil des Labors arbeitete ich mit meinem Klassenkameraden Inder Parmar zusammen und steuerte Tests zu deren Repository Tailor4Job bei.

Mein Pull-Request: #11

• Aufgabe: Ich habe einen Testfall für ihre jobFilter-Funktion hinzugefügt, um sicherzustellen, dass Randfälle korrekt verarbeitet werden.
• Herausforderungen: Ihr Repository verwendete ein anderes Framework und Setup als meines. Es dauerte einige Zeit, ihre Testtools und Projektstruktur zu verstehen.
• Ergebnis: Meine Pull-Anfrage hat ihren CI-Workflow erfolgreich bestanden. Diese Erfahrung hat mich gelehrt, wie wichtig es ist, Tests zu schreiben, die mit der bestehenden Struktur und den Richtlinien eines Projekts übereinstimmen.

---

Überlegungen zur kontinuierlichen Integration

Die Einrichtung von CI hat meinen Entwicklungsworkflow grundlegend verändert. Hier sind einige wichtige Erkenntnisse:

• Proaktive Fehlerprävention: CI stellt sicher, dass Fehler frühzeitig erkannt werden, wodurch das Risiko einer Beschädigung des Standardzweigs verringert wird.
• Einfache Zusammenarbeit: Automatisierte Tests geben Sicherheit beim Zusammenführen von Code mehrerer Entwickler.
• Verbessertes Debuggen: CI-Protokolle lieferten detaillierte Einblicke in Testfehler und machten das Debuggen schneller und effizienter.

Die Zusammenarbeit am Repo eines Partners war eine bereichernde Erfahrung, da ich dadurch eine andere Codebasis, Testumgebung und einen anderen Arbeitsablauf kennenlernen konnte.

---

Optionale Herausforderungen

Obwohl ich die optionalen Herausforderungen nicht vollständig umgesetzt habe, habe ich Folgendes untersucht:

1. Hinzufügen eines Linter: Durch die Automatisierung von Linting als Teil von CI können Stil- und Syntaxprobleme frühzeitig erkannt werden.
2. Entwicklungscontainer: Ich habe mit der Einrichtung einer reproduzierbaren Entwicklungsumgebung mithilfe von Docker und Codespaces experimentiert.

Diese Schritte können die Projektqualität weiter verbessern und das Onboarding für neue Mitwirkende erleichtern.

---

Abschluss

Lab 8 hat mir gezeigt, wie wichtig die Integration von CI-Workflows in Entwicklungsprojekte ist. CI gewährleistet eine konsistente Qualitätskontrolle und fördert die Zusammenarbeit, was es zu einem unschätzbar wertvollen Werkzeug in der modernen Softwareentwicklung macht.

Sie können sich unten den erfolgreichen CI-Lauf meines Projekts und die Pull-Anfrage an das Projekt meines Partners ansehen:

• CI-Workflow-Ausführung: GitHub-Aktionen
• Repo-PR des Partners: Pull Request #11

Dieses Labor hat mein Verständnis von Automatisierung, Tests und Zusammenarbeit in der Open-Source-Entwicklung wirklich erweitert.

Das obige ist der detaillierte Inhalt vonKontinuierliche Integration mit GitHub-Aktionen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!