GitHub Actions+Release Notes活用デプロイフロー

• slidict.io のデプロイメント全体像と自動化フローの要点を整理

• GitHub Actions での自動化、Conventional Commits によるリリースノート作成を解説

• AKS への継続的デプロイと3環境（Preview, Staging, Production）での段階的デプロイを説明

• 各環境のデプロイ条件: Previewは main ブランチ push 时、Stagingは PR に staging ラベル、Production は GitHub Release 作成時に自動デプロイ

• デプロイフロー概要と GitHub Actions ワークフローの全体像、Conventional Commits の設定とリリースノート生成の流れを把握する

• Docker イメージビルドの手順と AKS デプロイメントの詳細、Release Tasks 機構を連携させる運用を理解する

• 環境別設定、監視・通知、ベストプラクティスを用いた安定運用と迅速なデリバリーを実現するための実践ポイント

• デプロイフロー概要

• GitHub Actions ワークフロー

• Conventional Commits setup

• リリースノート生成

• Docker イメージビルド

• AKS デプロイメント詳細

• Release Tasks 機構

• 環境別設定

• 監視・通知

• ベストプラクティス

• デプロイの全体フローを示すビジュアル要素で、Git Push から Live環境までの工程を連携させている

• 主なステップは、Git Push → GitHub Actions → Docker Build → AKS Deploy → Live環境の到達

• 各ステージは連携しており、継続的デリバリ(CD)パイプラインとして動作することを強調した内容

• 3つのデプロイ環境には、それぞれ独立したAKSクラスタ設定が適用され、段階的なテストと検証が可能です

• Preview は main ブランチへの push 时にトリガーされ、開発中の最新機能を実機で確認します

• Staging は PR に staging ラベルを付与することでリリース前の最終検証を実施します

• Production は GitHub Release 作成時にユーザー向けの本番環境としてデプロイします

各環境は独立した AKS クラスタ設定を持ち、段階的なテストと検証が可能

• プロジェクトの基本ルールとして、プレフィックスは feat:, fix:, docs:, style:, refactor:, test:, chore: などを使用する

• 言語は日本語、50文字程度を目安に記述し、語尾に句点を付けない

• 例として feat:, fix:, docs: のコミットが示され、自己紹介欄追加・エラーハンドリング修正・デプロイ手順更新を含む

• 効果: コミット履歴が解析され自動でリリースノートを生成できる

💡 効果: コミット履歴がしっかり解析でき、自動でリリースノート を生成！

• main ブランチの push 时に自動実行される GitHub Actions で CHANGELOG を生成

• fromTag と toTag の範囲で、すべてのコミットを対象にして自動作成、マージコミットは除外設定

• 自動除外対象は「Merge pull request」「Merge branch」などのマージ関連コミット

• これにより、ユーザー向けリリースノートが自動生成されることを示す

自動除外されるコミット: * Merge pull request …​ * Merge branch …​ * その他マージ関連コミット

これにより、ユーザー向けリリースノートが自動生成される

• main-ci ワークフローは main ブランチへの push および手動実行で起動

• ジョブは以下を実行: 1) changelog 自動生成 2) draft release 作成 3) Kroki ダイアグラムサービスのデプロイ 4) Preview 環境へのフルデプロイ

• 実行時間は約 10～15分程度

• なお YAML 定義は on: push: branches: [main] と workflow_dispatch でトリガーされる

• Preview 環境デプロイを含む CI の全体流れを可視化するワークフロー

• イメージタグは 環境-コミットSHA の形式で一意性を確保

• ビルドは層ごとにキャッシュされ、再ビルドを効率化

• DockerHub のプライベートレジストリへ自動でプッシュされる

• イメージタグ: 環境-コミットSHA で一意性を確保

• ビルドキャッシュ: 層ごとにキャッシュされ、効率化

• DockerHub: プライベートレジストリへ自動プッシュ

• 証明書管理(cert-manager)を適用し、秘密情報・クラスター発行者・証明書を準備する

• Redis のデプロイを実行する

• Chrome ブラウザサービスをデプロイしてスクリーンショット用環境を用意する

• Sidekiq Workerをデプロイしてバックグラウンドジョブ処理を有効化する

• データベースマイグレーションが完了するまで待機し、完了条件を 120 秒 timeout で監視する

• 初回デプロイ時のみ実行される Release Tasks の実行を準備

• メインアプリケーションをデプロイし、Ingress を更新するためのマニフェストを適用

