🏃 Работаем нон-стоп: непрерывная интеграция и непрерывное развертывание кода (CI/CD)
Разбираемся, как разрабатывать ПО короткими спринтами с автоматическими тестами и развертыванием в продакшене.
Чего хочет заказчик от отдела разработки?
Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д.
Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код.
Частые изменения, например, для промышленного сектора, очень трудозатратны. Нельзя перенастраивать постоянно производственный автомобильный конвейер под меняющийся спрос на рынке.
Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя.
Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье.
Классический процесс разработки ПО
Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО.
Как раз организация CI\CD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте.
Оптимизация процесса разработки ПО на частые релизы и изменения
Разберем подробнее:
- Continuous Integration (непрерывная интеграция). Базовая опция – это автоматические тесты кода вашего нового функционала и возможность автоматического отката (в случае плохих тестов) обратно.
- Continuous Deployment (непрерывное развертывание). Базовая опция – это развертывание кода нового функционала в тесте, а затем в продуктивном окружении.
Чтобы увидеть полную картину, взглянем на схему процесса CI\CD:
Для реализации необходимы следующие компоненты:
- Git – система контроля версий.
- Artifact Repository – система хранения артефактов сборки. По сути, это может быть общая файловая система, доступная всем участникам процесса.
- Deploy Server – ресурсы, на которых запускаются и тестируются изменения.
Теперь пройдемся по шагам процесса:
- Разработчик написал в коде реализацию нового изменения и добавил код в систему контроля версий Git.
- После добавления нового кода в Git код отправляется на сервер сборки.
- Автоматически, после сборки на сервере, стартуют тесты для проверки нового изменения. Результаты сохраняются в Artifact Repository.
- Артефакты отправляются в первый Deploy Server. Новый функционал развертывается в тестовой среде и опять же тестируется. Тестовая среда, в данном случае, – максимально идентичная к продуктивной среде, но без real-time пользователей.
- Артефакты отправляются во второй Deploy Server. Новый функционал развертывается уже в продуктивной среде, где находятся real-time пользователи. Это последний шаг в процессе доставки нашего изменения.
Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git.
Процесс CI\CD (его еще называют конвейер) позволяет:
- Исключить человеческий фактор на этапах тестирования, тем самым ускоряя его.
- Система контроля версий позволяет хранить в себе все изменения, т. е. исключается потеря информации и всегда можно откатиться обратно.
- Non-Prod и Prod среды позволяют отловить баги до того, как они попадут к real-time пользователям и нарушат функционал основного сервиса или приложения.
Данная статья первая в цикле из трех статей посвященных CI\CD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment.