Кто может внедрить ci cd в процессы компании

Введение

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

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

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

Так как на проекте не было CI и автотестов, то тестирование и развертывание производилось вручную. Как следствие, возникали проблемы:

• Разработчики не создавали и не запускали unit тесты на регулярной основе.
• На уровне автоматизации тестирования не было UI-автотестов.
• Тестирование осуществлялось вручную, при этом отсутствовал даже тест-план.

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

В итоге, мы приняли решение внедрить CI/CD отдельным внутренним проектом. Таким образом наша компания выступила драйвером данного процесса. В условиях ограниченного бюджета привлекли на данный проект вспомогательного менеджера, который отвечал только за внедрение CI/CD. Кроме того, на 1,5 месяца подключили к работе над проектом начинающего DevOps инженера, который во время своей стажировки смог создать техническое задание для внедрения CI/CD системы.

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

Подготовка к внедрению CI/CD

Вначале мы составили следующую документацию к проекту:

• Анализ среды окружения — в этом документе мы перечисляем все имеющееся оборудование и программное обеспечение, которое является результатом работы команды.
• Диаграмму развертывания — в этой диаграмме мы показываем на каком оборудовании какое ПО установлено и как оно взаимосвязано.
• Диаграмму процессов взаимодействия — в этой диаграмме мы показываем, каким образом организован процесс тестирования и поставки ПО на момент старта проекта.
• Диаграмму интеграции CI/CD — в этой диаграмме мы показываем, каким образом будет организован процесс тестирования и поставки после внедрения CI/CD.
• Диаграмму атомарных операций — это вспомогательная диаграмма, в которой мы разбили все операции в рамках CI/CD на небольшие атомарные операции — кирпичики, из которых в дальнейшем создавались pipelines.

Ниже мы рассмотрим эту документацию подробнее.

После разработки документации DevOps инженер приступил также к практическим работам по проверке концепции. В рамках данной задачи было сделано следующее:

• Полностью настроены стенды в виде двух виртуальных машин. Настройка включала в себя копирование сред окружения проекта.
• Установлен и настроен Jenkins.
• Настроены базовые элементы процесса развертывания.

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

1. Внедрение CI/CD стоит начинать сразу после первичного анализа и составления технического задания. Так как во первых существует риск того, что внедрение CI/CD так и останется техническим долгом — а команда при этом получит состояние выученной беспомощности, а во вторых внедрение CI/CD это долгий процесс, и результат будет не очень скоро, только когда наберется критическая масса обновлений. Поэтому лучше сразу выделять время на работу с техническим долгом и через некоторое время этот подход окупится сторицей.
2. Внедрять CI/CD лучше мелкими инкрементами. Тогда команда сможет почувствовать результат, получить необходимый опыт и быструю обратную связь, что позволит достичь лучшего результата.
3. В процессе работы был применен опыт, приобретенный в рамках другого проекта. Было проведено демо по применению скриптов на Groovy в CI/CD на Jenkins. Это стратегия нашей компании, когда опыт, полученный на одном из проектов суммируется и передается на другие проекты, позволяя таким образом пользоваться экспертизой не только конкретных инженеров проекта, а всей компании целиком.

Фидбек вспомогательного менеджера проекта:

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

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

Также важная часть моей работы — задавать вопросы, требующие взглянуть на проблему с нужной стороны и обеспечивать продвижение небольшими инкрементами. На проекте очень быстрый срок поставки, релиз происходят каждую неделю. Естественно, что в этом случае даже зная конечную цель легко можно потерять мотивацию, ведь процесс внедрения CI/CD не такой быстрый. Здесь помогает стратегия внедрение, через решение небольших задач и постановки конкретных вопросов. Например установить Jenkins, добавить автоматический прогон unit-тестов после каждого коммита, научится останавливать и запускать приложение на сервере и т.п. И такими инкрементами обеспечить постоянное продвижение к цели.

Как гласит японская пословица: быстро двигаться — это двигаться медленно, но постоянно.

Фидбэк от основного менеджера проекта:

