CodePipelineの検出オプションであるイベントとポーリングを比較してみた
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、つくぼし(tsukuboshi0755)です!
CodePipelineの検出オプションには、イベントとポーリングの2種類が存在します。
最近CodePipelineを触っている中で、上記2つの違いについて調べる機会があったので、本記事でまとめてみたいと思います！
CodePipelineの検出オプションとは
CodePipelineの検出オプションとは、CodePipelineのソースプロバイダーでソースコードの変更があった際の検出方法を指します。
ソースコードの変更が検出されると、対象のパイプラインが自動で開始されます。
現在検出オプションは、以下の2種類が存在します。
- イベント
- ポーリング
コンソールでCodePipelineを作成する際は、以下の赤枠部分でAmazon CloudWatch Events(イベント)またはAWS CodePipeline(ポーリング)のいずれかを選択します。
なお公式ドキュメントでは、以下に記載があります。
以下、各々の検出オプションについて説明します。
ポーリング
従来から存在するCodePipelineの検出オプションです。
CodePipelineの検出方法は、当初はポーリングしかサポートされていませんでした。
コンソールでAmazon CloudWatch Eventsを選択した場合、CodePipelineのPollForSourceChangesパラメータがtrueで設定されます。
上記のパラメータを設定する事で、CodePipelineが定期的に、ソースコードが変更されているか確認するようになります。
イベント
ポーリングが登場してからしばらくしてサポートされた、新しいCodePipelineの検出オプションです。
公式ドキュメントでは以下の点から、CodePipelineの検出オプションとしてポーリングではなくイベントを選択する事を推奨しています。
・イベントは、平均して大幅に高速化されます。定期的なチェックが必要なポーリングとは異なり、イベントでは、発生直後にパイプラインを開始します。
・制限の引き上げ。変更をポーリングするパイプラインに比べて CodePipeline は、より多くのイベントベースのパイプラインをサポートできます。
・多数のパイプラインでのエクスペリエンスの向上。お客様によっては、多数のパイプラインでのコードの変更を調べるためにリポジトリを継続的にポーリングすることで、スロットリングまたはコストの増加が発生する場合があります。これらの問題はイベントを使用することで回避できます。
コンソールでAmazon CloudWatch Eventsを選択した場合、CodePipelineのPollForSourceChangesパラメータがfalseで設定されます。
また、CodePipelineのソースコード変更を検出するための、EventBridge関連のサービスが自動作成されます。
例えば、CodePipelineのソースプロバイダーにCodeCommitを選択した場合、以下のリソースが自動作成されます。
EventBridgeルール
- イベントパターン
- 以下のjson定義に基づいたカスタムイベントパターンが作成される
{
"source": ["aws.codecommit"],
"detail-type": ["CodeCommit Repository State Change"],
"resources": ["<CodeCommitリポジトリのARN>"],
"detail": {
"event": ["referenceCreated", "referenceUpdated"],
"referenceType": ["branch"],
"referenceName": ["<ブランチ名>"]
}
}
- ターゲット
- タイプ：CodePipeline
- 入力：一致したイベント
- ARN：(CodePipelineのARN)
- ロール：(自動作成されるIAMロール名)
IAMロール
- IAMポリシー
- 以下に基づいたカスタムポリシーがアタッチされる
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:StartPipelineExecution"
],
"Resource": [
"<CodePipelineのARN>"
]
}
]
}
検出オプション設定時の注意点
検出オプションを設定する際は、注意点があります。
それはCodePipelineの設定次第で、イベントとポーリングの両者を同時にON、または同時にOFFにできてしまうという事です。
以下各々の場合について、説明します。
同時にONにした場合
イベントとポーリングを同時にONにすると、ソースコードが変更された場合パイプラインは2回実行されるようになります。
PollForSourceChangesパラメータがtrueになっており、かつCodePipeline用のEventBridge関連リソースが既に作成されている場合に起こります。
公式ドキュメントでも、以下のように説明されています。
同時にOFFにした場合
イベントとポーリングを同時にOFFにすると、ソースコードが変更されてもパイプラインは実行されません。
PollForSourceChangesパラメータがfalseになっており、かつCodePipeline用のEventBridge関連リソースが作成されていない場合に起こります。
なお上記の「イベントとポーリングが同時にON/OFFになる」事象は、CloudFormationやTerraform等のIaCツールを使ってCodePipelineを作成すると、コンソールと挙動が異なるため遭遇しやすいみたいです。
下記のブログでも、同様の事象について紹介されているのでご参照ください。
最後に
今回はCodePipelineの検出オプションについてまとめてみました。
個人的には、コンソールで各々の検出オプションを選択した際の挙動が分かりにくいので、例えば「CodePipelineポーリング：有効化/無効化」「EventBridgeリソース作成：する/しない」みたいな形で設定項目を2つに分けてほしいな、と勝手に考えたりしてました。
ただポーリングは既に検出オプションとしては非推奨となっているので、将来的にポーリングが廃止され、検出オプションとしてはイベントのみになるかもしれないですね。
なおCodePipelineを使用されている方で、検出オプションとしてポーリングを選択されている方がいらっしゃれば、以下で検出オプションをイベントに変更できるので検討して頂くと良いかもしれません。
以上、つくぼし(tsukuboshi0755)でした!
