【AWS CodePipeline】ソース管理のベストプラクティス

Question

AWS CodepipelineでDockerコンテナの自動ビルド、デプロイを実現しています。
Codepipelineの内容と役割は下記です。
CodeCommit：コンテナソース、ビルド、デプロイに必要な設定ファイルを管理しているリポジトリ
CodeBuild：buildspec.ymlをもとにコンテナimageを作成し、ECRにpushする
CodeDeploy：ECRにpushしたimageをもとに、デプロイする

CodeBuildにつけるimage tagには、Commit hashを利用しています。
CodeCommitのリポジトリにはコンテナ１、２の２つのソースを管理しています。

このとき、コンテナ１のソースだけ変えてCommitした場合、コンテナ２のimageも再ビルドされてしまいますよね？

これを回避できる方法は何かありますでしょうか。

Answer 1

最も簡単な方法はコンテナ1と2のビルドを別のパイプラインにすることじゃないでしょうか。

方法は色々考えられますけど、単純にコンテナ１と２のソースを混在させず別のリポジトリにするのが最もわかりやすいです。
それが避けられないなら何らかの条件でディレクトリごとにビルドを走らせるようにすることですが、CodeCommitを使う場合CloudWartch Events(EventBridge)でCodeBuildに送るのでそこでどうにかして絞り込めば、と考えました。
ただ、申し訳ないのですが普段CodeCommitを使っていないのでドキュメントを読んでも更新対象のファイルを絞り込む条件がちょっと明確にはわかりませんでした…（どなたか知ってたら補足いただきたく）
GitHubとかならWebhookの条件絞り込みでできるんですけどね…。

CodeCommitのイベントについては下記にあるので、条件で絞るならこちらを見ながら試してみてください。
参考
AWS CodeCommit のアクション、リソース、および条件キー

Comments

[tanaka_123]

ありがとうございます。
コンテナ１と２のソースを混在させず別のリポジトリに持ち、パイプラインを一つで運用する
というのは不可能でしょうか。
コンテナ１，２どちらのデプロイにも対応できるパイプラインです。

[yu_1985]

パイプラインの組み方によってはできなくもないと思いますが、そこまでして一つのパイプラインにする必要がありますかね？
もっともどのようにデプロイしたいのかがわからないので何とも言えませんが…。

[tanaka_123]

ありがとうございます。
コンテナ１、２のソースの混在を避けれない場合は、
「何らかの条件でディレクトリごとにビルドを走らせるようにすること」
ですが、この何らかの条件は、buildspec.ymlで条件分岐等で制御することになりますよね？

[yu_1985]

buildspec.yml自体ではそれはできないと思います。
あくまでもビルドが走ったときに何をさせるかを定義するものなので、ビルドがトリガーされるかどうかをそれをもって制御はできないかと。