Внедрение CI/CD на долгоиграющем проекте требует значительных усилий менеджмента. Особенно это актуально, если на проекте нет выделенного девопса и у команды не очень много опыта внедрения CI/CD. Дополнительный (независимый) менеджер, который фокусируется только на реализации CI/CD — очень хороший подход в такой ситуации.

Диаграмма развертывания

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

Анализ среды окружения

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

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

На проекте мы всегда анализируем среды окружения по следующей структуре:

• Поставщики сервисов: хостинги, хранилища данных, прочие облачные сервисы и т.п.
• Оборудование в наличии: в данном случае какие именно сервера есть на проекте.
• Важные программные элементы при деплое новой версии продукта:
  • Основные директории приложения.
  • Репозитории системы контроля версий.
  • Скрипт обновления конфигурации БД.
• Важные организационные элементы при деплое новой версии продукта:
  • Jira — как именно используется таск трекер при деплое новой версии продукта.
  • Cистема хранения бэкапов БД.

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

• что из себя представляет элемент;
• каким целям служит;
• какие риски есть в этом элементе окружения.

Диаграмма процессов взаимодействия

Данная диаграмма создана для того, чтобы сформировать четкое представление о внутренней организации процессов поставки ПО на проекте перед внедрением CI/CD. Тут важно учесть все моменты, так как наша задача заключается, в автоматизации и улучшении этих процессов. И если описывая состояние перед началом внедрения CI/CD, вы забудете какой-то важный момент — вполне возможна ситуация, когда ваше решение будет не оптимальным либо нерабочим.

Рисунок 2 – Диаграмма процессов взаимодействия Test

Рисунок 3 – Диаграмма процессов взаимодействия Live

Диаграмма интеграции CI/CD

Проанализировав текущую ситуацию поставке продукта, мы разбили всю систему на атомарные операции и объединили их в пайплайн. Атомарные операции это базовые операции, которые может выполнять Jenkins в нашей системе, такие как остановка сервера, копирование данных, операции с системой контроля версий и т.п. Из этих базовых операций в дальнейшем строится весь процесс CI/CD.

Прочие документы

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

• Описание стенда — в рамках проверки концепции мы все решения проверяли на стенде и этот документ описывает наш опыт по проверке концепции с. В частности какое оборудование, какое ПО и как именно надо использовать.
• Хроника активности по внедрению CI/CD на проекте.

Заключение

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

Спикер курса «CI/CD на примере Gitlab CI», Lead DevOps в Naviteq (ex. Onesoil and EPAM) Александр Довнар, рассказывает про CI, CD и еще раз CD.

Александр — AWS Community builder и сертифицированный архитектор, соведущий подкаста DevOps Kitchen Talks. 11+ лет работает в IT и сетях, из них 7+ лет — в Devops.

Статья подготовлена на основе вебинара Слёрма «CI/CD: как, зачем, для чего».

Начнем с того, что такое CI/CD. Для одних это методология, для вторых — процесс, для третьих — методика. Все эти термины звучат правильно, но в то же время не до конца раскрывают смысл.

CI/CD — это набор инструментов, практик, процессов и методологий, который:

• позволяет компаниям улучшить качество продукта;

• помогает увеличить скорость поставляемого продукта;

• в целом положительно сказывается на бизнес-метриках.

Жизненный цикл разработки

Говоря про CI/CD, в первую очередь стоит вспомнить про SDLC (Software development life cycle) — жизненный цикл разработки ПО. Как правило, этот цикл изображается в виде круга или замкнутой схемы, на которых можно увидеть от 5 до 7 этапов.

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

Единичка в названии не значит, что этот этап работает только для начала проекта. Все остается актуальным и для текущих проектов, но применимо к началу новой итерации, спринта (привет, Agile) или новой версии продукта. Это работает и в waterfall, когда разработка ведется от начала до конца без каких-либо итераций.

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

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

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

