導入：なぜCI/CDの共通化が重要なのか
多くのプロジェクトを抱える現場では、各リポジトリに似たようなYAMLファイルが散乱しがちです。「特定のライブラリの脆弱性が見つかったので、全リポジトリのCI設定を修正する」といった作業が発生した際、手作業で修正するのは非常に非効率ですし、修正漏れのリスクも伴います。Reusable WorkflowsやComposite Actionsを活用することで、CI/CDロジックを「DRY（Don’t Repeat Yourself）」に保ち、運用コストを劇的に下げることが可能になります。
基礎知識：Reusable WorkflowsとComposite Actionsの違い
これらはどちらもCI/CDの共通化に役立ちますが、役割が異なります。
Reusable Workflows: 別のリポジトリからワークフロー全体を呼び出す機能です。ジョブ単位やワークフロー単位で呼び出せるため、大規模なCIパイプラインの標準化に適しています。
Composite Actions: 複数のステップを一つのアクションとしてまとめる機能です。シェルスクリプトやCLIコマンドの実行など、特定の「手順」をパッケージ化するのに適しています。
実装：Reusable Workflowsの作成例
まずは、共通化したい処理を別のリポジトリ（例: .github/workflows/reusable-test.yml）に作成します。
サンプルプログラム：再利用可能なワークフロー
以下は、Node.jsアプリケーションのテストを共通化するReusable Workflowの例です。
.github/workflows/reusable-test.yml
name: Reusable Test Workflow
on:
workflow_call: # 呼び出しを許可する設定
inputs:
node-version:
required: true
type: string
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
呼び出し側の実装
呼び出し側（各プロジェクトのリポジトリ）では、以下のように記述します。
.github/workflows/main.yml
jobs:
call-workflow:
uses: my-org/shared-workflows/.github/workflows/reusable-test.yml@main
with:
node-version: ’20’
応用・注意点：現場での運用ポイント
バージョン管理の徹底
Reusable Workflowを呼び出す際、ブランチ名（mainなど）を指定すると、修正が即座に全プロジェクトに反映されます。破壊的な変更を避けるため、本番環境では必ずタグ（@v1.0.0など）でバージョンを固定することを強く推奨します。
シークレットの受け渡し
Reusable Workflowにシークレットを渡す場合は、呼び出し側のワークフローで secrets: inherit を指定するか、個別にマッピングする必要があります。権限の最小化を意識し、必要なシークレットのみを渡すようにしましょう。
Composite Actionsの使い所
もし、特定のステップ（例：自社独自のセキュリティスキャン手順）だけを共通化したい場合は、Composite Actionsの方が軽量で扱いやすいです。目的に応じてこれらを使い分けることで、保守性の高いCI/CD環境を構築してください。
コメント