У меня есть один репозиторий с множеством интеграционных интерфейсов, которые мы развертываем на azure. Мы используем Git Flow - master (для производственных развертываний), разработка (для выпусков в нашей тестовой среде), Release-x ветви (для выпусков для UAT) и Feature-x ветви для нового кода.
Разработчики разветвляются, чтобы создавать Feature-x ответвлений. Когда функция завершена, мы создаем запрос на извлечение и объединяем его с Develop, где запускается процесс CI / CD и развертывается в TST, где мы проводим тестирование дыма.
Когда он будет готов для UAT мы создаем Release-x ветвь Develop и процесс CI / CD развертывает его в нашей среде UAT. Все исправления выполняются непосредственно в ветке Release-x .
Когда UAT завершен и подписан, мы объединяем выпуск с разработкой и мастер, где процесс CI / CD запускается и разворачивается, развивается в TST (снова) и мастер в PROD.
Проблема, которую мы находим, заключается в том, если, например, кто-то работает над новым функция для существующего интерфейса, который был развернут в PROD и создает для него PR (так что теперь он находится в ветке разработки), и кто-то еще вскоре после этого создает ветку релиза для другой функции, которая готова для UAT и PROD. новая функция от первого разработчика, которая будет развернута в UAT и PROD как часть конвейеров CI / CD, уже настроена !!! что мы не хотим, потому что он не прошел UAT или не был одобрен для PROD.
У нас есть шлюзы одобрения как для версий UAT, так и для PROD, но это означает, что утверждающему необходимо знать, что развертывать, а что - не развертывать на каких-либо данный момент, т. е. новая функция, которая была в ветви разработки (а теперь и в ветке релиза) - которая не готова к релизам UAT или PROD, но другая функция, которая готова готова для развертывания.
что не так с тем, что мы делаем?
Единственный способ, как я могу решить, это исправить, это иметь отдельные репо на интерфейс, но у нас более 50 интерфейсов.