Пятый этап — тестирование. По-хорошему, разработчик УЖЕ выполнил тестирование на предыдущем этапе. Теперь же начинается тестирование в масштабах всей компании, которое может включать от 1 до 10 шагов. В современном мире IT тестирование — это просто бездна возможностей и проблем. Как правило, сначала идет модульное тестирование или юнит-тестирование — то, что делает разработчик, когда готовит кусок кода (например, функцию, которая удаляет с какой-то строчки какую-то подстрочку) для проверки функционирования отдельного блока или компонента приложения. Далее наступает фаза continuous testing, которая может включать:

• интеграционное тестирование для проверки взаимодействия нескольких компонентов одной системы или одного сервиса с другим;

• end-to-end тестирование для проверки приложения со стороны клиента;

• performance-тестирование для оценки производительности системы;

• security-тестирование, включающее до 10 типов тестов (статический и динамический код-анализ).

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

Шестой этап — развертывание. Здесь приложение накладывается на нужную среду: это может быть сервер, виртуальная машина, контейнеры и т. д; все что угодно, в зависимости от того, какая именно платформа используется, чтобы запустить продукт. Далее цикл замыкается, потому что проект выходит на стадию сопровождения. Мы получаем обратную связь от клиентов (скорее всего, что-то не работает). Появляются новые требования исправить баг, происходит анализ его причин, планирование его исправления, создание дизайна, реализация, тестирование, выкладка и далее по списку.

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

Один CI и два CD

CI или Continuous integration — процесс, который гарантирует получение протестированного, версионированного и готового к установке или развертыванию на конкретной инфраструктуре куска или полной версии приложения в каждой итерации. Как правило, сюда включены build и test. Собираем — тестируем, компилируем — тестируем. Как только продукт протестирован, можно говорить о внедрении CI в процесс разработки. Далее начинается внедрение CD.

Чем отличается Continuous delivery от Continuous deployment? Вся разница заключается в стадии Deploy to production: в первом случае она выполняется вручную, тогда как во втором случае происходит автоматически.

Давайте разберем проект в вакууме. Как правило, в работе применяется Continuous delivery. После CI получаем версию приложения, передаем ее тестировщикам или разворачиваем на окружении, где выполняются автоматические тесты «от» и «до». Это называется acceptance test, когда выполненная задача проходит проверку на соответствие тому, что нужно было сделать. Параллельно мы убеждаемся, что ничего не сломалось по дороге, ведь что-то сломать внедрением нового функционала очень легко. В этом процессе активно участвуют инженеры по ручному тестированию (Manual QA Engineers), потому что на сегодняшний день автоматизировать абсолютно все не всегда безопасно. Человеческий глаз улавливает моменты, которые иногда ускользают от автоматики. Хотя с развитием machine learning-а все меняется.

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

На сегодняшний день процентов 80 проектов и продуктов зависят от согласий с каких-либо сторон. Это как раз и называется Continuous delivery, когда есть кнопка, которую нажимают для развертывания в продуктивную среду только после сбора всех необходимых согласий.

После этого в обоих случаях, как правило, запускаются smoke tests — тесты базового функционала. Чаще всего, если в компании хорошо развита система тестирования, будут запущены performance-тесты и что-нибудь еще, но уже в меньшем объеме. Ведь это уже среда, к которой подключаются клиенты, душить ее своими тестами не стоит. Тестировать нужно заранее, на стадии staging-окружения.

Резюмируем. CI — версионированный кусок кода или версия приложения. CD — доставка приложения до продуктивной среды. Continuous deployment — осуществление доставки без какого-либо ручного воздействия и дополнительных подтверждений. Continuous delivery — доставка «с кнопкой», здесь необходимо ручное вмешательство и сбор согласий.

Достичь Continuous deployment трудно, потому что этот процесс требует определенных подходов к развертыванию продукта и очень сложной инфраструктурной архитектуры, чтобы проблемы при или после разворачивания не сильно отразились на клиентах.

Для чего нужен CI/CD

Метрики. Это отличный способ продемонстрировать, зачем вообще нужен CI/CD при разработке. Остановимся на каждой метрике подробнее.

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

