Принципы непрерывной доставки
Как уже упоминалось здесь,
Ниже приведены принципы непрерывной доставки.
Every build is a potential release
Eliminate manual bottlenecks
Automate wherever possible
Have automated tests you can trust
В традиционном процессе сборки, без использования подхода непрерывной доставки, мы фиксируем код в основной ветви по нескольким причинам, главным образом для совместной работы разработчиков и тестировщиков.
Что касается первого принципа, как каждый коммит может стать потенциальным релизом?
2 ответа
Это довольно просто - если вы создали коммит и отправили изменения в master, а затем запустили сборку и все ваши автоматические тесты были успешно выполнены, то эта сборка может быть использована как релиз.
Таким образом, этот принцип больше связан со сборкой, чем с фиксацией, но если вы настроили запуск сборки для каждого изменения, переданного мастеру (Automate wherever possible принцип), то в данном случае это синоним.
Непрерывная доставка является продолжением непрерывной интеграции, см. Как непрерывная доставка связана с непрерывной доставкой / развертыванием?, И из практики CI:
Каждый коммит должен основываться на машине интеграции
Так что да, в CI/CD будет создаваться каждый коммит, и, если все критерии CD выполнены (акцент на потенциал!), Коммит доставляется (или может быть развернут, если D в CD стоит для развертывания). Если нет, то проблема должна быть решена.
Могут быть исключения, например, из-за бизнес-требований или ограничений ресурсов, в которых конвейер доставки / развертывания не запускается для каждой успешной фиксации CI. Но это усложняет выявление и исправление регрессий.
Но фиксация изменений с зависимостями от других, еще не зафиксированных изменений (как упомянуто в комментариях) не совместима с методологией CI/CD. Фиксация незавершенного выполнения в таком контексте все еще возможна с использованием функциональных переключателей / флагов и / или методов ветвления за абстракцией, которые могут скрывать временно неудовлетворенные зависимости, чтобы не вызывать регрессии.