今、CodePipeline V2のアップデートがアツい！
概要
AWS CodePipelineのアップデートが最近(2024/10時点)も活発に発表されている印象です。
CodeCommitのサービス終了などの発表もある中、Codeシリーズの仲間？でもあるCodePipelineのアップデートが頻繁である意外性とCodePipeline自体のユーザーとして動向を整理したいと思います。
CodePipeline V2のリリース
2023年10月、CodepipelineのV2がリリースされました。
この時は、各ステージに動的に変数を与えられるようになったり、料金体系がV1と異なるものになるなどの発表はあったものの個人的な印象としてはインパクトの大きいリリースではなかったです(ユースケースに新規機能刺さらなかった)。
CodePipeline が追加のトリガーフィルターと新しい実行モードのサポートを開始
2024年2月、Parallel と Queued の 2 つの新しいパイプライン実行モードをサポートするようになりました。
このアップデートは当時PipelineにQueueの機能を導入したいと考えていたこともあり、ホットなアップデートでした。早速、QUEUEモードを試してみてブログにまとめた記憶があります(当時最速だったはず)。個人的なバイアスのかかった感想になってしまいますが、このくらい機能に差があれば価格のとても安いV1と比較してV2の導入を検討してもいいかなという感じがしました。実際にコストを試算するとV2でもそれほど価格がかからない計算であったので一部のパイプラインをCodePipelineV2化しました。
ステージレベルの手動ロールバックをサポート
2024年4月、ステージレベルでボタン操作でロールバックできるようになりました(CLIからできるかは調べていないです)。2024年10月16日現在では、ロールバック、ステージのみの再試行、アクションの再試行をすることができるようになっていました。
パイプラインゲートを実装するためのステージレベルの条件を導入
2024年8月、ステージ条件を設定できるようになりました。このアップデートは本記事を書いている際にWhat's newを眺めている時に見つけました。詳細はクラスメソッドさんの記事を参照いただけるとわかりやすいのですが、これまでステージの成功か失敗かでしか次のステージに移行するかどうかの条件設定ができなかった(何も設定できない)のですが、このアップデートにより次のステージに移行するか、ロールバックするかなど条件設定を実現できるようになったようです。(便利そうなので使いたい)
(画像はクラスメソッドさんの記事から拝借)
最近の動向
マネジメントコンソールからはV2のCodePipelineしか作成できなくなる
2024年10月05日、CodeBuild セットアップなしでコマンド実行が出来る新しいビルドアクション「Commands」についての記事を読んでいたら(正確には見逃していたけど教えてくれた)、
現在 CodePipeline パイプラインには V1 と V2 があるのですが、確認したところどちらのバージョンでも新しいアクションを使うことが出来ました。
ただ、V1 は現在は新規では作成出来ないようですね。
とあり、マネジメントコンソールからCodePipelineをV2でしか作れなくなっているようです(何日からかは正確には不明)。CloudFormationからはV1で作れるようですが、両バージョンをサポートする旨の記述は特に当たらず、近い将来、CloudFormationからもV2しか作成できなくなるかもしれません。
AWS CodePipeline introduces new getting started experience
2024年10月10日、CodePipelineを作成する新しい方法が提供され、ユースケースごとに用意されたテンプレートを使って簡単にPipelineを構築できるようになりました(そうです)。まだ、触ったことはないですが、CodePipelineを使い始める方に対して敷居を下げる意図が感じられます。
AWS CodePipeline introduces skipping stage
2024年10月12日、ステージが失敗した際に、“Skip,” “Fail,”, “Rollback”のどの状態に遷移するか選べる機能が発表されました。テストやデプロイなどステージの性質の違いによって失敗した際の挙動を変えたい場合この機能が使えそうな感じがします。
(10月17日追記)
スキップ機能に関する機能のブログが出ていたのでリンクを追加しました。
この辺りは自分も近しいイメージです。
ユースケースについてはあまりドキュメントに記載がないのですが、挙動から推察するに失敗ではなく成功ではあるがステージを特定条件でスキップしたい場合に使います。
例えば特定ブランチ以外ではインテグレーションテストのステージをスキップするとか、ステージはスキップするけどもパイプラインとしては成功したものとして扱いたいような時に効果を発揮すると思います。
AWS CodePipeline supports automatic retry on stage failure
2024年10月16日、ステージのon failureライフサイクルイベントの結果として "Retry "を設定すると、リトライする設定ができるようになりました。「自動リトライは、一過性のエラーが発生する可能性のあるアクションを持つステージで役立ちます。」と書かれていますが、止めたいケースと自動リトライでパイプラインを通したいケースは要検討といったところでしょうか。
最近の動向まとめ
ここ1ヶ月(2024年9月下旬から10月中旬)でWhat's newで確認できるものだけでも5つのアップデートが発表されています。re:Inventとの兼ね合い等ある可能性があったとしてもCodePipeline V2の開発が活発であることは間違いないのかなと思います。
なぜ、CodePipeline V2のアップデートが活発なのか
- 仮説1: CodePipeline V1の採算が合わない
- CodePipeline V2の課金体系は非常にお財布に優しいです。ステージで実行されるCodeBuildの料金くらいしか気にする必要がなく、CodePipeline V2ではパイプラインの実行時間にも課金されるので料金的にはV1よりも高くなります。一方で、値上げ目的のためにここまで開発をするのかというと懐疑的で少なくともCodeBuildの料金は発生していたので、しないと思いますが、CodeBuildの値上げなど他の方法でもこのネックは解消できたはずであまり有力ではない気がします。
- 仮説2: CI/CDの基盤のシェアを拡大させたい(AWSで完結する機能を提供したい)
- 個人的な予想では、シンプルにこの要因が大きい気がします。どこかのカンファレンスで行われていた調査では、CI/CDにGitHub Actionsが最も使われていて、CodePipelineのシェアは高くなかった印象です。GitHubのユーザー側としては、CI/CDを所謂ベンダーロックされなくて済みますし、他のクラウドと組み合わせたCI/CDの構築が容易です。一方で、AWSとしてはCI/CDを含めた一連の開発フローを顧客に対してビルディングブロックとして提供したいはずですし、実際にCodeBuildからGitHub Actionsを実行できる機能のリリースなどもしています。一部のサービス終了などが話題にもなることはありますが、選択と集中の結果、CodePipelineは投資対象のサービスとして開発が活発に行われていると予想します。
まとめ
以上、最近CodePipelineのアップデートが多いなと思ったので、まとめ、振り返りとして書いてみました。これまで、CodePipelineを使ったことがなかった人や最近のアップデートに関して追えていない人、CI/CDに何を使うか迷っている人の参考になれば幸いです。
Discussion