Deployment frequency — частота разворачивания версии продукта; показатель наполовину технический, наполовину для бизнеса. По этому показателю можно увидеть, как часто мы доставляем клиентам новые версии приложения. В реальной жизни всегда есть баги и определенные запросы клиентов, которые используют абсолютно разные компьютеры, ОС, версии ПО. Да и сами люди разные: каждый человек видит мир (и ваш продукт) по-своему. Поэтому чем чаще мы разворачиваем новые версии нашего продукта — тем лучше. Но! Эту метрику нужно обязательно анализировать совместно с другими. Если мы доставляем приложение каждую минуту, но количество багов экспоненциально растет — что-то не так.

Бывает, что приложение настолько идеально, что в нем все есть, ничего не ломается, и все довольны. Значит, и обновлять ничего не нужно. Но такое приложение наверняка написано для себя и состоит из одной кнопки, которая выводит фразу «Привет!».

Deployment failures rate — процент развертываний с ошибками. Эту метрику как раз нужно добавлять к анализу предыдущей. Кроме того, в CI/CD важно предусмотреть действия в случае возникновения ошибок. Например, откатить приложение на предыдущую версию, чтобы клиенты продолжали с ним работать. Процент ошибок вместе с частотой разворачивания помогают отследить очень важные показатели для бизнеса и технической стороны разработки.

MTTR (Mean time for recovery или Mean time for restore) — количество времени, необходимое для восстановления жизнеспособности продукта. Эта метрика используется на только в CI/CD; например, ее часто можно встретить в SRE. В нашем случае MTTR можно измерять как с точки зрения откатки на предыдущую версию в случае ошибки, так и в целом анализировать скорость исправления багов, найденных в процессе CI/CD. Представим условную ситуацию: разработчик локально протестировал код — отправил его в систему контроля версий Git — запустился CI/CD пайплайн — в какой-то момент тестов вышла ошибка — так случилось 5 раз — на шестой раз разработчик исправил кусок кода — тесты заработали. Продолжительное время между тем как ошибка была замечена и тем, как она была исправлена, может свидетельствовать о несовершенном процессе определения обязанностей разработчика. Либо стоит проводить интеграционные тесты сразу. Либо что-то не было предусмотрено на стадии дизайна.

Небольшая ремарка. CI/CD — это процесс, который реализуется при помощи разнообразных инструментов: как включенных в систему контроля версий (Gitlab CI, Github Actions), так и отдельных систем (Jenkins). В инструментах реализуются пайплайны — последовательность кубиков (см. схему выше). С помощью этих инструментов производится описание стадий, которые нужно пройти с продуктом. Процесс пишется на программном коде либо на специальном коде системы. CI/CD позволяет реализовать нужный процесс, но в данной статье рассматриваются общие концепции, которые применимы к любой системе CI/CD. Здесь больше про процесс, чем про реализацию.

Кому и когда применять CI/CD

Опустим лишние рассуждения и теоретические выкладки. Вот вам выжимка: CI/CD нужен всегда. Рано или поздно. 

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

1. Вы стартап из одного-двух человек.

Например, CEO и CTO, один пишет фронтенд, второй занимается бэкендом. Вы никак не пересекаетесь с точки зрения кода, взаимодействуйте по API. Если же вы интегрируетесь, то вам несложно договориться друг с другом. Как только в компании появляется третий человек, начинаются вопросы. Не потому, что есть какие-то «плохие» языки программирования; это абсолютно нормальная ситуация: все люди разные, со своим мнением, опытом и навыками, которые они проецируют на работу. В то же время это довольно большая проблема, потому что весь Devops в целом — это про коммуникацию, про то, чтобы наладить мосты между департаментами разработки, тестирования и сопровождения. CI/CD как основополагающий инструмент Devops призван улучшить взаимодействие. Ну, или свести его к минимуму.

Тем, кто еще ничего не слышал про Devops, рекомендуем книгу «Проект «Феникс»»: там очень неплохо описаны процессы CI/CD в разрезе Devops-практики.

