Intégration continue avec les actions GitHub

Introduction

Dans le laboratoire 8 du DPS909, j'ai exploré la puissance de l'Intégration continue (CI), en particulier via les Actions GitHub. Ce laboratoire a été une excellente occasion d'améliorer mon projet en automatisant les tests, en assurant le contrôle qualité et en apprenant à intégrer les flux de travail dans les pratiques de développement réelles.

CI garantit que le code reste fonctionnel et sans bug à chaque modification. Cela évite de casser la branche par défaut en exécutant des tests en continu. Pour ce laboratoire, j'ai non seulement intégré CI dans mon propre projet, mais j'ai également contribué aux tests du projet de mon partenaire. Cet article de blog reflète mon parcours à travers ces tâches.

---

Configuration des actions GitHub pour mon projet

Pour configurer CI dans mon projet, j'ai créé un GitHub Actions Workflow. Ce workflow était déclenché à chaque fois :

• Un push a été effectué vers la branche principale.
• Une pull request a été créée ciblant la branche principale.

Configuration du flux de travail YAML

Vous trouverez ci-dessous le fichier YAML que j'ai utilisé pour mon workflow GitHub Actions :

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

Ce workflow extrait mon référentiel, construit le projet à l'aide de CMake et exécute les tests que j'ai écrits dans le Lab 7.

---

Tester CI avec une Pull Request

Pour m'assurer que le flux de travail fonctionnait comme prévu, j'ai :

1. Création d'une nouvelle branche, ajout de plus de tests.
2. Ajout de nouveaux tests pour une fonction différente dans mon projet.
3. J'ai poussé la branche vers mon référentiel et ouvert une pull request ciblant la branche principale.

Le workflow CI s'est déroulé comme prévu :

• Au départ, j'ai cassé un des tests intentionnellement pour constater un échec. Les journaux montraient clairement le problème, ce qui rendait le débogage simple.
• Après avoir corrigé le test, le CI a réussi, confirmant le succès du flux de travail.

La fusion de cette pull request dans la branche principale m'a donné l'assurance que mon projet était protégé contre les bugs involontaires.

---

Contribuer aux tests au projet d’un partenaire

Dans la deuxième partie du laboratoire, j'ai collaboré avec mon camarade de classe, Inder Parmar, et contribué aux tests de leur référentiel, Tailor4Job.

Ma demande de tirage : #11

• Tâche : J'ai ajouté un scénario de test pour leur fonction jobFilter afin de m'assurer qu'elle gère correctement les cas extrêmes.
• Défis : Leur référentiel utilisait un framework et une configuration différents du mien. Comprendre leurs outils de test et la structure du projet a pris un certain temps.
• Résultat : Ma pull request a réussi leur workflow CI. Cette expérience m'a appris l'importance de rédiger des tests qui s'alignent sur la structure et les directives existantes d'un projet.

---

Réflexion sur l'intégration continue

La configuration de CI a changé la donne pour mon flux de travail de développement. Voici quelques points à retenir :

• Prévention proactive des bogues : CI garantit que les bogues sont détectés tôt, réduisant ainsi le risque de rupture de la branche par défaut.
• Facilité de collaboration : les tests automatisés donnent confiance lors de la fusion du code de plusieurs développeurs.
• Débogage amélioré : les journaux CI ont fourni des informations détaillées sur les échecs des tests, rendant le débogage plus rapide et plus efficace.

Collaborer sur le dépôt d'un partenaire a été une expérience enrichissante, car cela m'a permis de découvrir une base de code, un environnement de test et un flux de travail différents.

---

Défis facultatifs

Bien que je n'aie pas entièrement mis en œuvre les défis facultatifs, j'ai exploré :

1. Ajout d'un linter : l'automatisation du peluchage dans le cadre de CI permet de détecter rapidement les problèmes de style et de syntaxe.
2. Conteneurs de développement : j'ai expérimenté la mise en place d'un environnement de développement reproductible à l'aide de Docker et de Codespaces.

Ces étapes peuvent améliorer encore davantage la qualité du projet et faciliter l'intégration des nouveaux contributeurs.

---

Conclusion

Le Lab 8 m'a appris l'importance d'intégrer les workflows CI dans les projets de développement. CI garantit un contrôle qualité cohérent et favorise la collaboration, ce qui en fait un outil précieux dans le développement de logiciels modernes.

Vous pouvez consulter l'exécution réussie de CI de mon projet et la demande d'extraction du projet de mon partenaire ci-dessous :

• Exécution du flux de travail CI : actions GitHub
• PR Repo du partenaire : Pull Request #11

Ce laboratoire a véritablement amélioré ma compréhension de l'automatisation, des tests et de la collaboration dans le développement open source.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!