Ну получается что да.

Так сделайте типичный мьютекс. На программном уровне запретите параллельный деплой. Сделайте чатик, куда будет писаться что деплой начат и всё такое

Так и делаем👍

Думал может кто по другому решает проблему

Ну в таком пайплайне когда кто угодно может деплоить на прод особо других вариантов нет.

Я так понимаю

Jenkins это умеет и делает

Вы не rsync-ом же деплоитесь? Деплой-тул какой?

Мы пока на хероку пайплайнс, все простенько

А что дженкинс делает?

Решает проблему автобилда, автотестов, конкурентного деплоя.
Там где я работал и был настроен дженкинс - проблем как ты описываешь не было.
Кейсы:
1) Ты запушил в ветку. должны пройти автотесты. Ты в дженкинсе кликаешь кнопку "build now" в целевой ветке, он билдит и показывает успешен ли билд. Ты можешь в билд включить автотесты. Ты также можешь настроить хук в своём гит-репозитории, чтобы он дёргал дженкинс, чтобы не нажимать кнопку вручную. Итог - у тебя всегда есть индикация билд успешен или нет, и так по каждой ветке. Ну либо выборочно.
2) Ты деплоишь на прод. В репозитории смержил ветку в мастер, в дженкинсе смотришь какие билды в мастер сейчас выполняются (если кто другой деплоит). Если никто - жмёшь "build now" в ветке мастер. Происходит деплой. Ура. Если нажмёшь "build now" во время чужого деплоя - предыдущий билд+деплой отменится твоим.

Вот ключевой момент по моему вопросу это то что у вас чужой деплой отменяется твоим

Только не совсем всеж отвечает на требования

У нас все нормальные работали в команде, никто не отменял чужой деплой на прод своим, все дожидались окончания.

Так что это вопрос адекватности коллег

Проблема что сервер знает только о факте билда, как только билд выполнен следующий модет свое деплоить

Я же говорю что есть необходимость пр держать пайплайн на некоторое время

И к тому же сам пайплайн состоит из двух ступеней - стейдж и прод

Да там всё это настраивается. Сколько надо ступеней - столько и делаешь.

Понятное дело, только время не настроишь :)