The Amazon Builders’ Library というページがあります。このページでは、Amazon においてソフトウェア開発をどのように行っているかがブログ記事の形式で公開されているのですが、その中で CI/CD に関する 4 つの記事（3 つは日本語化済み）が公開されていたので、どういうことが記載されているのかまとめてみました。
この記事では、最新の 4 記事目についてまとめています。
My CI/CD pipeline is my release captain (2022 年公開)
AWS のプリンシパルソフトウェアエンジニアである Clare Liguori による投稿です（3 記事目 と同じ人）。現時点で英語版のみです。
Introduction
Amazon で継続的デリバリーを採用する前は、多くのチームの開発者がリリースキャプテンと呼ばれる役割を果たしていました。リリースキャプテンは、コード変更のリリースを調整し、本番環境にデプロイする責任がありました。Amazon の多くの開発者はリリースキャプテンの役割が好きではありませんでした。時間がかかり、サービスの構築や新機能の開発から遠ざかるためです。リリースキャプテンがリリース日をスケジュールし、リリースに含める必要がある変更を決定し、リリース番号を割り当て、ソースコードリポジトリにリリースブランチを作成し、リリース候補をビルドしてテストしました。その後、リリースキャプテンは、本番環境にデプロイするための手順の詳細なリストを作成し、承認を得ました。これには、デプロイするリリース候補、さまざまな本番環境へのデプロイの順序、リリースによって運用上の問題が発生した場合に備えた各本番環境のロールバック手順が含まれます。現在、Amazon の開発者は、特定のリリースの変更の発送、リリースブランチの管理、リリース配信の調整について考える必要はありません。代わりに、開発者はコードをプッシュし、CI/CD パイプラインに変更のリリースを継続的に任せています。
Trunk-based development
Amazon のほとんどのチームはトランクベース開発を実践しています。これは、チームがリリースの管理をやめ、CI/CD パイプラインに継続的に変更をリリースさせるために必要なコアプラクティスです。開発者は、存続期間の長いフィーチャーブランチから共有ブランチに大量のコード変更を低頻度でマージするのではなく、ソースコードリポジトリ内の 1 つの共有ブランチに頻繁に小さなコミットを行うことでコード変更を行います。この共有ブランチは、Amazon の内部の Git システムでは mainline という名前になることが多いです。
Safe, automatic production releases
Amazon の CI/CD パイプラインは「ステージ」「承認」「プロモーション」としてモデル化されています。個々のステージで各環境にリリースがデプロイされ、設定されたテストやアラームといった承認ステップをパスすることで、そのリリースは次のステージにプロモートされます。
デプロイするリージョンごとに Wave というグループに分かれていて、後続の Wave ほど属するリージョン数が多くなっていて、これによってデプロイ速度の向上を図っています。各 Wave では更にステージに分かれていて、AZ 毎に One Box 環境へのデプロイと、その後の AZ 全体へのデプロイがあります。各ステージでは、まずはアーティファクトをデプロイして、その後アラームやテストの状況が監視され、問題がなければ承認されて次のステージへプロモートされていきます。
Multiple inflight releases
現在、Amazon のCI/CDパイプラインは、コード変更がパイプラインにデプロイされるまでの時間を最小限に抑えるために、進行中のリリースの複数持つことができます。開発者が新しいコードの変更をメインブランチにマージするとすぐに、新しいリリースがビルドされ、パイプラインの進行が始まります。トランクベースの開発を行う場合、開発者は新しいコード変更をマージすることが多いため、毎日複数の新しいリリースがビルドされ、パイプラインに入ることがよくあります。
たとえば、Stage 3 の規模が他よりも多くデプロイに時間がかかるとします。すると、Stage 3 で v1 をデプロイし終わる前に、Stage 2 にて v2, v3 のデプロイ＆承認が完了することがあります。その場合、Stage 3 では v3 のみがプロモートされます。
Transparent, immutable deployment artifacts
CI/CD パイプラインは、デプロイアーティファクトも管理します。このプロセスは開発者にとってほぼ完全に透過的です。開発者は、バージョン番号を計算したり、デプロイアーティファクト ID やビルド ID を追跡したりする必要がありません。パイプラインはリリース、デプロイ、ソースコードコミットの関係を追跡するため、開発者はデプロイのアーティファクトやリリースを意識しなくても、どのコードがデプロイされたかを確認できます。また、特定のソースコードの変更がパイプラインのどこにデプロイされたかを確認することもできます。たとえば、自分が書いたバグ修正がすべてのプロダクション環境にデプロイされたかどうかを確認できます。
Easy and automatic rollbacks
ロールバックは Amazon の運用文化の重要な部分です。私たちの運用プラクティスでは、まず問題の解消を優先し、ユーザーへの影響を軽減した後、詳細なトラブルシューティングを行います。時間をかけて問題の原因となった特定のコード変更を特定したり、問題を解決するために新しいコード変更を導入したりすると、ユーザーへの影響が長引いてしまいます。その代わり、まず最初にすべきことは、直近のデプロイを積極的にロールバックすることです。
不変のアーティファクトと不変の環境を使用することで、ロールバック展開が副作用や意図しない変更なしに、通常の展開とまったく同じ方法で行われるようにすることができます。デプロイのたびに EC2 インスタンスの同じディレクトリにコードをデプロイすることは、可変環境の一例です。この環境にデプロイすると、ロールバック後も新しいファイルがディレクトリに残り、古いコードの動作に影響を与えて運用上の問題が発生する可能性があります。代わりにインフラストラクチャをコードとして使用し、不変の AMI、コンテナイメージ、Lambda 関数をデプロイすることで、ロールバックデプロイ後にアプリケーションの環境を古いリリースに完全に置き換えることができます。チームがコードを (新しい AMI に置き換えるのではなく) 既存の EC2 インスタンスにデプロイする場合でも、可能な限り不変性を目指しています。デプロイするたびに、新しいコードをデプロイする新しいディレクトリが作成され、シンボリックリンクが現在のバージョンのディレクトリを指すように更新されます。ロールバックデプロイ中にも同じ手順が実行されます。古いコードが新しいディレクトリにデプロイされ、シンボリックリンクが更新されるため、ロールバックによって副作用が発生する可能性が低くなります。
Conclusion
Amazon では、継続的デプロイの実践と CI/CD パイプラインシステムの組み合わせにより、リリースキャプテンの役割をほとんど手放すことができました。Amazonには、モバイルアプリケーションやデバイスファームウェアなどのバージョン管理されたソフトウェアを提供するチームがいくつかあるため、それらのチームの中には従来のリリースを実践し、リリースブランチ、スケジュール、バージョン管理を注意深く管理しているところもあります。ただし、Amazon のほとんどの開発者は、リリースの管理に煩わされることなく、ビルドに集中できます。CI/CD パイプラインをリリースキャプテンにするために、チームはトランクベースの開発を通じてコード変更を継続的にリリースし、不変のアーティファクト、不変な環境、およびコードとしてのインフラストラクチャを使用してアプリケーションをデプロイします。