2. Продукт не может быть автоматизирован, или же цена автоматизации слишком высока.

Под автоматизацией в данной статье подразумеваются процессы сборки, тестирования и развертывания. Сегодня еще встречаются большие монолитные приложения, которые были написаны 10 лет назад и развертываются через Windows Wizard. С этим ничего не поделать. Вариант, конечно, есть: Windows, вопреки многим заблуждениям, отлично автоматизируется. Вопрос лишь в цене или времени, которое нужно потратить. Поэтому если проекту уже лет 30, его страшно поломать, и никакой автоматизацией или рефакторингом там не пахнет, то CI/CD может быть и не нужен. Но проблемы, которые решает CI/CD, в этом проекте есть на 100%, поэтому рано или поздно приложение придется менять, обновлять и, возможно, декомпозировать на микросервисы. Конечно, в случае монолита, который закрывает единственный функционал в мире и не имеет конкурентов, менять что-либо не требуется. Но это что-то из разряда фантастики.

3. Вы единственный пользователь своего продукта.

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

Зачем применять CI/CD

1. Ошибки отлавливаются раньше и быстрее.

Когда в команде есть CI/CD, то уже есть какое-то тестирование (надеемся). Следовательно, уже можно ловить ошибки на ранних этапах разработки. Ранние этапы в данном случае — CI или CD, стадии тестирования, происходящие до развертывания продукта. Такая практика помогает избегать багов, о которых сообщают пользователи. Если пользователь пишет с жалобой о том, что в интернет-магазине вместо морковки ему в корзину добавилась сосиска, это не очень хорошо. Представьте: вы приняли баг в работу, взяли неделю на исправление, а клиент в этом время ушел навсегда. Чем быстрее вы отловите ошибку и исправите ее, тем все метрики — а именно MTTR и Deployment failures rate — будут ниже. Что хорошо.

2. Меньше ошибок в целом.

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

3. Правильные процессы всегда помогают лучше и качественнее взаимодействовать.

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

4. Быстрая доставка благ клиентам.

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

5. Лучшая лояльность пользователя.

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

6. Выше доходность бизнеса.

Если мы быстрее доставляем новый функционал, привлекаем новых клиентов, быстрее оптимизируем процессы и повышаем качество поставляемого продукта в целом, то прибыль компании идет вверх. Но! Здесь необходимо учитывать, что один CI/CD не справится с этой задачей — остальные процессы тоже должны быть выстроены верно. В случае разработки внутреннего проекта увеличение доходности мы не получим, но если внутренние пользователи будут эффективнее делать свою работу, то это наверняка поможет.

Текущие проблемы CI/CD

Теперь обсудим острый момент: проблемы CI/CD среди тех, кто внедряет, использует и так или иначе связан с этой системой.

1. Бизнес думает, что это дорого.

Представьте онлайн-магазин, который целиком находится под управлением одного инженера: он отвечает за наполнение контентом, пишет код, раз в месяц заходит обновлять это все на сервере. Затем появляется второй, третий человек. Между ними начинаются конфликты, потому что они хотят делать по-разному. Появляется идея внедрить CI/CD. Придя к руководству, можно наткнуться на непонимание и отказ: «Мы больше денег потратим на время простоя, давайте вы плотнее насядете на наш магазинчик и будете чаще обновлять каталоги». В этом случае нужны переговоры, придется посчитать текущий lead time — сколько времени занимает определенный тип работы от идеи до конечной доставки. А потом прикинуть, сколько это займет в CI/CD. Как правило, будет заметно ускорение раза в три. К счастью, если наглядно показать проблематику, и указать на решение потенциальных задач, адекватный бизнес понимает, почему это необходимо, выделяет время и бюджет. Но иногда бизнесу надо помочь понять: почему и зачем.

2. Люди боятся лишиться работы.

