こんにちは。DevOpsの世界へようこそ。
現場で働いていると、こんな経験はありませんか？「新しいマイクロサービスを作るたびに、CI/CDの設定ファイルをコピペして、微妙に修正して……気づけば組織内に何十もの『似ているけれど微妙に違う』YAMLファイルが散らばっている」という状況です。
これはエンジニアにとっての「技術的負債」の温床です。今日は、GitHub Actionsの「再利用可能なワークフロー（Reusable Workflows）」を使って、この悪夢を終わらせる方法を伝授します。これをマスターすれば、あなたのチームの生産性は劇的に向上し、パイプラインの管理は驚くほど楽になります。
—
なぜ「再利用」が重要なのか？
CI/CDの役割は「自動化」ですが、その設定自体が属人化・複雑化しては本末転倒です。再利用可能なワークフローを使う最大のメリットは、「CI/CDの標準を中央集権的に管理できる」ことにあります。
- メンテナンス性: 修正は1箇所だけ。全リポジトリに即時反映。
- 標準化: 誰が作っても同じ品質のテストとデプロイを強制できる。
- DRY原則: “Don’t Repeat Yourself”（繰り返すな）。設定ファイルを「資産」として使い回します。
—
ステップ1：共有用リポジトリを用意する
まずは、組織内で共通化したいワークフローを保存する専用リポジトリを作ります。仮に `org-ci-templates` としましょう。
このリポジトリの `.github/workflows/` ディレクトリ配下に、汎用的なワークフローを作成します。
`.github/workflows/test-template.yml`
name: Reusable Test Workflow
on:
workflow_call: # これが「再利用可能」にする魔法のキーワードです
inputs:
node-version:
required: true
type: string
default: ’20.x’
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 }} # 受け取った変数を使用
- run: npm install
- run: npm test
—
ステップ2：各アプリケーションから呼び出す
次に、実際に開発しているアプリケーションリポジトリから、先ほど作ったテンプレートを呼び出します。
`.github/workflows/ci.yml`
name: CI
on: [push]
jobs:
call-shared-test:
# 別のリポジトリからテンプレートを読み込む
uses: my-org/org-ci-templates/.github/workflows/test-template.yml@main
with:
node-version: ’18.x’ # 呼び出し元で環境に合わせて柔軟に変更可能
これだけで、アプリケーション側のYAMLはわずか数行で済みます。もしテスト手順が変わっても、テンプレート側を1回直すだけで、全アプリのCIが最新化されるのです。
—
現場で役立つ「極限のハック」3選
初心者から一歩先へ進むために、次のテクニックを覚えておいてください。
1. シークレットの継承:
`secrets: inherit` をワークフロー呼び出し時に追加すると、呼び出し元のリポジトリにあるGitHub Secretsを、テンプレート側でそのまま使えます。デプロイキーの管理が非常に楽になります。
uses: my-org/org-ci-templates/.github/workflows/deploy.yml@main
secrets: inherit
2. 命名規則の強制:
「どのリポジトリから呼び出されても同じ挙動」にするため、テンプレート側で環境変数やプレフィックスを固定しましょう。チーム内で「`ci-.yml` は共有テンプレートを使う」といったルールを設けるだけで、心理的な安全性は高まります。
3. バージョン管理:
`@main` で呼び出すとテンプレートの更新が即時反映されますが、安定性を重視するなら `@v1.0.0` のようにタグで固定しましょう。本番環境へのパイプラインはタグ運用、開発環境はメインブランチ運用と分けるのが玄人のやり方です。
—
最後に：自動化の先にあるもの
CI/CDの設定をDRYに保つことは、単なる「コードの整理」ではありません。それは、あなたのチームが「アプリケーションの価値向上」という、本来注力すべき場所にリソースを集中させるための準備です。
最初は難しく感じるかもしれませんが、まずは「毎度書いているテストの工程」を一つ、このテンプレートに書き出してみてください。その瞬間から、あなたの毎日は劇的に楽になり、チームのメンバーは「あの設定、どこに書いたっけ？」と悩むことから解放されます。
さあ、次はあなたの番です。最高のパイプラインを構築し、開発を加速させていきましょう！何か詰まったら、いつでも聞きに来てくださいね。応援しています。