現象
serverless-prod.yml は push: [master] で走り、prod ステージ（CloudFormation スタック github-notifications-slack-prod）へデプロイする。concurrency の指定が無いため、master へ短時間に複数回マージすると deploy が並走し、#112 と同じ理由で後発が落ちうる。
✖ ServerlessError2: Stack:.../github-notifications-slack-prod/... is in UPDATE_IN_PROGRESS state and can not be updated.
発生実績
未確認。#112（dev 側）と同じ構造から導いた、実際には未観測の問題。
deploy 自体は 1 分程度で終わるため、それより短い間隔で連続マージしない限り踏まない。ただし複数 PR をまとめてマージする際には十分起こりうる。
対応案
#112 の対応（PR #113）と同じく concurrency group を設定する。
concurrency:
group: serverless-prod
cancel-in-progress: false
dev 側と同様、cancel-in-progress: false にして実行中のデプロイを打ち切らないこと。
dev との違い
dev と違い、prod では 待機中 run のキャンセルが実害になる点に注意が要る。同一 group の待機中 run は最新 1 本しか保持されないため、3 回続けてマージすると 2 回目の run はキャンセルされる。
ただし prod は master の内容をデプロイするので、最新の run が通れば結果として最新の master が反映され、中間コミットの run が飛んでも最終状態は正しい。むしろ無駄なデプロイが減る。よって dev よりも素直に適用できる。
補足
未観測の問題であり緊急ではない。#112 の対応が入った後、同じ形を prod にも適用するかどうかを判断すればよい。
経緯
PR #113（#112 の対応）のレビュー中に、スコープ外の同種の問題として切り出した。
現象
serverless-prod.ymlはpush: [master]で走り、prod ステージ（CloudFormation スタックgithub-notifications-slack-prod）へデプロイする。concurrency の指定が無いため、master へ短時間に複数回マージすると deploy が並走し、#112 と同じ理由で後発が落ちうる。発生実績
未確認。#112（dev 側）と同じ構造から導いた、実際には未観測の問題。
deploy 自体は 1 分程度で終わるため、それより短い間隔で連続マージしない限り踏まない。ただし複数 PR をまとめてマージする際には十分起こりうる。
対応案
#112 の対応（PR #113）と同じく concurrency group を設定する。
dev 側と同様、
cancel-in-progress: falseにして実行中のデプロイを打ち切らないこと。dev との違い
dev と違い、prod では 待機中 run のキャンセルが実害になる点に注意が要る。同一 group の待機中 run は最新 1 本しか保持されないため、3 回続けてマージすると 2 回目の run はキャンセルされる。
ただし prod は master の内容をデプロイするので、最新の run が通れば結果として最新の master が反映され、中間コミットの run が飛んでも最終状態は正しい。むしろ無駄なデプロイが減る。よって dev よりも素直に適用できる。
補足
未観測の問題であり緊急ではない。#112 の対応が入った後、同じ形を prod にも適用するかどうかを判断すればよい。
経緯
PR #113（#112 の対応）のレビュー中に、スコープ外の同種の問題として切り出した。