Почему-то многие думают, что автоматизация заберет у них работу. Это касается не только CI/CD, но и тестирования, Devops, да и вообще любой автоматизации: мы боимся, что наши навыки перестанут быть нужны. Увы, не без оснований. Если инженер привык нажимать одну и ту же кнопку раз в день, он не хочет или не может учиться, то внедрение CI/CD грозит ему потерей работы. К счастью, такое случается очень редко. Например, хороший manual-тестировщик в сегодняшних реалиях не может быть заменен автоматизированным фреймворком и никогда не останется без работы. Потому что, как минимум, этот автоматизированный фреймворк нужно кому-то описывать и реализовывать. Если вы хотите писать код, то с внедрением CI/CD вы будете еще больше писать код. Каждый день выходит по 5-10 новых фреймворков, и если вы готовы постоянно учиться новому и понимать, что происходит, то всегда будете конкурентоспособным сотрудником.

3. Многие начинают с инструментов вместо процессов.

Случаются ситуации, когда компании внедряют инструменты, а не процессы: «Давайте возьмем Gitlab CI и напишем пайплайн! Сборка, тестирование — готово». Однако внедрение инструмента не решит проблему понимания внутри команды. Вы не сможете нормально объяснить сотрудникам, зачем им это надо, и как со всем этим работать. Не сможете создать правильный дизайн процесса CI/CD. Внедряя инструмент без обдумывания всего процесса, невозможно предугадать: что будет доставляться, когда это будет тестироваться и т. д. Очень важно начинать с правильного шага, а именно — с процессов, диаграмм, сбора вводной информации от команды. Зачастую эта задача лежит на плечах менеджеров, но в более современном варианте Devops-практик инженеры должны принимать непосредственное участие не только в инструментарной реализации, но и в процессах.

4. Некоторые начинают с найма инженеров для внедрения инструментов, а не с внедрения процессов.

Например, CEO побывал на ИТ-конференции и впервые узнал про CI/CD. Он приходит к HR и просит нанять 25 Devops-ов, чтобы сделать красиво. Потому что знает, что CI/CD и Devops идут вместе. К сожалению, когда 25 Devops-ов придут на работу, они не исправят проблему. Если в компании отсутствуют процессы или они не поставлены, без человека с определенным административным ресурсом инструменты не помогут. Devops-ы временно будут чем-то заняты, они что-то сделают. Но это «что-то» никому не будет понятно.

5. Много инструментов, решающих схожие задачи.

Для реализации CI/CD существует много инструментов:

• Gitlab CI;

• Github Actions;

• Jenkins;

• Bitbucket Pipelines;

• Travis CI;

• Circle CI;

• Concourse CI;

• Drone CI;

• Jenkins X;

• Argo CD.

Уже 10, а это только CI. Если начнем перечислять тестирование, никаких пальцев не хватит. Все эти инструменты, по большому счету, решают похожие задачи. Выбрать бывает сложно, особенно, если нет понимания о том, что именно мы строим. Понимание процессов (опять же) очень важно: если мы хотим оценивать качество исходного кода, то можем взять SonarQube, если хотим делать пайплайн, а исходный код хранится в Gitlab — берем Gitlab CI, очень классное решение из коробки. А если мы планируем производить CI/CD в закрытом инфраструктурном контуре, в своем приватном дата-центре без выхода в интернет (потому что мы панки), то нам нужно решить, какие инструменты можно использовать для установки внутри. Там на горизонте появляются Jenkins или платный Gitlab. Выбор инструмента — сложный процесс, поэтому сначала необходимо сформировать в голове общую картинку, а далее приглашать специалистов, которые могут помочь с выбором конкретного инструмента. Как правило, это software/solution/systems архитекторы, enterprise-архитекторы, техлиды или просто хорошие инженеры. 

Здесь надо учитывать, что у каждого такого специалиста есть свое видение процессов. Зачастую из-за недостатка опыта многие инженеры думают, что решить проблему можно инструментом. Это не так. Если перетащить все на условный Jenkins без понимания специфики всей системы, проблемы не исчезнут. Каждый новый проект — это новые вводные; единого паттерна для всех проектов не существует.

6. Редко, когда изначально у кого-либо есть хотя бы high-level план.

