自動検査と自動配備
main に入った変更は、誰がサーバーに置いているのでしょうか
検査から配備まで、自動処理が担当する範囲を見てみましょう。
01リスク
手順を忘れそう
配備の手間と抜け検査してアプリを作って、サーバーへ。毎回手作業だと抜けそうです。
02対策
手順を自動で進める
合図の後は自動処理Actionsに手順を任せます。手動開始の方式では、担当者の合図で動きます。
03効果
不合格なら止まる
検査で問題を止める配備前の検査で不合格になった変更は、サーバーへ進みません。
04残る注意
使い方は人が確認
成功と業務確認を分ける更新に成功したら、私が業務の流れを試します。本番公開はその後ですね。
更新を始めると、何が自動で進むのか
GitHub Actions は、用意した手順を自動で実行する仕組みです。5slabでは、検査、配備用のアプリの作成、データベースの構造更新、サーバーへの反映、稼働確認の順に進めます。manual方式は人の合図、auto方式は対象ファイルの main への反映をきっかけに起動します。
自動検査とステージング配備の流れ
- 止まる経路
各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
業務フロー図「自動検査とステージング配備の流れ」。レーン4本、工程11個。 【レーン（担当）】（左から右） - 開発者: 変更を提出・確認 - GitHub: 台帳とイベント検知 - GitHub Actions: 自動化の作業場 - stg 環境: リハーサル用サーバー 【図の符号】破線=止まる経路 【工程】（上から下へ。担当 → 工程名） ── フェーズ: 検知 ── 1. 開発者: PR を main へ squash マージ〔開始・終了〕（変更を統合） 2. GitHub: 設定に応じて開始（人の合図 / main更新） 3. GitHub Actions: ワークフローが起動（app-deploy 実行） ── フェーズ: 検査 ── 4. GitHub Actions: 型検査とテストは合格？〔分岐〕（必須ゲートの確認） いいえ → 中止して通知（stg は元のまま）（破線） はい → 配備用にビルド（コンテナイメージ） 5. 開発者: 中止して通知（stg は元のまま）〔開始・終了〕（安全に停止） ── フェーズ: 配備 ── 6. GitHub Actions: 配備用にビルド（コンテナイメージ）（荷物を梱包） 7. GitHub Actions: DB の移行（migrate）（台帳の更新） 8. stg 環境: stg へ配備（サーバーへ配置） 9. GitHub Actions: 稼働確認（smoke）は OK？〔分岐〕（起動テスト） いいえ → 失敗を通知（破線） はい → stg 反映完了・確認済み候補を記録 10. 開発者: 失敗を通知〔開始・終了〕（開発者が確認） 11. stg 環境: stg 反映完了・確認済み候補を記録〔開始・終了〕（stg-r<run>a<attempt>）
検査で止まるのは、安全装置
型検査はプログラムの値の扱いなどが合っているか、テストは決めた操作が期待どおり動くかを調べます。必要な検査が設定されていない場合も止めます。アプリの作成（build）に成功してから、データベースの構造更新（migrate）、配備（deploy）と進むため、buildで失敗した段階ではデータベースは変更されません。
配備処理は、決められた main の実行だけに一時的な操作権限を渡す仕組みを使います。長く使える秘密鍵を保存せずに済みます。公開範囲も配備前後に検査します。ただし、自動検査が調べる範囲には限りがあるため、最後に依頼者が画面や業務の流れを確かめます。
失敗した場所で、対応は変わります
配備前の検査で止まった場合と、データベース更新やサーバー切替の途中で失敗した場合は、影響が異なります。担当者が実行記録と現在の状態を調べ、直してから再実行します。失敗を見て同じ操作を繰り返さないでください。
stg への反映は、manual と auto
manual（手動開始）は「検証環境を更新して」という依頼を受けて、担当者が反映する版を指定して起動します。その後の検査や配備は自動です。auto（自動開始）は対象ファイルの変更が main に入ると起動します。どちらも、起動しただけでは更新完了ではありません。
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表「stg 配備ポリシーの比較」。2列 × 4行。 【列】 1. manual（手動開始）（人の合図で更新） 2. auto（自動開始）（main 更新で即反映） 【比較】（観点ごとに） ■ stg が更新されるとき - manual（手動開始）: /git stg の実行時 / 人がコマンドで指示 - auto（自動開始）: 対象ファイルの main push 時 / 変更が入ると即座に起動 ■ 起動するもの - manual（手動開始）: 人（SHA を固定して起動） / 反映する版を明示 - auto（自動開始）: GitHub Actions / イベントで自動実行 ■ land のあとの案内 - manual（手動開始）: 未反映 PR の件数と経過時間を案内 / stg 反映の要否を確認 - auto（自動開始）: 実行と候補記録の完了を確認 / 重複した手動起動を抑止 ■ 向いている場面 - manual（手動開始）: Actions を節約・まとめて確認したい / universal の既定運用 - auto（自動開始）: 小さく頻繁に反映したい / スピード重視の開発 【観点】 - 共通の安全ルール: manual（手動開始） / auto（自動開始）
確認済み候補と、手動配備の限界
配備と自動検査が成功すると、公開に使える版が「確認済み候補」として記録されます。これは人が業務確認を済ませたという意味ではありません。担当者は候補の番号と検証用URLを伝え、依頼者がその版を試します。自動処理の外で管理者が個別に配備したものは、候補の記録がなく本番昇格に使えません。
押さえておきたい用語
- GitHub Actions
- ワークフロー
- CI / CD
- stg（検証環境） この用語の解説を読む
- 必須ゲート
- deploy-policy