🏃 Работаем нон-стоп: непрерывная интеграция и непрерывное развертывание кода (CI/CD)

Чего хочет заказчик от отдела разработки?

Если раньше бизнес хотел от производства увеличения объема продукта или сервиса, то это решалось масштабированием ресурсов: больше сырья, больше рабочей силы и т. д.

Пришло время и рынок «насытился» товарами. Вектор стал смещаться на конкурентность за счет быстрой подстройки под запросы конечного потребителя. У бизнеса появилась потребность не только делать что-то новое, но и чаще вносить изменения в существующий код.

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

Tesla, конечно, схитрила – сделала конвейер максимальной комплектации и зафиксировала софтом функционал, который приобретается в зависимости от потребности покупателя.

Для IT часто вносить изменения в продукт гораздо проще. Собственно, об этом и поговорим в статье.

Классический процесс разработки ПО

Классический процесс разработки ПО по принципу «часто и быстро» сложен в реализации. Передаем привет Каскадной модели разработки. На смену этой модели приходят Agile-методики, которые позволяют короткими спринтами накатывать изменения на минимальный прототип ПО.

Как раз организация CI\CD процесса и позволяет максимально быстро осуществлять большое количество изменений на каждом спринте.

Оптимизация процесса разработки ПО на частые релизы и изменения

Разберем подробнее:

1. Continuous Integration (непрерывная интеграция). Базовая опция – это автоматические тесты кода вашего нового функционала и возможность автоматического отката (в случае плохих тестов) обратно.
2. Continuous Deployment (непрерывное развертывание). Базовая опция – это развертывание кода нового функционала в тесте, а затем в продуктивном окружении.

Чтобы увидеть полную картину, взглянем на схему процесса CI\CD:

Для реализации необходимы следующие компоненты:

1. Git – система контроля версий.
2. Artifact Repository – система хранения артефактов сборки. По сути, это может быть общая файловая система, доступная всем участникам процесса.
3. Deploy Server – ресурсы, на которых запускаются и тестируются изменения.
   

Теперь пройдемся по шагам процесса:

1. Разработчик написал в коде реализацию нового изменения и добавил код в систему контроля версий Git.
2. После добавления нового кода в Git код отправляется на сервер сборки.
3. Автоматически, после сборки на сервере, стартуют тесты для проверки нового изменения. Результаты сохраняются в Artifact Repository.
4. Артефакты отправляются в первый Deploy Server. Новый функционал развертывается в тестовой среде и опять же тестируется. Тестовая среда, в данном случае, – максимально идентичная к продуктивной среде, но без real-time пользователей.
5. Артефакты отправляются во второй Deploy Server. Новый функционал развертывается уже в продуктивной среде, где находятся real-time пользователи. Это последний шаг в процессе доставки нашего изменения.

Что в итоге: большое количество тестов (автоматических тестов, без участия человека), две среды исполнения Non-Prod и Prod и общий Git.

Процесс CI\CD (его еще называют конвейер) позволяет:

1. Исключить человеческий фактор на этапах тестирования, тем самым ускоряя его.
2. Система контроля версий позволяет хранить в себе все изменения, т. е. исключается потеря информации и всегда можно откатиться обратно.
3. Non-Prod и Prod среды позволяют отловить баги до того, как они попадут к real-time пользователям и нарушат функционал основного сервиса или приложения.

Данная статья первая в цикле из трех статей посвященных CI\CD. В следующий раз на практике рассмотрим реализацию Continuous Integration и Continuous Deployment.

Материалы по теме

• ТОП-10 актуальных книг по DevOps: от новичка до профессионала
• Современный подход к кибербезопасности: как внедрить в компании методики DevSecOps?
  
• Путь в профессию: интервью с инженером DevOps