GitHub Actions「再利用可能ワークフロー」でCI/CDをコードの資産に変える：DRY原則の究極形
こんにちは。テックリードとして日々数多のCI/CDパイプラインを眺めていますが、正直に言おう。「各リポジトリにコピー＆ペーストされた数千行のYAML」ほど、組織の成長を阻害する負債はない。
開発者がビジネスロジックではなく「YAMLの修正」に追われる状況は、DevOpsの敗北だ。今日は、GitHub Actionsの「再利用可能なワークフロー（Reusable Workflows）」を使い倒し、組織全体のパイプラインを「メンテナンスフリー」にするための実戦的戦術を授ける。
—
1. なぜ「コピー＆ペースト」が死を招くのか
リポジトリごとにCI定義を持つと、言語のバージョンアップやセキュリティスキャンの追加といった「全社的な変更」が発生した際、あなたは数十のリポジトリにPRを投げ続けることになる。これは退屈な作業という以上に、「設定の不整合」による重大なインシデントの温床だ。
再利用可能なワークフローは、単なるコードの共通化ではない。「CI/CDをインフラストラクチャとしてコード化（IaC）し、組織の標準規格として配布する」ための戦略的基盤である。
—
2. 構築の鉄則：標準化のためのディレクトリ構造
まずは、CI定義を集約する専用リポジトリ（例: `org-workflow-templates`）を作成せよ。ディレクトリ構成は以下のように「責務」で分けるのが鉄則だ。
.github/workflows/
├── build-node.yml # Node.js標準ビルド
├── docker-publish.yml # コンテナビルド＆Pushの共通規格
└── security-scan.yml # 全プロジェクト強制の静的解析
実践的な「再利用可能ワークフロー」の構成例
`build-node.yml` の中身を覗いてみよう。`inputs`で柔軟性を担保しつつ、`secrets`の取り扱いを標準化する。
.github/workflows/build-node.yml
name: Reusable Node.js Build
on:
workflow_call:
inputs:
node-version:
description: ‘Node.js version’
default: ’20.x’
type: string
secrets:
NPM_TOKEN:
required: false
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
registry-url: ‘https://registry.npmjs.org’
- run: npm ci
- run: npm run build
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
—
3. チーム開発を加速させる「呼び出し側」の洗練
使う側のリポジトリは、驚くほどシンプルになる。これが開発者の生産性を最大化する。
.github/workflows/ci.yml (各アプリリポジトリ)
jobs:
call-workflow:
uses: my-org/org-workflow-templates/.github/workflows/build-node.yml@main
with:
node-version: ’20.x’
secrets:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
ここで差がつく！プロのテクニック：
- バージョニングの徹底: `@main` を使ってはいけない。本番環境では `@v1` や `@v1.2.0` のようなGitタグを指定し、破壊的変更が予期せぬタイミングで走るのを防ぐこと。
- マトリックス戦略: `strategy.matrix` と組み合わせて、複数のOSやランタイムバージョンに対して一括でテストを実行させろ。
—
4. 現場で震えるほど役立つ「ハック＆ツール」
絶対入れるべきGitHub用ブラウザ拡張
- [Octotree](https://www.octotree.io/): リポジトリのディレクトリ構造を左サイドバーに表示。大規模なCIテンプレートを修正する際、これがないと迷子になる。
- [GitHub Actions Extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions): エディタ内でワークフローの実行状況を確認できる。わざわざブラウザを開く時間は無駄だ。
隠れたキーボードショートカット
- `t` キー: ファイル検索。テンプレートリポジトリ内の巨大なYAMLを探すとき、これを知らないエンジニアは損をしている。
- `w` キー: ワークフロー実行ページへ直行。CIが落ちた瞬間に叩け。
—
5. 組織への浸透：チーム運用のルール
1. 「CIの変更」をPRで強制する: 再利用ワークフローに変更を入れるときは、必ず影響を受ける（依存している）リポジトリのCIがパスすることを確認するスクリプトをCIに含めろ。
2. テンプレートの「強制」と「許容」: 全社ルールは必須化しつつ、個別のプロジェクト固有のステップは `jobs` の前後に `composite actions` を差し込めるような柔軟なインターフェース（`pre-build` や `post-build` のスクリプト注入など）を設ける。
3. ドキュメントはREADMEに書くな: ワークフローの `on.workflow_call` 内に `description` をしっかり記述せよ。GitHubのUI上で各Inputの意味がツールチップとして表示され、開発体験（DX）が劇的に向上する。
—
最後に：なぜこれを行うのか
CI/CDをDRYにすることは、単なるコードの整理整頓ではない。「組織のベストプラクティスを、常に最新かつ安全な状態で全チームに即座に配布する」という、DevOpsの究極の目的を達成するための手段だ。
今日から、コピー＆ペーストを止めよう。あなたのリポジトリは、もっと洗練された場所になれるはずだ。何か詰まったら、いつでも聞け。現場の知見をさらに叩き込んでやる。