1. はじめに

アプリ開発において、効率的なデプロイ環境とブランチ戦略の構築はプロジェクトの成功に不可欠です。本記事では、各デプロイ環境の役割と、効果的なブランチ戦略の考え方について詳しく解説します。

まとめると次に示す１ページのスライドのようになります。デプロイ環境とブランチ戦略は密接に関係しているため、両者を組み合わせて適切に設定することが重要です。ここでは、パブリッククラウドを活用した Web アプリを対象のアプリとして想定しています。

また、次回以降、ここで紹介した内容を具体的なツールの設定を行いながら、環境構築していきます。

デプロイ環境とブランチ戦略

2. ロールモデル

本シナリオを紹介する上で、この記事で利用している言葉の意味を理解するために、以下のロールモデルを定義します。

ロール名 説明
アプリ開発者 新しい機能を実装たり、既存の機能のバグを修正したりと実際にコードを記述するロール
プラットフォーム開発者 IaC や Dockerfile などインフラに関するコードを記述するロール
SRE システムの信頼性を確保し、運用を効率化するための取り組みを行うロール
テスター 開発された機能が正しく動作するかや、見つかったバグが正しく修正されているかを確認するロール
クラウド管理者 企業内でのクラウド上でのサービス利用を促進し、適切に利用するためのルール作りをして徹底させるロール
利用者 実際にアプリケーションを利用するロール

3. デプロイ環境の種類

まず、ここではデプロイ環境の種類とそれぞれの役割について説明します。 アプリ開発において、それぞれのフェーズに応じて、異なる要件の環境が必要とされます。それぞれの要件でどのような環境が必要とされ、それを満たすためにどのような環境を準備すべきかについて解説します。 それぞれのフェーズで利用される環境をデプロイ環境と呼びます。

3.1. サンドボックス環境

3.1.1. 役割

まず、サンドボックス環境です。 サンドボックス環境の目的は、アプリ開発者がクラウドで新しく提供される機能を試して、自社の既存のアプリの機能を改善したり、新しい機能を追加したりするために、実際にサービスを触りながら試すための環境です。

加えて、プラットフォーム開発者もこの環境上で新しく提供される機能を試して、自社の既存のアプリの性能を改善したり、よりシンプルな構成にしたりできないかを評価します。

また、クラウド管理者もこの環境を利用して、新しい機能を試して、自社のポリシーに準拠した機能であるかを確認します。

本環境の定義における難しい点は、クラウド上で提供される新たな機能が必ずしも新しいサービスとして提供されるわけではないことです。 例えば、クラウド上で提供される新しい機能が、既存のサービスの新しい機能として提供される場合もあります。 また、大手のパブリッククラウドは、世界中の各地域にリージョンと呼ばれるサービス提供ポイントを設けており、すべてのリージョンにおいて同時に提供が開始されることは少ないです。

これらのことから、サンドボックス環境と他の環境を同じルールで扱うと、いつまで経っても新しい機能を試すことができず、他社に遅れをとってしまう可能性が高くなります。 一方で会社や顧客のデータが含まれている他の環境と同じように扱うと、資産の漏洩や顧客情報の流出など、セキュリティ面でのリスクが高まります。

そのため、サンドボックス環境は他の環境と切り離して、独自のルールで運用することで、柔軟性を高めつつ、セキュリティリスクを低減する環境を定義する必要があります。

3.1.2. 環境に求められる要件

サンドボックス環境に求められる要件は、以下の通りです。

3.2. 開発環境

3.2.1. 役割

次に、開発環境です。 開発環境は、アプリ開発者が新しい機能を実装したり、バグ修正や性能改善を目的として、既存の機能を修正したりするための環境です。

通常、一つのアプリに対して複数名で開発することが一般的です。 そのため、開発環境では、複数のアプリ開発者が同時に開発を行うことができるように、環境を共有する必要があります。 一方で、お互いに開発している機能が干渉しあわないように、環境を分離する必要があります。

このように矛盾する条件を満たすために、開発環境は開発する機能に影響がないリソースは共有しつつ、開発する機能に影響があるリソースは分離することが求められます。 そのため、開発環境におけるポリシーはある程度プロダクション環境と同じ定義であることに加え、必要に応じて例外を受け入れられるポリシーである必要があります。

また、開発環境はプラットフォーム開発者がシステムのインフラ構成を IaC (Infrastructure as Code) のコードを作成します。これにより、複数の環境への新規デプロイやアプリの変更に伴う新しいバージョンをデプロイする時に、人手を介さないことによって、ヒューマンエラーを減らすことができます。

3.2.2. 環境に求められる要件

開発環境に求められる要件は、以下の通りです。

3.3. 検証環境

3.3.1. 役割

検証環境は、開発環境で開発された機能を並行して開発された別の機能と統合したときにお互いに悪い影響を及ぼさないかや、すでに提供している機能に悪い影響を及ぼさないかを確認する環境になります。

そのため、検証環境はプロダクション環境に近い設定で動作することが求められます。 この環境を利用するテスターは、開発された機能が正しく動作するかや、見つかったバグが正しく修正されているか、また、すでに提供している機能が問題なく動作するかを確認します。

また、単に機能の動作確認だけでなく、利用者が増加して負荷が高まったとしても問題なく動作し続けるかなどの負荷テストのような非機能のテストも実施されます。

3.3.2. 環境に求められる要件

検証環境に求められる要件は、以下の通りです。

3.4. ステージング環境

3.4.1. 役割

ステージング環境は、本番環境と同じ設定で動作する環境です。ここでは、最終的な確認を行い、利用者に影響を与える前に問題を発見することが目的です。

