Введение

Скорость и качество сборки продукта являются основными конкурентными преимуществами в разработке программного обеспечения. Поэтому новая концепция CI/CD - Continuous integration and Continuous delivery - непрерывная интеграция и непрерывная доставка - начала вытеснять архаичные модели программирования, такие как императивная, структурная или модульная. Она помогает минимизировать ошибки, увеличить темпы сборки и качество разрабатываемого продукта.

Что такое CI/CD

CI/CD - это одна из практик DevOps, которая подразумевает непрерывную интеграцию и доставку. Этот набор принципов разработан для повышения удобства, частоты и надежности развертывания программного обеспечения или изменений продукта. CI/CD относится к agile-практикам и позволяет разработчикам уделять внимание реализации бизнес-требований, качеству кода и безопасности продукта. Цели CI/CD: обеспечение последовательного и автоматизированного способа сборки, упаковки и тестирования продуктов или приложений; автоматизация развертывания в различных средах; минимизация ошибок и проблем.

Принципы CI/CD

Существует четыре руководящих принципа CI/CD.

1)Разделение ответственности. Каждый из участников процесса разделяет ответственность за определенные этапы жизненного цикла продукта. Проектируется бизнес-логистика, реализуются сквозные функции, проводятся приемочные испытания и организуется логистика кода.

2)Снижение рисков. Каждая команда, участвующая в разработке продукта, стремится снизить риски - контролируется правильность бизнес-логистики, проверяется пользовательский опыт, улучшается хранение и обработка данных и т. д.

3)Сокращение цикла обратной связи. Разработчик и клиент должны стремиться к увеличению скорости внесения изменений и утверждения правок. Сборка и тестирование кода могут быть автоматизированы. А в ситуациях, когда требуется участие человека, можно минимизировать количество информационных посредников.

4)Реализация среды. Разработчики должны иметь общее рабочее пространство с основной и вспомогательной ветками для контроля версий и качества, приемлемости, отказоустойчивости и т.д.

Этапы CI/CD

Методология CI/CD предполагает разделение процесса разработки на семь этапов.

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

2)Сборка. Выбранная система контроля версий инициирует автоматическую сборку и последующее тестирование проекта. Триггеры для активации сборки могут быть настроены самостоятельно. Для автоматизации сборки используется Jenkins или другой инструмент.

3)Ручное тестирование. После того как система CI проверит работоспособность тестовой версии, код передается для ручного исследования.

4)Релиз. После ручного тестирования в сборку вносятся исправления. Далее происходит выпуск версии кода для клиентов.

5)Развертывание. На этом этапе текущая (рабочая) версия кода размещается на производственных серверах разработчика. Клиент может взаимодействовать с программой и изучать ее функции.

6)Поддержка и мониторинг. Продукт начинает использоваться конечными пользователями. В то же время разработчики продолжают его поддерживать и анализировать работу пользователей.

7)Планирование. На основе пользовательского опыта разрабатывается новая функциональность и составляется план улучшений. После этого разработчик начинает писать код - и цикл замыкается.

Плюсы и минусы CI/CD

Минимальное время от запроса клиента до запуска в эксплуатацию. Методология сокращает время запуска обновлений до нескольких дней (в некоторых случаях - недель). Благодаря этому разработчики получают возможность быстрее тестировать инновации и внедрять решения быстрее конкурентов.

Возможность проверять варианты. Оперативное тестирование и множество итераций помогают разработчику быстро выявить варианты, не имеющие перспектив, даже на начальных этапах.

Качество результата. Проведение автоматизированного тестирования помогает выявить ошибки и другие проблемы на самых ранних стадиях разработки. При стандартном подходе к выпуску релизов это сделать сложно или невозможно.

Требования к опыту. Теоретически все корпоративные ИТ-системы можно перевести на CI/CD. Но на практике, чтобы получить результат, необходим первичный опыт работы с методологией, а также правильная организация перестройки всех процессов.

Сложность обеспечения взаимодействия. Непрерывное обновление и непрерывная доставка должны быть четко скоординированы, что возможно только после тщательной настройки взаимодействия между специалистами всех уровней.

CI/CD - шумиха или необходимость?

CI/CD - одна из самых хиповых методологий разработки ПО. Впервые идея ее внедрения была озвучена в 2006 году, а уже в 2008 году эксперты высказали мнение, что ее популярность связана с развитием облачных сервисов. В то же время желание использовать ее для решения других задач объясняется не популярностью, а преимуществами системы - возможностью быстро координировать и внедрять обновления на основе пользовательского опыта.

В условиях жесткой конкуренции эта методология становится необходимостью, поскольку позволяет значительно сократить время от разработки кода до выпуска продукта. CI/CD подходит для задач, связанных с веб-разработкой, omnichannel-решениями, электронной коммерцией и другими сложными компонентами frontend и middleware. Однако внедрение Continuous integration & Continuous delivery не всегда оправдано - например, в областях с редким обновлением программного обеспечения методология себя не оправдает.

Результат

CI/CD - это не просто методология, но и очень хороший инструмент для команды разработчиков. Чем дольше планируется развивать и поддерживать проект, тем полезнее будет иметь хорошо продуманный CI/CD. Все ресурсы и затраты на этот инструмент окупаются на расстоянии. С его помощью неоспоримо сокращается время выхода на рынок, а также снижается вероятность совершения ошибки. Самое главное - поддерживать инструмент в хорошем состоянии.