GitHub Actions を使用して CI のワークフローを作成するには

  • 9 分

開発者がコード ベースに変更を追加するたびに機能が更新されるように、コードのビルドと発行プロセスを自動化することが目的であることを思い出してください。

このプロセスを実装するには、次の方法を学習します。

  • テンプレートからワークフローを作成します。
  • 再利用可能なワークフローを使用して重複を回避します。
  • 複数のターゲットに対してテストする。
  • ビルド ジョブとテスト ジョブを分離します。

テンプレートからワークフローを作成する

ワークフローを作成するには、テンプレートを使用することから始めるのが一般的です。 テンプレートには、実装している特定の種類の自動化に対して事前に構成された一般的なジョブとステップがあります。 ワークフロー、ジョブ、手順に慣れていない場合は、 GitHub Actions モジュールを使用して開発タスクを自動化 する方法を確認してください。

GitHub リポジトリのメイン ページで、[ アクション] を選択し、[ 新しいワークフロー] を選択します。

[ ワークフローの選択 ] ページでは、さまざまな種類のテンプレートから選択できます。 1 つの例として、Node.js テンプレートがあります。 Node.js テンプレートでは、Node.js とすべての依存関係がインストールされ、ソース コードがビルドされ、さまざまなバージョンの Node.jsのテストが実行されます。 もう 1 つの例として、 Python とその 依存関係をインストールし、lint を含むテストを複数のバージョンの Python で実行する Python パッケージ テンプレートがあります。

Node.js ワークフロー テンプレートから開始するには、検索ボックスに「 Node.js」と入力します。

検索ボックスが強調表示され、テキストが Node.jsされた [GitHub Actions] タブを示すスクリーンショット。

検索結果の [Node.js ] ウィンドウで、[ 構成] を選択します。

[Node.js] ウィンドウが強調表示され、[構成] ボタンが選択されている [GitHub Actions] タブを示すスクリーンショット。

プロジェクトの node.js.yml ファイルがテンプレートから作成されます。

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

on属性に示すように、この例のワークフローは、リポジトリへのプッシュに応答するか、メイン ブランチに対してプル要求が作成されたときに実行されます。

このワークフローは、 job 属性で示される 1 つのジョブを実行します。

runs-on属性は、オペレーティング システムに対してワークフローがubuntu-latestで実行されることを指定します。 node-version属性は、バージョン 14.x、16.x、18.x Node.js それぞれ 3 つのビルドがあることを指定します。 matrix属性については、モジュールの後半で詳しい説明を行います。

jobs属性では、GitHub Actions アクション/checkout@v3 アクションを使用して、リポジトリから仮想マシン (VM) にコードを取得し、actions/setup-node@v3 を使用して正しいバージョンの Node.jsを設定します。 ${{ matrix.node-version }}属性を使用して、Node.js の 3 つのバージョンをテストするように指定します。 この属性は、前に定義したマトリックスを参照します。 cache属性は、既定のディレクトリにキャッシュするためのパッケージ マネージャーを指定します。

この手順の最後の部分では、Node.js プロジェクトが使用するコマンドを実行します。 npm ci コマンドは、package-lock.json ファイルから依存関係をインストールします。 npm run build --if-present が存在する場合はビルド スクリプトを実行します。 npm test はテスト フレームワークを実行します。 このテンプレートには、同じジョブのビルドステップとテストステップの両方が含まれています。

npm の詳細については、npm のドキュメントを参照してください。

開発者のチームは、再利用可能なワークフローを使用して、自動化の繰り返し手順を合理化および標準化することでメリットを得ることができます。 再利用可能なワークフローを使用することで、冗長性を減らし、保守性を向上させ、継続的インテグレーション/継続的デプロイ (CI/CD) パイプライン全体の一貫性を確保できます。

再利用可能なワークフローを使用して重複を回避する

チームの規模とプロジェクトが拡大するにつれて、複数のワークフロー ファイルで同じ手順が繰り返されるのが一般的です。 これらの手順には、コードのチェックアウト、依存関係のインストール、テスト、デプロイが含まれる場合があります。 この種の重複により、コード ベースが煩雑になるだけでなく、コードの変更が必要な場合のメンテナンス時間も長くなります。 再利用可能なワークフローでは、自動化ロジックを 1 回定義し、他のワークフローからロジックを呼び出すことで、この問題を解決できます。

再利用可能なワークフローは、プログラミングの関数と同様に、他のワークフローが呼び出すことができる特別な GitHub Actions ワークフローです。 それらを作成して、ビルド ステップ、テスト 手順、デプロイ戦略などの繰り返しのロジックを共有します。 再利用可能なワークフローを作成した後は、同じリポジトリ内または異なるリポジトリ内の他のワークフローから参照できます。