Часто можно услышать фразу: «Мы начнем, а там — как пойдет. Если что, потом поправим». В итоге проект превращается в монолитного монстра из миллиона строк кода и костылей. Сопровождать это очень сложно. Но есть и хорошая новость: при внедрении CI/CD всегда можно использовать метрики и общие кубики (последовательность пайплайнов), о которых мы писали выше. Все это натягивается на процесс разработки продукта — и появляется определенный высокоуровневый план.

Подытожим. CI/CD — это автоматизация. То, что вокруг нас. То, что мы принимаем как данность. Это интерфейс взаимодействия между командами. Разработчик не идет к тестировщику с дискетой: он отправляет свой код в систему контроля версий, происходит CI, и в момент начала тестирования за работу виртуально берется тестировщик. Или на этапе acceptance-тестирования система CI может автоматически сообщить тестировщику через систему учета задач (Jira, например): «Пожалуйста. Можно тестировать, вот ссылка». Не потому, что команды разработки, тестирования, сопровождения и остальные не умеют общаться, а потому, что это сложно. Особенно в гигантских компаниях. А CI/CD делает процесс взаимодействия легким и непринужденным.

Для тех, кто хочет разобраться в CI/CD за 7 недель

Автор: Александра Пшеборовская

Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина — в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами (читать как «последовательность этапов в CI/CD») и даже внедрять свои. Так почему же CI/CD — отличный инструмент контроля качества? Давайте разбираться.

Итак, зачем CI/CD тестировщикам?

• Автоматический запуск тестов

• Контроль качества с помощью Quality Gates

• Построение релизного процесса

Жизнь до и после внедрения CI/CD

Автоматический запуск тестов

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

Допустим, у нас есть девопс и мы делегировали настройку пайплайнов с тестами. Но так мы игнорируем прекрасную возможность реализовать вторую функцию CI/CD — контроль качества с помощью «ворот качества».

Контроль качества с помощью Quality Gates

Что же такое «ворота качества», иначе говоря, проверки качества кода? Давайте посмотрим на нашу «крепость» — код продукта. Каждый день команда разработки пишет код для новых фич, которые могут сломать нашу крепость. Задача QA — тестировать каждую фичу и уменьшать вероятность попадания бага в код продукта. QA мало спит и нервничает, ведь процесс не автоматизирован и нет «сторожа», который контролирует все метрики, даже в самые опасные моменты, например в пятницу вечером, когда разработчик хотел бы пораньше убежать в выходные и доделать все задачи, не перенося их на новую неделю. В этот момент происходит злосчастный merge, который принесет много проблем позже.

Путь нового кода через «ворота качества»

Внедрение проверок качества решает эту проблему.

Каждая из проверок будет отвечать за прохождение важной метрики. Если метрика не соблюдается, «ворота» должны закрыться и не пустить фичу дальше. Пока не пройдут все проверки, фича не будет залита в код продукта, а значит потенциальные баги будут предотвращены.

Из каких проверок качества может состоять CI/CD?

Чтобы максимально автоматизировать процесс, нам нужно составить список проверок для успешного прохождения пайплайна. Можно следовать последовательности проверок качества “fail first” (упади как можно раньше). Первыми идут проверки на работоспособность приложения, а именно: сборка, code style и статический анализ. 

Пример СI/CD пайплайна

Со сборкой все понятно: не собралось приложение — значит, фича не допущена. Code style важно вынести в CI/CD, чтобы унифицировать требования и не тратить время на code style ошибки во время code review.

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

Далее указываем проверки второго уровня: юнит-тесты с анализом покрытия и контролем достижения нужного уровня, а также интеграционные и системные тесты со всеми возможными отчетами для наглядности. 

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

Общие требования к пайплайну: 

• он должен гарантировать максимальное качество фич с учетом ваших требований;

• длительность пайплайна не должна стопорить рабочий процесс. Обычно на пайплайн выделяется до 20 минут.

Примеры инструментов для внедрения в проверки качества

Code style linter