• Horizontal Pod Autoscaler のデプロイを実行して自動スケーリングを有効化

• 一度だけ実行したいタスクを管理する機構で、実行履歴は release_tasks テーブルで管理される

• 二重実行防止は executed_at で判定する設計

• 手動実行は make release-tasks コマンドで可能

• 例: BackfillFeatureFlag が全ての FeatureFlag を enabled: true に更新する

• 実行履歴: release_tasks テーブルで管理

• 二重実行防止: executed_at で判定

• 手動実行: make release-tasks コマンドで可能

• GitHub Release をトリガーに production 用 CI を実行するワークフローの要約

• types: [released] で Draft Release が Publish されたときに実行される

• deploy_production ジョブは別ファイル ./.github/workflows/call-deploy-ci.yml を使用し、環境情報を引き渡す

• 環境設定: ENVIRONMENT=production、ENVIRONMENT_URL=https://slidict.io、POD_PREFIX=slidict-io

• 重要: Draft Release から Published Release へ変更されたタイミングで実行される点に注意

重要: Draft Release → Published Release に変更されたとき

• PR の staging ラベルが付与された時にのみトリガーされる staging-ci ワークフロー

• on: pull_request_target の main ブランチでラベル追加・同期・再オープンを検知

• deploy_staging ジョブは条件 contains(…​) により label が staging の場合に実行

• 用途: 本番リリース前の最後の検証環境を構築・検証するためのワークフロー

用途: 本番リリース前の最後の検証環境

• コード開発は Conventional Commits で記述

• main ブランチへ merge → main-ci 自動実行、Changelog 生成、Draft Release 作成、Preview 環境へデプロイ

• オプションの Staging 検証 → staging ラベル付与、staging-ci 実行、staging.slidict.io で最終検証

• GitHub Release 公開 → production-ci 自動実行、production 環境へデプロイ

• ユーザーが新機能を利用可能になるまでの完了までを示す

• ERB テンプレートで環境別設定を制御し、展開対象を明確化する

• 自動実行スクリプト manifests/expansion.rb が production 環境用の secret.yml を適用

• 展開対象は Azure Service Principal 認証情報／DNS 設定／各環境別リソース

• Deployment の replicas は環境変数 PRODUCTION_REPLICAS で動的制御

• 環境ごとの設定を統一して Kubernetes Manifests を柔軟に管理する

• 環境ごとに kubeconfig はすべて AKS Slidict を指す

• Pod レプリカ数が Preview=2、Staging=3、Production=5 の違い

• HPA の最小/最大値が 2/10、3/15、5/30 と環境で異なる

• リソースリミットは Preview=small、Staging=medium、Production=large

• DNS のFQDNが Preview/Stagingは *.svc.cluster.local、Productionのみ本番FQDN

• 監視は Preview/Stagingが基本、Productionは Prometheus + Grafana を使用

• Nagios による監視設定を要約

