GitHub Actions「Composite Actions」でCI/CDをコードとして洗練させる：DRY原則の究極形
「またYAMLのコピペか……」。
CI/CDパイプラインを運用していると、誰もが一度は感じる絶望だ。数十のリポジトリを持つマイクロサービス環境で、同じ認証処理やキャッシュ設定を書き散らすのは、技術的負債の養殖に他ならない。
GitHub Actionsの真価は、単なるタスクランナーではない。「CI/CDそのものを、テスト可能なソフトウェアとして設計できる」点にある。本稿では、Composite Actionsを活用し、チームの生産性を劇的に向上させるための「設計思想」と「現場のハック」を伝授する。
—
1. なぜ「Composite Actions」なのか？
`Reusable Workflows`（`workflow_call`）も強力だが、Composite Actionsは別格だ。コンテキストを完全に独立させ、「一つのステップ」としてシームレスに組み込める。
- Reusable Workflows: ジョブ単位の再利用。コンテキスト（`needs`など）の受け渡しが煩雑。
- Composite Actions: ステップ単位の再利用。シェルスクリプトの延長で書け、引数の制御も容易。
現場のベストプラクティス：ディレクトリ構成
共通化されたアクションは、専用の組織リポジトリ（例: `my-org/actions`）で管理せよ。これを全リポジトリから参照させるのが、DevOpsスケーリングの定石だ。
.
├── setup-node-env/ # 共通アクション名
│ ├── action.yml # 定義ファイル
│ └── setup.sh # 複雑なロジックを分離（可読性向上）
└── …
—
2. 破壊的生産性を生む「Composite Actions」実装例
単にコマンドを並べるのは素人だ。プロは「入力のバリデーション」と「失敗時のハンドリング」を組み込む。
`action.yml` のベストプラクティス例
name: ‘Custom Setup Node’
description: ‘Node.js環境を最適化してセットアップする’
inputs:
node-version:
description: ‘Node version’
default: ’20’
required: false
runs:
using: “composite”
steps:
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
cache: ‘npm’
- name: Verify Environment
shell: bash
run: |
# 実行時のバリデーションを組み込む
if [ -z “$(which npm)” ]; then
echo “::error::Node.js setup failed”
exit 1
fi
echo “Node.js $(node -v) is ready.”
ここがプロの視点:
`run`コマンドをYAMLに直書きせず、`script/`ディレクトリにシェルスクリプトを追い出せ。シェルはLint（ShellCheck）が効く。YAMLの中に埋め込むと、エディタの補完も効かず、複雑な条件分岐が地獄と化すからだ。
—
3. 生産性を加速させる「隠れたハック」
① 開発スピードを上げるショートカットと設定
- GitHub CLI (`gh`): CI/CD設定の確認にブラウザを使うな。
- `gh run list –limit 5` で直近の失敗を即座に確認。
- `gh run watch
` でターミナルからログをライブ監視。 - VS Code Extension: 「GitHub Actions」拡張機能を入れろ。YAMLのスキーマ補完が効かない開発環境は、目隠しで高速道路を走るようなものだ。
② チーム開発の「暗黙知」を排除するルール
- Semantic Versioningの徹底: アクションを呼び出す際は `v1` ではなく、`v1.2.3` と固定せよ。共通ライブラリの更新で全サービスが同時に死ぬ事故を防ぐ必須の作法だ。
- `shell: bash` のデフォルト化: OS依存を排除するため、必ず `shell: bash` を指定し、`set -euo pipefail` をスクリプトの冒頭に置くこと。
—
4. チームへの導入・運用ロードマップ
1. 「コピペの温床」を見つける: 全リポジトリの `.github/workflows/` を検索し、3回以上重複している処理を特定する。
2. 専用リポジトリの作成: `my-org/github-actions` を用意する。
3. ドキュメントはREADMEに書くな: `action.yml` の各入力項目に `description` を丁寧に書け。それがGitHub上でそのまま仕様書になる。
—
最後に：CI/CDは「プロダクト」である
多くのエンジニアがCI/CDを「付随する雑務」と考えている。しかし、CI/CDは開発者体験（DX）を決定づける最も重要なプロダクトだ。
Composite Actionsを使いこなし、パイプラインを「疎結合」かつ「疎結合」に保つこと。重複したYAMLを削除し、共通化されたアクションを呼び出す一行を見たとき、そのパイプラインは「保守されるべきコード」から「資産」へと昇華する。
さあ、今すぐ不要なYAMLを削除し、最高にDRYなパイプラインを構築してくれ。君のチームの生産性は、間違いなく一段上のフェーズへ到達するはずだ。