ci: prod デプロイを直列化して CloudFormation の競合を防ぐ（#114） - #115
Merged
Conversation
master へ短時間に複数回マージすると deploy が並走し、スタックが UPDATE_IN_PROGRESS のままで後発が落ちうる。dev 側（#112 / PR #113）と同じ 構造の問題。 serverless-prod に concurrency group を設定して直列化する。dev とは別の group 名にして、環境をまたいで待たされないようにする。実行中のデプロイを 中途半端に打ち切らないよう cancel-in-progress は false にする。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoGxJDiZa8c2E3PVAnxbK8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
close #114
課題
serverless-prod.ymlはpush: [master]で走り、prod ステージ（CloudFormation スタックgithub-notifications-slack-prod）へデプロイする。concurrency の指定が無いため、master へ短時間に複数回マージすると deploy が並走し、#112 と同じ理由で後発が落ちうる。未観測の問題だが、deploy 自体は1分程度で終わるため、複数 PR をまとめてマージする際には十分起こりうる。
変更内容
PR #113（dev 側）と同じ形で concurrency group を設定する。
dev とは別の group 名にしている。 別スタックなので互いに競合せず、同じ group にすると環境をまたいで無用に待たされる。
dev との違い
dev 側では「待機中の run が2本以上になると古い方がキャンセルされ、その PR が deploy 未検証のまま残る」ことを既知の制約として挙げた。prod では同じ挙動が実害にならない。
prod がデプロイするのは master の内容なので、3回続けてマージして中間の run がキャンセルされても、最新の run さえ通れば最終状態は正しく反映される。むしろ中間コミットへの無駄なデプロイが減る。
そのため dev よりも素直に適用できると判断した。
動作確認
concurrencyが意図した値でパースされることを確認（group: serverless-prod/cancel-in-progress: False）serverless-dev）と group 名が重複していないことを確認補足
この PR がマージされると、その push 自体が新しい
concurrency設定下での最初の prod デプロイになる。Generated by Claude Code