Стиль кода — это набор правил, которым должна удовлетворять каждая строчка кода в проекте, начиная от правил выравнивания и до правил типа «никогда не использовать глобальные переменные».

Казалось бы, как стиль может влиять на тестировщиков? Оказывается, связь прямая. Есть несколько плюсов, которые проверка стиля дает QA-команде (а, на самом деле, всем членам команды): — благодаря единому стилю в проекте разработчику легче работать с кодом, а значит есть чуть больше времени на реализацию новых фичей и исправление ошибок; — за счет ускорения ревью кода можно не проверять стиль вручную, так как это сделает CI/CD, а значит снова выигрывается немного времени на новые фичи или исправление ошибок.

Примеры руководств по стилю можно подсмотреть у крупных компаний. Например, вот стиль по JavaScript от Airbnb, а вот гайды от Google. Также вы можете написать собственный.

Инструменты для проверки стиля зависят от языка кода. Можно найти подходящий, например, на GitHub, а также узнать, какие инструменты используют в соседних командах. Примеры линтеров — ktlint для Kotlin, checkstyle для Java или eslint для JavaScript. Все они берут какой-то свод правил за основу и подсвечивают места, где код этим правилам не удовлетворяет.

Статический анализ кода

На рынке существует много разных статических анализаторов кода. Рассмотрим один из них под названием Qodana. Основное преимущество этого анализатора кода в том, что он содержит различные инспекции, доступные нам в средах разработки JetBrains, когда мы пишем код.

Многие наверняка использовали IDE-driven подход, когда IDE помогает вам писать код и указывает на различные ошибки: неоптимальное использование кода, необработанный NullPointerException, дубликаты и т. д. 

Пример репорта Qodana

К сожалению, мы не можем быть уверены, что разработчик исправил все найденные проблемы внутри IDE перед коммитом. Один из способов гарантировать отсутствие критичных проблем в коде — внедрить Qodana прямо в CI/CD-пайплайн. Если нельзя пофиксить все сразу, вы сможете выбрать критичные проблемы, добавить их в baseline и постепенно разбирать тех. долг, не замедляя разработку, но при этом контролируя появление новых проблем.

Тестовое покрытие

Покрытие кода — метрика, которая помогает понять, насколько хорошо код покрыт тестами, в большинстве случаев — юнит-тестами.

В проверке качества нужно задать какой-то минимальный процент покрытия, который необходимо поддерживать в проекте. Так код не сможет попасть на боевое окружение, если он не покрыт тестами на достаточном уровне. Минимальный процент устанавливается эмпирическим способом, но стоит помнить, что и стопроцентное покрытие может не избавить код от ошибок полностью. Согласно этой статье от Atlassian, хороший показатель — 80%.

Для разных языков есть разные анализаторы покрытия, например Jacoco для Java, Istanbul для JavaScript, Coverage.py для Python. Всех их можно встроить в CI/CD и удобно следить за метриками.

Построение релизного процесса

Помимо автоматического запуска тестов и выполнения определенных метрик качества кода, CI/CD позволяет тестировщикам выстроить релизный процесс.

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

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

1. На каждое изменений в гит-ветках запускается сборка приложения.

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

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

4. Релиз-кандидат тестируется и проходит финальные проверки.

5. Релиз-кандидат уходит на боевое окружение — это может быть ручной запуск пайплайна или автоматический, если на предыдущем шаге релиз-кандидат прошел все проверки. Зависит от частоты и серьезности релизов, предпочтений в команде и удобства выкатки.

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

Основные правила релизного процесса:

• Артефакты должны быть готовы для скачивания и тестирования, а в идеале — быть собраны в одном месте.

• Максимальное количество проверок и тестов должно проходить автоматически, без участия человека.

• Все сложные манипуляции со сборками должны быть переложены на автоматизацию, если это возможно.

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

---

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

Реализуйте пайплайны, автоматизируйте процессы, используйте статический анализ кода!

Ваша команда Qodana

Спасибо

Ирине Хромовой за классные иллюстрации и помощь в написании статьи.

Обсудить в форуме