GitHub Actions の再利用可能なワークフローの概念を示す図。複数のリポジトリまたはワークフローは、中央のワークフローを参照できます。

再利用可能なワークフローを使用する理由

再利用可能なワークフローを使用する利点は次のとおりです。

  • 一貫性。 Teams は、すべてのプロジェクトで同じ自動化標準に従うことができます。
  • 効率性。 ステップをコピーして貼り付ける代わりに、再利用可能なワークフローを指すだけです。
  • より簡単な更新。 テスト ステップを追加するなどしてプロセスが変更された場合は、1 つの場所で更新します。 すると、そのワークフローを使用するすべてのワークフローが自動的にその恩恵を受けます。
  • スケーラビリティ。 再利用可能なワークフローは、複数のサービスを管理するプラットフォームまたは DevOps チームに最適です。

次に、再利用可能なワークフローを使用してプロジェクトを改善する方法について説明します。

再利用可能なワークフローを実装する

再利用可能なワークフローを使用するには:

  1. リポジトリ フォルダーに、再利用可能なワークフローを作成します。 このファイルには、テスト、ビルド、デプロイに関連する一般的な手順など、共有する自動化手順が含まれています。
  2. workflow_call イベントを使用してワークフローを構成することで、ワークフローを再利用可能に明示的に有効にします。
  3. メイン ワークフロー (呼び出し元ワークフロー) で、この再利用可能なファイルを参照し、必要な入力またはシークレットを指定します。

再利用可能なワークフローの利点を示すために、次の実際のシナリオを検討してください。

例

組織に 10 個のマイクロサービスがあるとします。 10 個のマイクロサービスはすべて、次の操作を行うために同じ手順を必要とします。

  • テストを実行する
  • コードをリントする
  • 特定の環境にデプロイする

再利用可能なワークフローがない場合、各リポジトリは複数のワークフロー ファイル間で同じロジックを複製し、ステップの繰り返しとメンテナンスが困難になります。

再利用可能なワークフローを使用する場合:

  • プロセスは、中央ファイル (たとえば、 ci-standard.yml) で 1 回定義します。
  • このファイルは、すべてのマイクロサービス独自のワークフローから呼び出し、環境やアプリケーション名などの変数を渡します。

脆弱性のスキャンなど、新しいセキュリティ手順またはツールが追加された場合は、再利用可能なワークフローに 1 回だけ追加します。 10 個のマイクロサービスはすべて、更新されたプロセスの使用をすぐに開始します。 10 個のマイクロサービスを変更する必要はありません。

再利用可能なワークフローの機能とその利点を理解することで、ベスト プラクティスを採用して有効性を最大化し、CI/CD パイプラインとのシームレスな統合を確保できます。

ベスト プラクティス

  • チーム間で共有する予定の場合は、再利用可能なワークフローを 1 つのリポジトリに一元化します。
  • ブランチまたはタグを使用してワークフローのバージョンを設定し (たとえば、 @v1を使用)、必要に応じて変更を簡単にロールバックできるようにします。
  • 入力とシークレットを明確に文書化します。 再利用可能なワークフローは、多くの場合、入力とシークレットに依存します。 チームは、使用する情報を把握する必要があります。
  • いくつかの手順のみを再利用する必要がある場合は、完全なワークフローを作成するのではなく、再利用可能なワークフローと複合アクションを組み合わせます。

再利用可能なワークフローは、任意のエンジニアリング チームで一貫性を強制し、重複を減らし、DevOps プラクティスをスケーリングするための強力な方法です。 単一のリポジトリ、マイクロサービス、オープンソース ライブラリのいずれを管理する場合でも、再利用可能なワークフローによって自動化を簡素化できるため、CI/CD はより高速で、よりクリーンで、管理しやすくなります。

ワークフロー テンプレートをカスタマイズする

このモジュールの冒頭では、開発者のチームに CI を設定する必要があるシナリオを検討しました。 Node.js テンプレートは優れたスタートですが、チームの要件に合わせてカスタマイズする必要があります。 異なるバージョンの Node.js と異なるオペレーティング システムを対象にする必要があります。 また、ビルドとテストの手順を個別のジョブにする必要があります。

カスタマイズされたワークフローの例を次に示します。

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

この例では、複数のオペレーティング システムと言語バージョンでテストするための ビルド マトリックス を構成します。 このマトリックスでは、Node.jsの各バージョンとペアになったオペレーティング システムごとに 1 つずつ、4 つのビルドが生成されます。

4 つのビルドとそのテストによって大量のログ データが生成されます。 すべてを整理するのは難しいかもしれません。 次のサンプルでは、テスト ステップを専用のテスト ジョブに移動します。 このジョブは、複数のターゲットに対してテストします。 ビルドとテストの手順を分離すると、ログ データの操作が簡単になります。

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true