В разработке любого софта есть два подхода: итеративный и непрерывный. Они отличаются методами работы и сложностью организации. Если будете работать в сфере ИТ, наверняка вам встретятся оба подхода.
Итеративный подход
Итеративный — это значит, что разработка идёт итерациями, отдельными шагами. Разработчики пишут код, потом проверяют его и выпускают новую версию программы. После этого отдыхают, и снова за работу — пилить следующую версию.
👉 В итеративном подходе заказчик или пользователи видят результат только в самом конце этапа и до этого пользуются старой версией.
Непрерывный подход
Непрерывный подход — это когда разработка идёт маленькими шажками каждый день, и каждый день в репозиторий отправляются какие-то мелкие изменения. Если вы не знаете, что такое репозиторий, почитайте наш гит-словарик, с ним будет гораздо проще.
👉 При непрерывном подходе пользователи каждый день получают новую версию, которой уже можно пользоваться.
Непрерывная интеграция
Чтобы непрерывная разработка работала как задумано, для неё нужно подготовить особые условия работы:
- репозитории и и гит-системы;
- налаженные системы автотестов;
- систему отчётов и обратной связи, чтобы программисты сразу могли видеть результаты своей работы или если что-то пойдёт не так.
👉 В программировании непрерывный подход называют непрерывной интеграцией (Continuous Integration, CI), потому что результаты работы за день сразу интегрируются в мастер-ветку продукта.
Непрерывная доставка
Ежедневная внутренняя сборка ещё не означает, что эта версия сразу попадёт к пользователям. Для этого нужно настроить другие процессы:
- автоматизированную сборку новой версии в отдельной ветке, чтобы на неё не влияли постоянные обновления;
- интеграционное тестирование;
- отправку новой версии в магазины приложений или на сайт;
- автоматическое обновление в тех системах, где это предусмотрено архитектурой.
👉 Такие действия называют непрерывной доставкой (Continuous Delivery, CD), потому что они доставляют пользователям свежие результаты работы программистов. Обычно эти две аббревиатуры, CI/CD, используются вместе, потому что это взаимосвязанные процессы. Непрерывная интеграция постоянно выдаёт свежие версии, а непрерывная доставка делает их доступными для пользователей.
Кто это настраивает
Почти всё из этого зависит от тестировщиков и девопсов.
Тестировщики следят за тем, чтобы все новые изменения работали без сбоёв и не ломали то, что было до этого. Так как новые версии появляются каждый день, то тестировщикам нужно переложить как можно больше задач на автоматическое тестирование. Это позволяет держать темп и тестировать вручную только сложные моменты или то, что не удалось покрыть автотестами.
Задача девопсов — подготовить среду разработки и тестирования, чтобы всё работало максимально автоматически:
- коммиты сами проверялись перед попаданием в мастер-ветку;
- новые версии сами собирались перед тестированием;
- тесты сами запускались после сборки;
- отчёты сами отправлялись в нужные команды после тестирования;
- протестированные сборки сами попадали в магазины приложений и на сайт продукта.
Зачем это нужно
Смысл CI/CD в том, чтобы не откладывать процесс финальной сборки на самый конец, как это делается в итеративном подходе, а собирать все кусочки по чуть-чуть, но сразу. Это позволяет пользователям постоянно получать свежие версии программ, а разработчикам — не опасаться того, что на этапе финальной сборки всё сломается.
Кому не подходит
Непрерывная разработка — дорогой и сложный процесс, который не подходит маленьким командам с ограниченным бюджетом. Для настройки и запуска такого процесса нужно нанимать много разных специалистов, а это дорого и не всегда оправданно.
А ещё есть области, в которых важна не скорость появления новых фич, а стабильность — медицина, космонавтика, пассажирские перевозки. Там новые версии могут выходить раз в три года, и это нормально — главное, чтобы работало без сбоёв.
