AWSは、アプリケーションとインフラのアップデートのために自動化されたリリースパイプラインを促進するマネージドな継続的デリバリーサービスである、CodePipelineの新機能を発表した。これらの追加機能は、様々なデリバリー戦略を採用し、パイプライン設計においてより柔軟性を顧客に提供するチームのサポートを目的にしている。今回のアップデートでは、CodePipelineにトリガーと新しい実行モードが導入され、ブランチベース開発を使用しているユーザーや、monorepo（モノレポ）内で複数のプロジェクトを管理しているユーザーのニーズに対応する。
AWSのMichael Ohde氏は、包括的かつ徹底した例を含む投稿にて、3つの異なるパイプライン設計作成で、いかに効果的に新しい機能を活用するかを詳しく説明している。これらのパイプラインを設定するプロセスでは、AWS Management Console内、またはCodePipeline APIを使ったスクリプトでトリガーと実行モードを設定する。ユーザーは、複数の実行を処理するための要件に応じて、Queued、Parallel、Supersedなどの実行モードから選択できる。
GitFlow リリースパイプライン
例えば GitFlow のリリースパイプラインは、キュー実行モードを使ってトリガーされた順番に実行を処理する。ブランチフィルタを設定することで、ユーザーは main、develop、hotfix、release のようなブランチを特定でき、設定されたブランチのいずれかにプッシュされた関連するコード変更に、パイプラインが確実に応答する。この設計により、チームはGitFlow開発モデルに従うことができる。このような開発モデルは、並行開発や長期ブランチを使ったリリースを行う大規模プロジェクトの管理によく使われる。
Pull Request（PR）パイプライン
同様に、PRパイプラインは並列実行モードを利用し、プルリクエストごとに独立して実行をトリガーする。この設定により、マージ前にブランチをまたいだ変更案の迅速な検証が可能になる。これは、すべてのプルリクエストに対して実行されるように設計されており、変更をメインブランチにマージする前にビルドやテストの失敗を検出するのに特に有用なことが知られている。
Monorepoパイプライン
monorepo（モノレポ）パイプラインでは、ファイルパスフィルターを設定することで、パイプラインの実行をリポジトリ内の特定のフォルダに集中できる。このアプローチは、不要な実行を最小限に抑え、リソース割り当てを最適化する。これは、1つのリポジトリに複数のプロジェクトのコードが含まれるような配置に最適だ。
この変更に対する反応は肯定的だが、一部のコメンテーターはこの変更は遅すぎたと指摘している。
最初のリリースから約9年、CodePipelineがついにブランチベースのリポジトリに対応した。2018年にこれを本当に使えたら良かったのに。
- Luc van Donkersgoed
AWS CodePipelineにトリガーと実行モードを導入すると、特に開発プラクティスにうまく適合しない僅かなユースケースの場合に、ユーザーやチームが配信ワークフローを自動化するための可能性の幅が広がる。GitFlowやそれに手を加えた、複雑な複数ブランチ戦略を使うチームは、AWS CodePipelineをより効果的に使用できるようになった。
これら機能の利用に関する詳細なガイダンスについて、AWS CodePipelineユーザーガイドが参照でき、またAWSが提供するハンズオンチュートリアルを探索可能だ。