• 監視項目: healthz (/healthz), sns_login (/healthz/sns_login), https (https://slidict.io を12時間間隔) を監視

• 設定: debug_level 2048、debug_verbosity 2、configmap docker/nagios/nagios.cfg

• 注意: ホスト名は azure-kubernetes 内のサービス DNS を使用し、*.svc.cluster.local が該当

• 目的: アプリ起動・SNS認証・外部 HTTPS の健全性を定期確認

注意: ホスト名は azure-kubernetes 内のサービス DNS を使用 * ✅ *.svc.cluster.local

• Prometheus Operator を用いて自動スクレイピングを設定

• Alerts により異常を検知し通知をトリガー

• 通知先は Slack や Email など、Grafana のダッシュボードと連携して配信

• Prometheus Operator で自動スクレイピング

• Alert Rules で異常検知

• 通知: Slack, Email など

• slidict.io エディタから図を生成・埋め込み可能

• 完全クローズド環境で実行（外部API呼び出しなし）

• AKS クラスター内で kroki の各デプロイメントを稼働

• mermaid/bpmn/excalidraw の図種別をサポートする kroki メインサービスと Ingress の構成

• manifests/azure-kubernetes/kroki/ 配下に図種別別デプロイメントと入口設定を配置

• slidict.io エディタから図を生成・埋め込み可能

• 完全クローズド環境で実行（外部API呼び出しなし）

• 開発環境を背景で起動: docker compose up -d

• Rails サーバーをアプリコンテナで起動: docker compose exec app bin/dev

• codex 環境で rspec を実行: RAILS_ENV=codex bundle exec rspec

• 公開資産のキャッシュ対策: public/assets/ を削除後、docker compose restart app

• 重要: public/assets/ が存在するとプリコンパイル済み資産を優先読み込みし、新規アセットが認識されない

重要: public/assets/ が存在するとプリコンパイル済みアセットを読み込み、 動的生成がスキップされるため、新規のアセットが見つからなくなる

• schedules を使用: https://github.com/sidekiq-scheduler/sidekiq-scheduler

• キャッシュからの実行: Redis database 15

• テスト: spec は config/sidekiq_schedule_spec.rb ではなく、実装に組み込む

• schedules を使用: https://github.com/sidekiq-scheduler/sidekiq-scheduler

• キャッシュからの実行: Redis database 15

• テスト: spec は config/sidekiq_schedule_spec.rb ではなく、実装に組み込む

• Redis のマルチデータベース構成で用途別に分離する

• DB 11: Redcord（キー値ストア）、DB 12: ActionCable（リアルタイム通信）、DB 14: キャッシュストア、DB 15: Sidekiq（バックグラウンドジョブ）

• Redis CLI でデータベースを確認する例: redis-cli -n 15 KEYS "*" で Sidekiq のキーを一覧表示

• コード変更時は関連ドキュメントも必ず更新する

• 文書構成の対象は docs/ 配下の各ファイル・セクションを包含する

• Help Articles や シード管理など、ユーザー向け情報の整備を優先する

• Help Articles: docs/seeds/help_articles/ で更新

• シード管理: ユーザー向けの情報は整備が必須

• コミットメッセージが Conventional Commits に準拠していることを確認する

• RSpec テストが全て PASS かを make rspec で検証する

• RuboCop が PASS かを make rubocop で検証する

• Brakeman セキュリティ確認を実施する（docker compose exec base bundle exec brakeman）

• ERB のフォーマットを整える（make htmlbeautifier args='*/.erb'）

• TypeScript/JavaScript のビルドを実行する（yarn build）

• 関連ドキュメントを更新する

• Release Tasks が必要な場合は実装済みであることを確認する

• ☐ コミットメッセージが Conventional Commits に準拠

• ☐ RSpec テストが全て PASS： make rspec

• ☐ RuboCop が PASS： make rubocop

• ☐ Brakeman セキュリティ確認： docker compose exec base bundle exec brakeman

• ☐ ERB フォーマット確認： make htmlbeautifier args='*/.erb'

• ☐ TypeScript/JavaScript ビルド： yarn build

• ☐ 関連ドキュメント更新

• ☐ Release Tasks が必要な場合は実装済み

• コード確認とテストを実施（make rspec, make rubocop）

• 変更をコミット・プッシュ（git add, git commit, git push origin main）

• GitHub Actions が自動実行されDraft Releaseを作成

• Release の稼働状況とクリティカルバグを確認

• GitHub Release を Published に変更 → production-ci が自動実行

• 本番環境へデプロイ完了 🎉

• デプロイ失敗時は、まず GitHub Actions の Workflow ログを確認して原因を把握する

• AKS のポッド状態を確認し、必要に応じてポッドのログを参照して障害箇所を特定する

• ポッドログを確認してエラーメッセージや例外を読み取り、再現手順を整理する

• デバッグモードで再実行するか、Workflow の Run ボタンで再実行して修正箇所を検証する

• 小分けコミット: 1つの PR は複数の小さなコミットで構成

• Conventional Commits: 自動リリースノート生成に必須

• テスト駆動開発: テストなしで main へマージしない

• Preview 環境活用: main-ci で自動デプロイを活用

• Staging 検証: 本番向けの大型変更は staging で徹底テスト

• Release Notes 確認: Draft Release をレビューしてから Published

• Monitoring 監視: 本番デプロイ後の動作確認を必須化

• ドキュメント同期: コード変更とドキュメント更新を同時に実施

1. 小分けコミット: 1つの PR = 複数の小さなコミット

2. Conventional Commits: 自動リリースノート生成に必須

3. テスト駆動開発: テストなしで main にマージしない

4. Preview 環境活用: main-ci で自動デプロイされる

5. Staging 検証: 本番向け大型変更は staging でテスト

6. Release Notes 確認: Draft Release をレビューしてから Published

7. Monitoring 監視: 本番デプロイ後の動作確認は必須

8. ドキュメント同期: コード変更とドキュメント更新は同時に

• CI/CD の現状は main-ci / staging-ci / production-ci の3つのワークフローがあり、それぞれの実行内容と所要時間は以下のとおり。

  • main-ci: Changelog + Docker Build + AKS Deploy、約10～15分

  • staging-ci: Docker Build + AKS Deploy、約8～12分

  • production-ci: Docker Build + AKS Deploy、約8～12分

• 最適化のポイントとして、Docker BuildKit によるレイヤーキャッシュ、並列ジョブ実行（cert, setup_configmap など）、DockerHub へのプッシュによるレジストリ内キャッシュ活用を挙げる。

最適化のポイント: * Docker BuildKit によるレイヤーキャッシュ * 並列ジョブ実行（cert, setup_configmap 等） * DockerHub へのプッシュ（レジストリ内キャッシュ活用）

• 本番環境で問題が起きた場合、以前のイメージへ素早く戻す手順を示す

• まず現在のイメージを確認し、過去のロールアウト履歴を参照して前のバージョンへロールバック

• ロールバック後は、新旧Podの状態を確認し、ログを確認して影響範囲を把握する

• GitHub Releases でも前のバージョンタグから新しい Release を作成することで同様のロールバックを実施可能

GitHub Releases でも可能: 前のバージョンタグから新しい Release を作成

• GitHub Actions Secrets の活用と管理ポイントを整理

• GitHub App 連携用の APP_ID/APP_PRIVATE_KEY、AKS kubeconfig、Azure サブスクリプション、DNS サービスプリンシパル、Docker Hub 資格情報を Secrets に格納

• セキュリティ対策：シークレットはマスク表示、ログ出力なし、PR では利用不可（pull_request_target を活用）

✅ セキュリティ: * すべてのシークレットはマスクされる * ログには出力されない * PR では利用できない（pull_request_target を使用）

• HPA による自動スケールを適用。

• 最小 5、最大 30 のレプリカ数を設定。

• CPU 70%・メモリ 80%の利用率を閾値としてスケーリング。

• 対象デプロイは slidict-io-production。

• よくある質問と回答を整理

• Release Task 再実行: release_tasks テーブルの該当レコードの executed_at を NULL にする

• Preview デプロイ失敗: public/assets/ ディレクトリを削除して再起動

• Staging で本番同様テスト: staging ラベルで PR をデプロイし staging.slidict.io で検証

• Release Notes 手動修正: Draft Release を編集して公開（GitHub UI から）

• Rollback: kubectl rollout undo で前バージョンに戻す

Q: Release Task を再実行したい A: release_tasks テーブルの該当レコードの executed_at を NULL にする

Q: Preview デプロイが失敗した A: public/assets/ ディレクトリを削除して再起動

Q: Staging で本番同様にテストしたい A: staging ラベルで PR をデプロイし、staging.slidict.io で検証

Q: Release Notes を手動で修正したい A: Draft Release を編集して公開（GitHub の UI から）

Q: Rollback したい A: kubectl rollout undo で前バージョンに戻す

• slidict.io のデプロイメントは自動化と段階的デプロイを軸に、Conventional Commits から自動的に Changelog を生成する仕組みを持つ

• Preview → Staging → Production の順次デプロイでリスクを抑え、PR staging ラベル検証→ Release 本番化で安全性を確保

• GitHub Actions, Grafana, Nagios による可視化と、HPA による自動スケーリングで運用を可監視性高く運用

• ロールバック機構で迅速な復旧を実現、DevOps 文化としてコード品質とドキュメント整備を重視

✨ 自動化: Conventional Commits → 自動 Changelog 生成

🚀 段階的デプロイ: Preview → Staging → Production

🔒 安全性: PR staging ラベルで検証 → Release で本番化

📊 可視化: GitHub Actions + Grafana + Nagios

⚡ スケーラビリティ: HPA による自動スケール

🔄 復旧性: ロールバック機構で迅速な復旧

💡 DevOps 文化: コード品質とドキュメント整備が鍵

• GitHub Actions + Conventional Commits + AKS は強力な CI/CD の組み合わせ

• デプロイパイプラインを理解することで、チーム全体の開発効率と品質を向上させる

• 最新版は slidict.io で公開中

• Happy Deploying! 🎉

GitHub Actions + Conventional Commits + AKS = 強力な CI/CD

デプロイパイプラインを理解することで、 チーム全体の開発効率と品質が向上する

Happy Deploying! 🎉

本スライドの最新版は slidict.io で公開中