Общий вопрос по семантическим версиям версий с использованием конвейера CI / CD

Question

Мне еще предстоит найти четкое руководство по семантическому версионированию выпусков программного обеспечения с использованием CI / CD Azure DevOps (Server).

Я понимаю, что я бы настроил конвейер CI для нашей команды, чтобы мы могли получитьпреимущества уведомлений о сбоях сборки, выполнении тестов, охвате кода, статическом анализе кода и еще больше полезных вещей.

Конвейер CD обнаруживает конвейер CI, выполняя артефакты в различных средах после их завершения.

Использование такого подхода, кажется, не имеет смысла для меня.А как насчет сборок, которые терпят неудачу, потому что разработчик не обратил внимания или что команда хочет отказаться?Такие сборки не найдут своего пути в производство, но могут использовать номера версий, что приведет к пробелам в нашей схеме управления версиями.

Каков ваш опыт или подход для семантической версии версий программного обеспечения с использованием конвейеров CI / CD?Вы вишневый сбор?У вас есть отдельный сборочный конвейер для сборок релизов?

Answer 1

1. Неудачные сборки не развертываются.Для сборок, которые успешно выполняются, но не проходят тестирование качества или интеграционное тестирование при развертывании в более низких средах, вы можете поставить шлюзы утверждения, чтобы кто-то должен был утвердить релиз, прежде чем он перейдет в более высокие среды.

2. Если высоберите версию 1.0.1 своего приложения и разверните его в dev, и это нехорошо, это не значит, что версия 1.0.1 не существует.Это существует.Он состоял из определенных активов кода.Это было плохо, и ваши пользователи никогда его не увидят, но это отлично .Если пользователи видят версию 1.0.1, переходят на 1.0.94, почему это важно?