Continuous Integration & Continuous Delivery. Почему для собеседования в IT это нужно знать?

Continuous Integration

Continuous Integration (непрерывная интеграция (CI) — практика частой сборки и тестирования приложения с целью выявления ошибок на ранней стадии разработки. Если говорить простым языком, то каждый раз, когда разработчик хочет внести изменения в общий код проекта, эти изменения подхватываются системой контроля версий, добавляются в сборку проекта и добавляются к основной ветке разработки. Такое добавление еще называют слиянием (от англ. merge). После каждого слияния (которое проходит по несколько раз в день) в системе происходит автоматическая сборка и тестирование (проверка производительности, надежности API, модулей кода). Таким образом, CI представляет собой автоматизированный процесс, в котором, как правило, используется специальное серверное ПО, отвечающее за поиск изменений в коде в системе контроля версий, сборку, развертывание и тестирование приложения. 

Основная задача, которую решает CI, — это как можно более частое обновление кода проекта. При частом обновлении у разработчиков будет больше времени, чтобы выявить и исправить проблемы. К тому же сделать это будет гораздо проще благодаря системе контроля версий, с помощью которой можно однозначно определить версию проекта, начиная с которой появился дефект, и проследить историю изменений. 

При непрерывной интеграции большое внимание уделяется  автоматизации тестирования. Это является одной из самых серьезных проблем.

Хорошим выходом из такой ситуации является добавление автоматических тестов для всех новых функций по мере их разработки. Этим занимаются, как правило, тестировщики-автоматизаторы. При этом разработчик, работая над новой функциональностью или исправлением ошибки, также пишет так называемые unit-тесты для отдельных частей кода. Иногда тесты пишутся до начала самой разработки (test driven development или TDD). 

Непрерывная интеграция подразумевает и непрерывное тестирование, которое включает в себя не только автоматизацию, но и включение автоматического тестирования в конвейер CI/CD. Некоторые тесты могут выполняться до или во время запуска CI-конвейера. С другой стороны, существует целый блок тестов, для выполнения которых ПО должно быть уже развернуто в целевых средах, и их невозможно включить в конвейер CI/CD (например, тестирование производительности). 

Лучшие практики CI включают в себя:

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

К основным инструментам CI можно отнести Jenkins, TeamCity, GitLab CI и др.

• Jenkins (сайт) — ведущий бесплатный сервер автоматизации с открытым исходным кодом, написанный на языке Java. У него богатый набор функций для автоматизации задач сборки, тестирования, развертывания, интеграции и релиза программного обеспечения. Функциональные возможности системы можно расширить с помощью большого количества плагинов. Наравне с GitLab является лидером на рынке.
• GitLab (сайт) — веб-приложение и система управления репозиториями программного кода для Git. Помимо функции хранения, имеет собственные механизмы для непрерывной интеграции (CI) и доставки (CD) кода, а также систему отслеживания ошибок. Доступна установка платной и бесплатной версии продукта. 
• TeamCity (сайт) — серверное программное обеспечение от компании JetBrains, написанное на языке Java, билд-сервер для обеспечения непрерывной интеграции. Этот программный продукт является платным.

Continuous Delivery

Целью Continuous Delivery (непрерывная поставка; CD) является мгновенная доставка изменений версии продукта в эксплуатацию после изменения кода. CD значительно повышает time to market за счет быстрой обратной связи, автоматизации тестирования и более быстрой валидации бизнес-идей.

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

Процесс непрерывной доставки связан с еще одним термином: непрерывное развертывание Continuous Deployment (CD). Данный подход предполагает, что каждое изменение кода, прошедшее тестирование, попадает сразу к клиенту. Непрерывное развертывание — это хороший способ наладить обратную связь с клиентом. Разработчики могут сосредоточиться на написании ПО, и как только оно готово, клиент сразу же получает его в работу.

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

Условно подход CI/CD можно разделить на 7 этапов.

1. Создание. Программисты пишут определенную часть кода, а затем тестируют в ручном режиме на локальной машине. Если тест пройден успешно, то эта часть кода попадает в основную ветку разработки благодаря CI.
2. Сборка. На втором этапе используют специальное ПО для контроля версий продукта. Программа запускает автоматическую сборку с внесенными изменениями, а после тестируется полученный код. 
3. Ручной тест. После прохождения автотеста в программном обеспечении продукт отправляется на проверку к команде тестировщиков. Они вручную проверяют написанный код и ищут баги. Стоит отметить, что в последнее время намечается общемировая тенденция отказа от данного этапа, а следовательно, и от профессии  ручного тестировщика. Происходит это по ряду причин, таких как развитие смежных профессий (автоматическое тестирование, QA), а также развитие и улучшение инструментов, позволяющих построить надежный конвейер CI/CD. 
4. Релиз. После успешного окончания третьего этапа код поступает в релиз. Создается рабочая сборка для обновления текущего программного продукта до актуальной версии.
5. Развертывание. Полученное обновление публикуется на официальных серверах и, таким образом, доставляется клиенту.
6. Поддержка и мониторинг. Разработчики отслеживают отзывы клиентов и готовят список будущих изменений.
7. Планирование. На последнем этапе создается утвержденный список изменений для следующих версий. По окончании данного шага цикл разработки заканчивается и начинается заново.

Всегда ли нужен CI/CD?

С точки зрения продаж непрерывная интеграция и непрерывная поставка важны, так как выглядят весьма привлекательно для клиента: благодаря CI/CD-конвейеру ускоряется процесс разработки ПО, ошибки обнаруживаются на ранних этапах разработки, а внесенные изменения мгновенно доставляются клиенту. Внедрение CI/CD может принести в инженерные команды высокий моральный дух, лучшую коммуникацию и др. (State of DevOps Report от Puppet дает несколько инсайтов на эту тему). Сочетание CI/CD представляет собой одну из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности. 

Однако на практике не все выглядит так радужно. Если основная проблема CI — это автоматизация тестирования, то для CD — это техническая сложность развертывания.

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

Чтобы решить данную проблему, используют специальное ПО для автоматизации развертывания — Docker. Docker — это платформа для разработки, доставки и запуска контейнерных приложений. Docker позволяет создавать контейнеры, автоматизировать их запуск и развертывание, управляет жизненным циклом. В свою очередь, контейнер — это способ упаковать приложение и все его зависимости в единый образ. Контейнеры позволяют отделить приложение от инфраструктуры: разработчикам не нужно задумываться, в каком окружении будет работать их приложение, будут ли там нужные настройки и зависимости. Они просто создают приложение, упаковывают все зависимости и настройки в единый образ. Затем этот образ можно запускать на других системах, не беспокоясь, что приложение не запустится.

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

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

Помимо технической сложности, внедрение CI/CD накладывает определенные ограничения на команды при выборе технологий, процессов и инструментов. Как итог — в компании появляется новая роль: DevOps-инженер, который определяет архитектуру CI/CD-конвейера, обеспечивает мониторинг и логирование, предоставляет командам разработки инфраструктуру и инструменты деплоя и пр. Кроме того, на практике применение CI не всегда выгодно для проекта, особенно в тех случаях, когда достаточная автоматизация сборки и тестирования невозможна по тем или иным причинам.

Прежде чем принимать решение о внедрении CI/CD-конвейера, стоит оценить его эффективность как минимум по трем главным метрикам.

1. Time and speed. В общем случае СI/CD позволяет существенно (при грамотной настройке) сократить lead time (lead time = cycle time + wait time) от момента запроса фичи до поступления ее клиенту.
2. Качество. Изменение в процентном соотношении или количестве failed deployments и багов после внедрения СI/CD. 
3. Деньги. ROI после внедрения, количество запускаемых экспериментов в единицу времени и др.

В заключение приведем основные плюсы и минусы CI/CD-конвейера. 

Главные плюсы CI/CD:

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

Главные минусы CI/CD:

• Обслуживание CI/СD-инструментов является дорогостоящим вложением.
• Изменения создают эффект домино. 
  • Одно небольшое изменение с CI/CD может повлиять на несколько различных взаимодействий в коде. То есть может вызвать проблемы в цепочках обслуживания. Таким образом, нужна дополнительная возможность откатить изменения при необходимости.
• Непрерывное изменение требует постоянного мониторинга и отчетности.
  • Изменения CI/CD влияют на платформу, на которой они развернуты. Мониторинг и отчетность в реальном времени необходимы для понимания и быстрого решения любых проблем. Если изменение ведет к некорректному поведению, вам нужно узнать об этом до того, как проблемы коснутся других служб.
• Обязательное наличие автоматизированного тестирования, без которого CI в принципе невозможен.
• Необходимость дополнительно координировать доставку изменений.
  • CI/CD предполагает, что любые изменения доводятся до пользователей максимально быстро. В таком случае, к примеру, служба поддержки практически не уведомляется о предстоящих изменениях и может не справиться с вопросами и жалобами клиентов.