Amazonデプロイメントパイプラインの外観と、プロダクション環境に継続的にデプロイするために実行するプラクティスについてAWSエンジニアは先頃書いた。パイプラインは、単体テストと統合テストを実行している複数の本稼働前環境での変更を検証し、ステージを使用してプロダクションへのデプロイを調整する。パイプラインは主要なメトリクスを監視し、必要に応じてロールバックできるため、開発者はデプロイメントを積極的に調査しない。また、開発者は、一般的な構成を継承できるコードとしてのパイプラインをモデル化する。
通常、マイクロサービスは、結合を減らす目的でデプロイ時間を短縮するための複数のデプロイパイプラインで構成されている。たとえば、パイプラインは、アプリケーションコード用、インフラストラクチャ用、OSパッチ用、構成用、およびオペレーターツール用のパイプラインにすることができる。各パイプラインは、ソース、ビルド、テスト、プロダクションを含む少なくとも4つのフェーズで構成される。
出典: "Automating safe, hands-off deployments" blog post
ビルドステージでは、パイプラインがコードをコンパイルし、単体テストを実行し、静的分析を実行し、コードカバレッジを評価し、アーティファクトを保存する。テストステージでは、パイプラインはアルファ、ベータ、ガンマなどの複数の本稼働前環境での変更を検証する。また、ここで、さまざまなゾーンやリージョンへのデプロイを実施する。最後に、チームはパイプラインをより小さなデプロイメントステージに分割して、障害が発生した場合の影響を制限する。次のステージに進む前に、パイプラインはサービスをしばらく監視して、サービスの可用性を確保する。
出典: "Automating safe, hands-off deployments" blog post
開発者がコーディングを完了し、単体テストと統合テストを使用して個人のAWSアカウントで変更を検証すると、チームの他の誰かがそれを確認する必要がある。レビュー担当者は、コードが正しいこと、十分なテストがあること、十分にインスツルメントされていること、および変更が下位互換性があることを確認してロールバックを確実にする。コードレビューは最後の手動プロセスであり、コードがメインブランチに到達すると、デプロイパイプラインが自動的にトリガーされるため、重要なステップである。ただし、ユーザーインターフェイスの変更など、公開前に追加の承認が必要になる場合がある。AmazonのClare Liguori氏がレビュープロセスの詳細を共有した:
トランクベースの開発を行うため、パイプラインはメインブランチのみを扱います。 ブランチを作成することはほとんどありません。自動バックアップツールがローカルコミットをremote git refにプッシュし、コードレビューの送信により、提案された変更のremote git refが作成されます。コードレビューはユニットテストを実行します。
さらに、一部のデプロイメントパイプラインには、デプロイメントを開始できるタイミングを示し、悪影響を引き起こすリスクを軽減するための時間枠を設定できる。Liguori氏によると、これらの一連の時間枠により「通常の勤務時間外はオンコールエンジニアとのやり取りが少なくなり、時間枠が閉じている間に少数の変更がバンドルされるようになります」。
InfoQは先頃、AWSコンテナサービスのプリンシパルソフトウェアエンジニアであるClare Liguori氏に、Amazonがどのように継続的にデプロイするかについての詳細を話した。
InfoQ: プロダクションに継続的な問題がある場合はどうなるのでしょうか？
Clare Liguori氏: プロダクションで継続的な問題については、まず、インパクトを示す特定のパイプラインステージ（影響を受けるアベイラビリティゾーンやリージョンなど）をロールバックして、可能な限り迅速にインパクトを緩和することに焦点を当てます。インパクトの根本原因が特定のパイプラインステージに固有のものではないことが判明した場合は、変更がデプロイされたパイプライン内のすべてのウェーブをロールバックします。
InfoQ: チームはどのようにして各ステージでどのタイプのテストを実行するかを決めているのでしょうか？
Liguori氏: パイプラインは、変更のサイズに関係なく、常にフルセットのテストを実行します。小さな変更であっても、予期せぬ場所でバグやパフォーマンスのリグレッションが発生する可能性があるため、パイプラインでは、すべてのユニットテスト、機能テスト、および統合テストが変更のたびに実行されるようにしています。実行に時間がかかるような大規模なテストスイートの場合は、テストスイートを複数の小さなテストスイートに分割してパイプライン内で並列に実行することで、パイプラインを高速化し、変更をより早くプロダクションに移行させることができます。
InfoQ: チームはコードレビューのボトルネックにどのように対処しているのでしょうか？
Liguori氏: プロダクションへの変更はすべてコードレビューが必要であり、パイプラインによって実施されます。コードレビューがボトルネックにならないようにするために、多くのコード変更を含む単一の大規模なコードレビューを提出するよりも、機能作業を複数の小さなコードレビューに分割し、マージして個別にプロダクションに出荷することを推奨します。小規模なコードレビューの方が、チームメンバーがタスク間でレビューしやすいため、この方法を採用することで、コードレビューをより継続的にレビューして出荷することができます。
InfoQ: 開発者はどの程度の規模で、プロダクションのコピーをAWSアカウントで実行しているのでしょうか？
Liguori氏: ローカルでの変更をテストするための開発セットアップは、チームのニーズ、好み、アーキテクチャによって異なります。例えば、多くのマイクロサービスでは、ローカルでサービスをコンテナで実行し、チームで共有しているAWSアカウントにある単一の「開発」データベースを使用してテストデータを保存することでテストを行うことができます。他のチームでは、各チームメンバーがそれぞれの小さな開発データベースを別々のAWSアカウントに置くことを好んでいます。アーキテクチャやテストする必要のある変更に応じて、Step FunctionsのワークフローやSQSキューのような他のリソースを開発アカウントに作成することもあります。