GitHub アクションとの継続的統合

導入

DPS909 のラボ 8 では、継続的インテグレーション (CI) の力を、特に GitHub Actions を通じて調査しました。このラボは、テストを自動化し、品質管理を確保し、実際の開発実践にワークフローを統合する方法を学ぶことで、私のプロジェクトを強化する素晴らしい機会でした。

CI は、コードが変更されても機能し、バグがない状態を維持することを保証します。テストを継続的に実行することで、デフォルトのブランチが壊れるのを防ぎます。このラボでは、CI を自分のプロジェクトに統合しただけでなく、パートナーのプロジェクトにもテストを提供しました。このブログ投稿は、これらのタスクを通じた私の旅を反映しています。

---

自分のプロジェクトの GitHub アクションのセットアップ

プロジェクトで CI をセットアップするために、GitHub Actions Workflow を作成しました。このワークフローは、次の場合にトリガーされました。

• メインブランチにプッシュが行われました。
• メイン ブランチをターゲットとするプル リクエストが作成されました。

YAML ワークフロー構成

以下は、GitHub Actions ワークフローに使用した YAML ファイルです。

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

このワークフローは、リポジトリをチェックアウトし、CMake を使用してプロジェクトをビルドし、ラボ 7 で作成したテストを実行します。

---

プルリクエストによる CI のテスト

ワークフローが期待どおりに機能していることを確認するために、次のことを行いました。

1. 新しいブランチ add-more-tests を作成しました。
2. プロジェクト内の別の関数に新しいテストを追加しました。
3. ブランチをリポジトリにプッシュし、メイン ブランチをターゲットとするプル リクエストをオープンしました。

CI ワークフローは期待どおりに実行されました:

• 最初、私は失敗を観察するために意図的にテストの 1 つを破りました。ログには問題が明確に示されているため、デバッグが簡単になりました。
• テストを修正した後、CI が合格し、ワークフローの成功が確認されました。

このプル リクエストをメイン ブランチにマージしたことで、プロジェクトが意図しないバグから保護されているという自信が得られました。

---

パートナーのプロジェクトへのテストの貢献

ラボの 2 番目の部分では、クラスメートの Inder Parmar と協力して、彼らのリポジトリ Tailor4Job にテストをコントリビュートしました。

私のプルリクエスト: #11

• タスク: エッジケースが正しく処理されることを確認するために、jobFilter 関数のテスト ケースを追加しました。
• 課題: 彼らのリポジトリは、私のものとは異なるフレームワークと設定を使用していました。テスト ツールとプロジェクトの構造を理解するのに時間がかかりました。
• 結果: 私のプル リクエストは、CI ワークフローに正常に合格しました。この経験から、プロジェクトの既存の構造とガイドラインに沿ったテストを作成することの重要性を学びました。

---

継続的インテグレーションについての考察

CI のセットアップは、私の開発ワークフローにとって大きな変革でした。以下に重要なポイントをいくつか示します:

• プロアクティブなバグ防止: CI はバグを早期に発見し、デフォルトのブランチを破壊するリスクを軽減します。
• コラボレーションの容易さ: 自動化されたテストにより、複数の開発者のコ​​ードをマージする際に自信が得られます。
• デバッグの改善: CI ログにより、テストの失敗に関する詳細な洞察が得られ、デバッグがより迅速かつ効率的になりました。

パートナーのリポジトリでの共同作業は、異なるコードベース、テスト環境、ワークフローに触れることができたので、充実した経験でした。

---

オプションのチャレンジ

オプションの課題を完全には実装していませんが、次のことを検討しました。

1. リンターの追加: CI の一部としてリンティングを自動化すると、スタイルと構文の問題を早期に発見するのに役立ちます。
2. 開発コンテナ: Docker と Codespaces を使用して再現可能な開発環境をセットアップして実験しました。

これらの手順により、プロジェクトの品質がさらに向上し、新しい貢献者のオンボーディングが容易になります。

---

結論

ラボ 8 では、CI ワークフローを開発プロジェクトに統合することの重要性を学びました。 CI は一貫した品質管理を保証し、コラボレーションを促進するため、現代のソフトウェア開発において非常に貴重なツールとなっています。

私のプロジェクトの CI 実行の成功とパートナーのプロジェクトへのプル リクエストを以下で確認できます。

• CI ワークフローの実行: GitHub アクション
• パートナーのリポジトリ PR: プル リクエスト #11

このラボにより、オープンソース開発における自動化、テスト、コラボレーションについての理解が深まりました。

以上がGitHub アクションとの継続的統合の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。