How to achieve continuous release of applications

01 継続的リリースのまとめ

デプロイのプロセスでは、多くの問題に直面することがよくあります。

1. 手動デプロイでは、デプロイに時間がかかるため、頻繁にエラーが発生し、デプロイの問題を手動で修正する必要があります。

2. 環境が切り離されている場合、環境間の差異が大きいため同様の本番環境が存在せず、環境問題が顕著になります。環境が不安定なため、初回デプロイ時の本番環境の状況を判断できません。

3. クラスターをデプロイする際、各環境の設定が異なるため手動で修正する必要があります。この時点で、ノードの設定はほぼ制御不可能です。本番環境の設定を直接変更する場合、リスクは比較的高くなります。

4. デプロイ時には、複数の開発者が共同作業し、頻繁に更新が行われるため、相互にブロックが発生します。この時点で、運用保守、開発、テストの連携コストが非常に高くなります。

継続的リリースのプロセスでは、多人開発、シンプルなデプロイ、安定した環境、継続的な自動検証、機能の迅速な反復、リリースモードの設定サポート、機能の安定性確保を実現したいと考えています。リリース中に問題が発生した場合、安定バージョンに迅速にロールバックし、問題を素早くフィードバックできます。

測定指標はチームの行動に直接影響を与えます。コード行数を開発者の指標として選択すると、開発者はパフォーマンスの見かけを重視してコードを簡潔に書かなくなります。この現象をホーソン効果と呼びます。

デリバリープロセスでは、サイクルタイムを測定指標として選択できます。サイクルタイムとは、開発開始から最終納品までの時間を指します。

たとえば、リソース準備では、環境リソースの準備開始から環境が完全に利用可能になるまでの期間がリソース準備のサイクルタイムです。現在クラウドでは、予算申請後にオンラインで直接購入できるため、リソース調達サイクルを大幅に短縮できます。

リリース有効性とは、機能開発の検証、リリース準備から顧客への納品までの期間を指します。リリースの準備時間、リリース環境の設定時間、グレースケール時間、フィードバック問題への対応速度などが含まれます。

02 継続的リリースの構築パス

サイクルタイムを短縮するには、プロセス全体の自動化が必要です。環境、ソフトウェアパッケージ、ネットワーク設定、インフラストラクチャ、外部サービスなどの機能をすべて、構築、デプロイ、テスト、リリースなどの段階からバージョン管理に組み込む必要があります。

アプリケーションを公開する際、ソフトウェアに必要な実行環境を準備し、必要なインフラストラクチャや外部サービス依存関係などを設定する必要があります。ソフトウェアをインストール環境で実行し、必要なデータと状態を設定することで、ソフトウェアデリバリーを完了できます。

バージョン管理には、要件ドキュメント、テストスクリプト、自動化ケース、ネットワーク設定、データベース作成、アップグレード、初期化、ロールバックなどが含まれ、すべてバージョン管理が必要です。

さらに、チームはコンセンサスを形成する必要があります。継続的リリースのプロセスでは、チームはリリース仕様に従い、プロセス全体を継続的に改善し、リスクを制御可能に保つ必要があります。

03 クラウド上での継続的リリースの実践

次に、継続的リリースの関連ステップについて説明します。環境準備では、テンプレートを投入し、既存テンプレートまたはカスタマイズされたテンプレートを使用してクラウド環境を記述します。入力パラメータを指定して自動デプロイを実行します。最後に、各リソースのデプロイ完了状況を確認し、後続の管理を実施します。

このリソース準備プロセスは、企業の迅速なクラウド移行とオンデマンドでのバッチデプロイに適しています。アプリケーションはリソースの迅速な複製を必要とし、既存リソースを使用してアプリケーションを迅速に構築します。

継続的ビルドでは、サービスを提供するコードパッケージをパッケージ化して OSS にアップロードします。ユーザーは関連する環境パラメータを入力して、対応するソフトウェアパッケージをプルできます。次に、運用作業のスケジューリングを通じて、対応するパッケージ情報を ECS にプルします。クラウドアシスタントは対応するデプロイスクリプトを実行してアプリケーションを起動し、外部サービスを提供します。

ビジネスが拡大し続け、マシンがサービスをサポートできなくなった場合、Auto Scaling による伸縮で迅速にマシン数を増減し、自動デプロイを実現できます。

継続的リリースでは、主に Auto Scaling のローリングアップグレードに基づいています。まず伸縮アクティビティを停止し、次にインスタンスをグループ化してスタンバイ状態にします。該当インスタンスは公開プロセス中に外部サービスを提供しません。公開完了後、インスタンスはスタンバイモードを終了し、外部サービスを提供します。

ローリングアップグレードは、カナリアリリース、ブルーグリーンリリース、バッチリリースなどの機能に適しています。運用作業オーケストレーションでソフトウェアパッケージを作成し、スケーリンググループを作成して ECS インスタンスを追加し、ローリングアップグレードタスクを実行します。

04 アプリケーションの継続的リリース

次に、継続的リリースのプロセスにおけるリリース原則について説明します。アプリケーション公開は、低リスクで頻繁、低コスト、迅速かつ予測可能なプロセスであるべきです。

このプロセスでは、スクリプト化、バージョン管理、再現性、フィードバックを実現する必要があります。自動化の面では、自動化デプロイ、自動化テスト、自動化フィードバックを実現する必要があります。

管理の面では、バージョン管理、依存関係管理、環境管理、設定管理を改善する必要があります。高速ロールバック、迅速な再リリース、トレーサビリティを実現します。問題が発生した場合、継続的改善、頻繁な反復、迅速なフィードバック、生産サイクルの短縮を可能にします。

ライフサイクルデリバリーのトレーサビリティと可観測性を向上させることで、リリースをより効果的にすることができます。

前述の図に示すように、継続的リリースに関連するサービスには主に、クラウド、環境準備、コードビルド、自動デプロイ、継続的リリースが含まれます。

環境準備では、ROS、Terraform、ECS、ACS、OSS などのクラウドリソース製品を使用して環境を準備できます。コードビルドでは、ACMS や ERDC Cloud Effect を通じてアプリケーション設定管理を実施できます。

自動デプロイでは、EDAS または OSS を通じてデプロイ・構築できます。継続的リリースでは、RDC Cloud Effect を通じてデプロイパイプラインをカスタマイズし、Auto Scaling を通じて継続的リリースを実施できます。

Q&A セクション：ユーザーの質問と回答

Q1：ホーソン効果は、被験者が研究されていることを認識しているために人為的な効果が生じるものです。クラウド自動化後にこの状況を完全に回避できますか。

A：継続的リリースにより適した測定方法を決定する必要があります。測定指標が不適切な指標である場合、ホーソン効果は結果の偏りを引き起こします。測定指標が信頼できる場合、ホーソン効果は指標をより良くしていきます。

Q2：パイプラインデプロイに伴うリソース関連、データ関連、権限制御関連などの問題について、発生しうる問題を効率的に解決するにはどうすればよいですか。

A：パイプラインデプロイは一般的にアプリケーション単位でデプロイされます。アプリケーションを設定する際、リソースデータ権限を設定する必要があります。さらに、クラウド上のアクセス制御機能を活用して権限管理を強化することもできます。