Эволюция разработки. Continuous Integration, Continuous Delivery
Старая модель разработки ПО
Это еще до появления CI/CD и т.п.
Один такой процесс называют итерацией.
Главные недостатки:
- Ручная интеграция
- Поздние обнаружения проблем
- Проблемы слияния кода
- Длительные циклы обратной связи
- Длинные итерации ⇒ медленный вывод бизнеса на рынок
Continuous Integration
CI - непрерывная интеграция - практика разработки, требующая от разработчиков интеграции кода в общий репозиторий несколько раз в день.
Это не просто автоматизация сборки, а новый подход, новые процессы, которые разрабы должны перенять/внедрить.
Основные принципы достижения непрерывной интеграции
- Единый центральный репозиторий
- Запуск сборки после пуша
- Автоматизация сборки
- Скорость сборки
- Компиляция и автоматические тесты
- Исправления кода в приоритетном порядке
- Совместная работа
- Уведомления в месседжеры
Главные плюсы CI
- Ускоряет процесс производства ПО
- Избавляет от человеческих ошибок
- Позволяет распараллелить процессы
- Проверка на дефекты происходит на несколько шагов раньше
- Удешевляет исправление дефектов
Единый центральный репозиторий
В старой модели разработки ПО разрабы работали в отдельных ветках и окончательная интеграция в основную ветвь происходила только в конце итерации.
Для достижения же CI все разрабы должны юзать один общий репозиторий в течении всей итерации.
Так снимается ответственность за слияние кода и его интеграцию с команды сборки и интеграции (Build & Integration Team), и эта ответственность распространяется среди всех разрабов.
В целом так проще, ибо интеграциями будут заниматься разрабы, которые лучше всех знают свой код ⇒ им проще, чем отдельной команде, которой придется сначала разбираться, что делать, а уже потом делать.
⇒ Команда сборки и интеграции не нужна больше - вместо нее будет Build & Integration Server:
Сервер сборки и интеграции
Чтобы убедиться, что код совместим и работает, его следует компилировать регулярно, то есть, после каждой фиксации кода любым разрабом в любое время, иначе говоря, запуск сборки после пуша.
Каждый раз, когда разработчик проверяет какой-либо код, он должен быть скомпилирован на сервере сборки и интеграции, а весь процесс сборки должен запускаться автоматически, когда любой разработчик делает какую-либо фиксацию (коммит).
Таким образом, процесс сборки будет централизован и автоматизирован, происходя на выделенном сервере сборки:
Все разрабы должны иметь доступ результатам сборки, чтобы быть в состоянии проверить правильность сборки их кода. После каждого билда результаты (артефакты) будут автоматически размещаться на сборочном сервере и все члены команды будут иметь доступ к этим артефактам. А при ошибке во время сборки разраб (сделавший коммит, который и вызвал ошибку) сразу получит уведомление (по почте/в slack и т.п.).
Автоматические тесты
Кроме компиляции кода, сборка должна иметь и автоматизированные тесты, которые будут работать с последней версией кода.
Тесты могут быть комбинацией:
-
автоматических модульных тестов (Automated Unit testing)
чтобы проверить, дает ли код ожидаемые результаты -
автоматических интеграционных тестов (Automated Integration testing)
для проверки правильной работы интеграции -
автоматических функциональных тестов (Automated Functional testing)
для проверки работы функциональности, необходимой бизнесу -
автотестов пользовательского интерфейса (Automated UI testing)
чтобы проверить, отвечает ли, например, интерфейс веб-приложения должным образом
Для UI тестов укапованный код нужно запустить во временной локальной среде.
Скорость сборки
Важным требованием для неприрывной интеграции является то, что весь процесс сборки, включая и запуск тестов, должен быть быстрым - не более нескольких минут.
Здесь уже пропадает нужда в команде тестировщиков и получается такая схема:
Минусы старого подхода и плюсы CI
| Старая подход разработки | Continuous Integration |
|---|---|
| Проблемы проявляются поздно | Проблемы быстро находятся и исправляются |
| Работа разработчиков блокируется дефектами | Дефекты исправляются сразу, нет задержек |
| Длинный цикл обратной связи | Автотесты. Короткий цикл обратной связи |
Pipeline
При внедрении CI реализуется концепция конвейера сборки и интеграции - Integration Build Pipeline:
Все шаги в этом конвейере могут выполняться паралельно.
Continuous Delivery
CI - это лишь половина жизненного цикла разработки ПО, вторая половина - эксплуатация.
Старая модель эксплуатации (operation)
Operations Team в этой модели получает инструкции по деплою в тестовую среду от разрабов; если QA Team подтверждает работоспособность развернутого ПО в тестовой среде, сертифицирует выпуск ПО и сообщает первой команде (Ops), чтобы те подготовили производственную среду (Prod) и задеплоили релиз согласно инструкции.
Минусы такого подхода
- Правильность инструкций не гарантирована
Ответственность за это лежит на разрабах, которые могут, к примеру, очевидные для себя вещи не указать в инструкции к деплою. - Разница в инструкциях для разных сред
- Человеческий фактор
Речь идет о ручном деплое - Простои (downtimes)
Continuous Delivery
Непрерывная доставка (CD) - практика разработки ПО, при которой ПО может быть запущено в производство (prod) в любое время; ибо необходимо всегда иметь возможность задеплоить в production-среду
Важным условием для CD является CI.
Конвейер выпуска (Release Pipeline):
В CD pipeline всё еще остался ручной этап - тестирование ПО в тестовой среде командой QA. Но это не нарушает концепцию CD, ибо, по-прежнему, ПО может быть задеплоено в prod в любое время, хоть и вручную (ибо деплой в прод еще согласовать нужно, например).
Конвейер сборки/интеграции и конвейер выпуска:
Плюсы CD / Какие проблемы решает CD
- Автоматизированные сценарии, которые тоже можно тестировать
- Скрипты выполняют необходимые шаги для окружения
- Снижение влияния человеческого фактора
- Быстрый выпуск продукта на рынок
Continuous Deployment
Continuous Deployment (непрерывное развертывание) - практика разработки ПО, в которой код постоянно и непрерывно автоматически деплоится в прод. Достигается засчет автоматических приемных тестов вместо QA Team.
В этом случае нет этапа с ручным одобрением - всё выполняется автоматически: от коммита до деплоя в прод (хоть и, в этом случае, к коммитам и слияниям в релиз ветку обычно имеют доступ не все разрабы).
Компания должна быть готова к такому подходу (если стоит задача применить такой подход в компании): должны быть настроены внутренние процессы, чтобы можно было уверенно сказать, что код, пришедший от разраба, достаточно покрыт тестами и прошел тщательное code review.
К слову, такие компании как Meta, Netflix, Twitter деплоятся в прод каждые 30 минут, то есть примерно 50 раз в день.
Просто оставлю это здесь…