すでにこれまでの環境で、機能面、非機能面での動作確認は済んでいるため、基本的にステージング環境では、プロダクションのデータベースと接続させて問題なくデータが見えているかなど、プロダクション環境にそのまま移行できるかを SRE によって確認する環境になります。

また、 SRE によってプロダクション環境のバージョンアップ作業として、 Blue/Green デプロイメント作業によってルーティングが切り替えられます。

3.4.2. 環境に求められる要件

ステージング環境に求められる要件は、以下の通りです。

3.5. プロダクション環境

3.5.1. 役割

プロダクション環境は、利用者が実際にサービスを受ける環境です。 そのため、 SRE によってサービスの運用に必要な作業が行われます。例えば、リソースの利用率が想定以下になっているかという監視設定や、リソースの利用率が想定以上になったときに自動的に対処するためにリソースを追加するオートスケールの設定をしたり、対処できない問題が発生したときにアラートを飛ばす設定をしたりと多岐に渡ります。

3.5.2. 環境に求められる要件

プロダクション環境に求められる要件は、以下の通りです。

3.6. まとめ

本章で紹介した内容をまとめると、次に示す１ページのスライドのようになります。

ロールモデルとデプロイ環境

4. ブランチ戦略の基本

このように様々な目的の環境を運用していくと、現在、どの環境でどのコードが設置されているかがわからなくなることがあります。

それを防ぐため、それぞれの環境に対して、該当するブランチを作り、さらに、開発プロセスにおいてどのようにブランチを作成してそれぞれのブランチをどのように運用するかを決めることは、目的がわからないブランチに埋め尽くされるようなブランチ地獄の発生を防ぐことが可能になります。

そのため、プロジェクトの最初のタイミングで、ブランチ戦略を考えることはとても重要になります。

4.1 ブランチの種類

ブランチ名 デプロイ環境 ブランチ元 Pull request 先 用途
master(main) ステージング なし なし ・プロダクションとしてリリースするコード
・全てのブランチの基準となるブランチ
rc(release) 検証 master master ・次期リリースとなるコード
・検証後に master にマージする
feature_xxx 開発 master release ・新機能の開発を行うブランチ
・機能ごとに別々のブランチを作成して作業
開発完了後に release ブランチにマージする
hotfix_yyy 開発 master release ・バグ修正の開発を行うブランチ
・バグごとに別々のブランチを作成して作業
・開発完了後に release ブランチにマージする

4.1.1. master ブランチ

master ブランチは、常にデプロイ可能な状態を保つことが求められるブランチです。通常、リリース済みのコードが含まれます。また、 main ブランチと名付けることもあります。

4.1.2. release ブランチ

release ブランチは、次のリリースに向けた最終調整が行われるブランチです。ここのブランチは、 master ブランチに対して各機能やバグ修正の結果が統合されたブランチとなります。

開発ブランチは、次のリリースに向けた検証が行われるブランチです。ここでは、複数のフィーチャーブランチが統合されます。また、rc (release candidate) ブランチと名付けることもあります。

4.1.3. feature ブランチ

feature ブランチは、新しい機能を開発するための一時的なブランチです。 master ブランチをベースに機能の開発が行われ、それが完了したら、 release ブランチにマージされます。

通常、 feature ブランチの命名規則は、 feature ブランチでわかることが接頭辞として使われ、その後に機能の内容を示す例えばチケット番号やタイトルが付けられます。

4.1.4. hotfix ブランチ

hotfix ブランチは、本番環境で発生したバグを修正するためのブランチです。 master ブランチをベースに機能の開発が行われ、それが完了したら、 release ブランチにマージされます。

また、バグにはその深刻度に応じて、修正の優先度をつけることがあります。例えば、クリティカルなバグはすぐに修正する必要があるため、次のリリース時に他の機能と一緒にリリースされる release ブランチにマージされるのではなく、検証の上、直接 master ブランチにマージされることがあります。

通常、 hotofix ブランチの命名規則は、 hotfix ブランチでわかることが接頭辞として使われ、その後にバグの内容を示す例えばチケット番号やタイトルが付けられます。

4.2. デプロイ環境とブランチの連携

4.2.1. 環境ごとのブランチ運用

各デプロイ環境に対応するブランチを設定することで、効率的なデプロイとテストが可能になります。例えば、ステージング環境には release ブランチをデプロイすることが一般的です。

5.2. 自動デプロイの設定

自動デプロイを設定することで、コードの変更がブランチにマージされるたびに、対応する環境に自動的にデプロイされます。これにより、デプロイの手間を削減し、迅速なフィードバックが得られます。

6. まとめ

デプロイ環境とブランチ戦略を適切に設定することで、開発プロセスの効率化と品質向上が期待できます。各環境とブランチの役割を理解し、プロジェクトに最適な戦略を構築しましょう。

Appendix 1. Blue/Green デプロイメント

パブリッククラウド上でのサービス提供される機会が増えて以来、プロダクション環境プロダクション環境のバージョンアップする手段として、 Blue/Green デプロイメントという方法がよく採用されます。

これは、既存のプロダクション環境を更新するのではなく、ステージング環境にプロダクション環境と同じ構成でデプロイして、外部から流入する通信のルーティング先を変更することで、メンテナンス期間を儲け抵抗するなど、利用者に影響を与えずに新しい機能を提供することが可能になります。

Appendix 2. チケット駆動開発とブランチ戦略

ブランチ戦略をより効率的に行う方法として、新しい機能のリクエストやバグの報告が一覧されるチケットとブランチを関係づけて運用することで、より理解しやすいプロジェクト管理の方法があります。

この方法については、改めて紹介します。

7. 参考文献