CI/CD и еще один CD. Разбираемся в терминологии pipelines в контексте автоматизации тестирования
О чем речь
В IT индустрии используется большое разнообразие инженерных культур и практик, таких как Agile, бережливое производство (lean software development), DevOps. Все они так или иначе нацелены на бесперебойную доставку ценности за счет повторяемых коротких итераций. Неотъемлемой частью такого подхода является конвейерный подход или по-английски — pipelines. Подразумевается, что в идеальном мире разработчик заливает код на сервер и дальше происходит магия, состоящая из автоматизированных этапов сборки проекта, контроля качества кода, запуска тестов и сбора метрики. На рынке существует большое количество платных и бесплатных инструментов для настройки такого процесса, который мы называем «процессом непрерывной интеграции» или CI/CD (Jenkins, GitLab CI, Teamcity и д.р.). Однако для построения действительно зрелого процесса недостаточно просто установить инструмент. За каждым этапом конвейера стоит сложная логика того, что должно быть запущено, на каких вычислительных ресурсах и как эти ресурсы используются.
На собеседовании кандидаты очень часто гордо говорят, что знают CI/CD. Но знать можно по-разному. Одно дело нажимать кнопку запуска и смотреть, какой цвет получился: красный или зеленый. И совсем другое дело настраивать весь флоу от и до самостоятельно, чем обычно и занимаются DevOps инженеры. Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: «А в чем разница между CI и CD?». Далее я хочу поделиться своим пониманием отличий CI от CD и от еще одного CD на примере запуска автотестов. Заранее предупрежу, что мое видение может частично отличаться от вашего. Ведь у всех нас немного разный опыт, разные проекты и источники для изучения, которые могут расходиться. Главное, что какое-то видение у вас есть!
Коротко про пирамиду тестирования
Так как мы рассматриваем непрерывную интеграцию в контексте автоматизированного тестирования, необходимо описать виды автотестов. Полагаю, читатель знаком с термином «Пирамида тестирования». Существует много разных ее модификаций в зависимости от специфики проекта и технологий. Кратко опишу три самых популярных уровня.
Unit тесты
Фактически во всех модификациях пирамиды эти тесты лежат в основании. Они характеризуются низкой стоимостью и высокой скоростью запуска. Unit тесты подразумевают изолированное тестирование частей кода (методов и функций) и чаще всего выполняются разработчиками. Не требуют отдельного тестового стенда.
Самый нестандартизированный уровень, так как он сильно зависит от проекта и архитектуры разрабатываемой системы. Может дробиться на различные подуровни. Выделяется отдельный компонент системы (может быть как UI component так и API endpoint) и тестируется в изоляции от другого компонента и базы данных. Как и в случае с unit тестированием отдельный тестовый стенд не требуется, а все зависимости мокируются, что также значительно удешевляет и ускоряет тесты. Данный уровень может покрываться как разработчиками, так и тестировщиками.
E2E тесты
Самый востребованный уровень, так как тестирование происходит с точки зрения пользователя. Больше никаких изоляций компонент и программных частей. Все происходит на тестовом стенде с полноценной базой данных. В большинстве случаев выполняется тестировщиками и ими же автоматизируется, например одним из самых популярных инструментов — Selenium. Это самый дорогой уровень, так как требует больше времени на прохождение тестов и ресурсов на поддержание тестового стенда.
CI — Continuous Integration
Непрерывная интеграция — это только самый начальный этап нашего pipeline. Здесь подразумевается именно интеграция нового кода разработчика с уже существующим кодом, находящимся у нас в репозитории. При отправке кода на сервер запускаются быстрые unit тесты и статические анализаторы кода, проверяющие, например, соответствие установленным стандартам кодирования. Также на этом этапе могут запускаться интеграционные и компонентные тесты, если они написаны изолированно, поскольку тестовый стенд не требуется. Так как этот этап быстр в прохождении (речь идет о минутах) и прост в установке, то довольно часто разработчики могут настроить его без привлечения DevOps.
CI
CD — Continuous Delivery
Непрерывная доставка выводит наш pipeline на совершенно другой уровень. Для начала мы должны собрать наше приложение. В случае Web и Backend мы выкатываем изменения на тестовый стенд. А для мобильных приложений необходимо собрать билды. Только после этого можно переходить к запуску e2e тестов для Web / Mobile / API. Как вы видите, здесь понадобится огромное количество дополнительных компонентов: сервер базы данных, сервера для тестового стенда, механизм для развертывания кода, браузеры и эмуляторы для запуска тестов, механизм балансировки нагрузки. Все это требует большой нагрузки на CPU и память, а, значит, и дополнительные затраты на поддержку. Именно тут необходимо понимание DevOps технологий.
CD
Еще один CD — Continuous Deployment
Вишенкой на торте является этап непрерывного развертывания. Его часто путают с непрерывной доставкой, так как у них одинаковая аббревиатура — CD. Именно этот этап делает наш pipeline действительно непрерывным. Во многих организациях я видел в основном предыдущий этап непрерывной доставки, когда тесты запускаются не тестовом стенде, а дальше тестировщики что-то проверяют руками или release-manager дает разрешение на влитие в основную ветку разработки (master) и сам релиз. В таком случае о никакой непрерывности речи не идет. Непрерывное развертывание подразумевает автоматический релиз нашего кода в production, если все тесты на предыдущих этапах прошли успешно. В дополнение к этому собираются метрики продукта и сравниваются с предыдущими показателями.
Страшно ли сразу выкатывать на production без дополнительного тестирования и согласования? Безусловно. Именно поэтому настолько зрелый процесс редко где встречается, так как для него необходимо наличие хорошо поставленных процессов и хорошее тестовое покрытие, которому доверяет вся команда. Это та самая целевая функция, к которой нужно стремиться.
CD
Заключение
Мы рассмотрели 3 этапа построения pipeline и обсудили, какие тесты необходимо запускать на каждом из этих этапов. Если у вас есть опыт в использовании и построении CI / CD / CD, буду рад увидеть ваши варианты в комментариях.
Также хочу порекомендовать бесплатные уроки от моих коллег из OTUS по темам:
