リリース関連

CIパイプライン

• 起動方法
  • developブランチまたはfeatureブランチへプッシュした際
• 備考
  • 「ビルド成果物をGCSへアップロード」が完了した後の場合、ビルド成果物はGCSから手動で削除する必要がある

CD（DEV）パイプライン

• 起動方法
  • CIパイプラインが起動終了した際
• 備考
  • 古いコミットの内容を開発環境へデプロイしたい場合は、git revertまたはgit resetなどを使用してHEADを確認したいコミットに持ってきてリモートへプッシュすること

CD（PROD）パイプライン

• 起動方法
  • prepare-prod-cd：リモートへコミットタグがプッシュされた際
  • manual-deploy-prod：GithubActionsの手動実行（詳しくはこちらの記事を参照のこと）
• 切り戻しを行う場合
  • 切り戻しを行いたいリリースバージョンをActionsのGUIから入力することで行う
• 備考
  • 現状リリースされているバージョンは、GitOpsの場合簡単に確認が可能だが、今回の場合は難しい。そのため、READMEなどで現状のリリースバージョンを表示することで現状のバージョンをGitOps的に管理することが可能。

設計関連

ブランチ戦略

• 基本的にgit-flow戦略に則って開発を行うことを想定。
• git-flow戦略かgit-feature-flow戦略が選択肢として挙がるため、その比較をしながら選択根拠について記載
  • 根拠
    • git-feature-flow戦略と比較すると、リリースまでの変更内容の流れがシンプルになること
    • 今回、スクラムのような細かい変更を高頻度にリリースする予定ではないため
• 今後、コストを掛けてリリースさせたい場合は、git-feature-flow戦略に倒すことを検討のこと

git-flow戦略

• 概説：開発ブランチ上で単体テストなどを行い、ある程度品質の担保が確認できたら開発環境に対応するdevelopブランチへマージして、そこで大きい粒度のテストを行う
• モノリシックアプリの開発に向いている
• 参考ページ
  • メリット
    • リリースまでの流れがシンプルになるため理解しやすい
    • 開発環境と本番環境の資材の冪等性を担保させやすい
  • デメリット
    • 開発のアジリティを挙げるベストプラクティスである高頻度リリースを行うことができない
    • ビジネスとして展開する場合は不向き

git-feature-flow戦略

• 概説：開発ブランチからdevelopブランチへforceでマージさせて、動作確認用として開発環境とそれに対応するブランチを使用する開発手法
• スクラムなどに向いている
• 参考ページ
  • メリット
    • 開発のアジリティを挙げるベストプラクティスである高頻度リリースを行うのに向いている
    • 提案されてそこそこ期間が経っているため、導入記事などが結構ある
  • デメリット
    • コストを掛けたくないようなアプリの開発手法には不向き

CI/CDパイプライン

CIの処理詳細

• ビルド
  • FireCMSのテンプレートに組み込まれているスクリプトを使用してビルドしている（vite）
• GCPへの認証
• ビルド成果物圧縮
  • GCS上でビルド成果物を管理することと処理の過程でネットワーク帯域を節約するためにgzip圧縮を行う
• ビルド成果物をGCSへアップロード
  • 開発環境へデプロイする資材と本番環境へデプロイする資材を統一するためにGCSへアップロードする
  • RunnerからGCSへのアップロードにはcloud-sdkを使用する。理由としては、マルチプロセスアップロードが使用可能なため、今後大規模アプリに適用する場合に処理速度の点で有利になる

CD（DEV）

• GCPへの認証
• Set Up cloud-sdk
• ビルド成果物をGCSからダウンロード
• ビルド成果物解凍
• FirebaseExended/action-hosting-deploy
  • 公式アクションを使用して動作確認用のpreviewチャンネルへデプロイする