②GitHubActions_応用編_後半.pptx

うさうさ研修工房 講座シリーズ VOL.4（後半） GitHub Actions 応用編 本番運用とアクションの自作 Environments・カスタム Action・Reusable Workflowsで一段上の運用へ 面白きこともなき世を面白く🐰 2026年7月 — うさうさ研修工房

00 / この回のゴール この回で身につけること • デプロイ前に人の目を挟む「承認フロー」を、 Environmentsで組めるよ うになる ① 承認フロー • Composite／JavaScript／Dockerという3種のカスタムActionの使い分け を理解する • Reusable Workflowsで、複数リポジトリの重複を減らせるようになる ② • 本番運用に必要な「監査証跡」「同時実行制御」の考え方を知る 自作Action ③ 再利用 workflow 出典：GitHub Docs「GitHub Actions documentation」 2

01 / デプロイ保護 Environmentsとは何か • WHY 本番デプロイが「うっかり」実行されてしまうと、被害が大きい Push • WHAT Environmentsは、staging・productionなどのデプロイ先ごとに保護 ルールとSecretsを紐づける仕組み • できること 必須レビュアーの設定（最大6名）／待機タイマー／デプロイ可能 ブランチの制限 Staging デプロイ 承認待ち POINT Environmentに紐づくSecretsは、保護ルールを通過するまでジョブから一切 アクセスできません。 出典：GitHub Docs「Deployments and environments」「Managing environments for deployment」 Production デプロイ 3

01 / HOW 承認フローを実際に組む • HOW Settings → Environments で環境を作成し、Required reviewersを設定 する deploy.yml jobs: • ジョブ側は environment: production の1行を追加するだけで保護ルールが適 用される • 「Prevent self-review」を有効にすると、デプロイした本人が自分で承認するこ とを防げる deploy: runs-on: ubuntu-latest environment: name: production url: https://example.com steps: - run: ./deploy.sh environment: の1行だけで保護ルールが有効に 出典：GitHub Docs「Deploying with GitHub Actions」 4

02 / 自作アクション カスタム Actionの3種類 • WHY 同じ処理を何度もコピペしていると、修正のたびに全リポジトリを回る羽 目になる Composite • WHAT Composite／JavaScript／Dockerの3種類から選んで自作できる 既存stepの束ね。コード不要 • 選び方 まずComposite→複雑なロジックはJavaScript→特殊な実行環境が要 るならDocker JavaScript 起動が速い。ロジック処理向き Docker 環境ごと固定。起動はやや遅い 出典：GitHub Docs「About custom actions」 5

02 / HOW Composite Actionを作ってみる • HOW .github/actions/セットアップ名/action.yml に、まとめたいstepsを書く • 呼び出し側は uses: ./.github/actions/セットアップ名 の1行に集約される • 複数リポジトリで同じ処理を使う場合は、別リポジトリに切り出して参照する形 に発展させられる action.yml name: 'Setup Node Project' inputs: node-version: default: '20' runs: using: composite steps: - uses: actions/setup-node@v4 with: node-version: ${{ inputs.node-version }} 出典：GitHub Docs「Metadata syntax reference」 6

03 / 再利用ワークフロー Reusable Workflowsで全体を再利用する • WHY Composite Actionは「steps単位」の再利用。job全体・パイプライン全体 を再利用したい場面もある • WHAT workflow_call トリガーを持つワークフローは、他のワークフローから 呼び出せる • 使い分け steps単位ならComposite Action、job／パイプライン単位なら Reusable Workflow 共通 workflow 出典：GitHub Docs「Reusing workflows」 7

03 / HOW 呼び出し側と呼び出される側 • 呼び出される側 on.workflow_call でinputs／secretsを定義しておく • 呼び出す側 uses: に対象workflowのパスとバージョンを指定するだけ • Secretsは明示的に渡す必要があり、これも権限最小化の一部として機能する caller.yml jobs: build-and-push: uses: myorg/actions/ .github/workflows/ build.yml@v1 with: image-name: my-app secrets: deploy_key: ${{ secrets.KEY }} 出典：GitHub Docs「Reusing workflows」 8

04 / 本番運用 本番運用に必要な心構え • 監査証跡 Environmentsは「誰が」「いつ」「何を」承認したかを記録として残す • 同時実行制御 concurrencyで、同じ環境への同時デプロイを防ぐ • タイムアウト 承認待ちのワークフローは最大35日で自動キャンセルされる点 に注意 「動いている」から「安全に運用されている」へ 出典：GitHub Docs「Deployments and environments」「Reviewing deployments」 9

05 / 総合演習 自分のプロジェクトに当てはめる staging／productionのEnvironmentsを作れるか 重複しているstepsをComposite Actionにできそうか洗い出す 複数リポジトリで共通化できそうな処理をReusable Workflow化する production環境にRequired reviewersを設定できているか 出典：本教材セクション1〜4のまとめ 応用編は「知る」より 「当てはめる」が本番 10

WRAP-UP まとめと次の一歩 • Environmentsで、本番デプロイに人の目を挟む仕組みを作る • 重複コードは、まずComposite Actionから再利用化を検討する • job／パイプライン単位の再利用は、Reusable Workflowsが担う • 「動く」の先にある「安全に運用され続ける」を意識する うさうさ研修工房 面白きこともなき世を面白く🐰 出典：GitHub Docs「Actions」 11