01/ 03Git・GitHub
自動テストと自動配備
マージを引き金に、検査・ビルド・stg 配備まで仕組みが運ぶ（GitHub Actions）
main に合流した変更は、GitHub Actions が自動でテスト・ビルドを通り、リハーサル環境（stg）まで運ばれます。人がやるのはマージまで ── 途中の検査で落ちれば配備されず、環境は元のまま守られます。
- マージが自動配備の引き金になる
- テストという関所を通らなければ配備されない
- 本番へはもう一段、人の承認で昇格する（次章）
マージした変更はどう届けられる？
5SLAB では、配備を人の手作業にしていません。手順書どおりに人が操作する方式は、抜け漏れや「担当者しかできない」を生みがちだからです。仕組みに任せると配備は日常の作業になり、小さな変更を頻繁に安全に届けられるようになります。
各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
業務フロー図「GitHub Actions で自動配備」。レーン4本、工程10個。 【レーン（担当）】（左から右） - 開発者: あなた / レビュアー - GitHub: リモートリポジトリ - GitHub Actions: CI / CD（自動実行） - stg 環境: リハーサル環境 【工程】（上から下へ。担当 → 工程名） ── フェーズ: マージ ── 1. 開発者: PR を承認して main へマージ〔開始・終了〕 2. GitHub: main の更新を検知 ── フェーズ: 検査 ── 3. GitHub Actions: ワークフローが自動起動 4. GitHub Actions: テスト＆型チェックは合格?〔分岐〕（品質の関所） はい → 配備用にビルド いいえ → デプロイ中止・原因を通知 5. 開発者: デプロイ中止・原因を通知〔開始・終了〕（環境は元のまま） 6. GitHub Actions: 配備用にビルド（配布できる形に固める） ── フェーズ: 配備 ── 7. stg 環境: stg 環境へ反映 8. GitHub Actions: 公開後の稼働チェック OK?〔分岐〕（ちゃんと動くか確認） はい → stg 反映完了・確認できる状態に いいえ → 自動で切り戻し・通知 9. GitHub Actions: 自動で切り戻し・通知〔開始・終了〕（前の版に戻す） 10. stg 環境: stg 反映完了・確認できる状態に〔開始・終了〕（実物を確かめられる）
止まるのは失敗ではなく安全装置
テストで止まって配備されない ── これは事故ではなく、壊れたものが配備される前に安全装置が働いた状態です。環境は元のまま保たれます。直してもう一度マージすれば、何度でもやり直せます。
押さえておきたい用語
- GitHub Actions
- ワークフロー
- CI / CD
- スモークテスト
- ロールバック