О чем речь

В 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
CI

CD -  Continuous Delivery

Непрерывная доставка выводит наш pipeline на совершенно другой уровень. Для начала мы должны собрать наше приложение. В случае Web и Backend мы выкатываем изменения на тестовый стенд. А для мобильных приложений необходимо собрать билды. Только после этого можно переходить к запуску e2e тестов для Web / Mobile / API. Как вы видите, здесь понадобится огромное количество дополнительных компонентов: сервер базы данных, сервера для тестового стенда, механизм для развертывания кода, браузеры и эмуляторы для запуска тестов, механизм балансировки нагрузки. Все это требует большой нагрузки на CPU и память, а, значит, и дополнительные затраты на поддержку. Именно тут необходимо понимание DevOps технологий.

CD
CD

Еще один CD - Continuous Deployment

Вишенкой на торте является этап непрерывного развертывания. Его часто путают с непрерывной доставкой, так как у них одинаковая аббревиатура – CD. Именно этот этап делает наш pipeline действительно непрерывным. Во многих организациях я видел в основном предыдущий этап непрерывной доставки, когда тесты запускаются не тестовом стенде, а дальше тестировщики что-то проверяют руками или release-manager дает разрешение на влитие в основную ветку разработки (master) и сам релиз. В таком случае ни о какой непрерывности речи не идет. Непрерывное развертывание подразумевает автоматический релиз нашего кода в production, если все тесты на предыдущих этапах прошли успешно. В дополнение к этому собираются метрики продукта и сравниваются с предыдущими показателями. 

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

CD
CD

Заключение

Мы рассмотрели 3 этапа построения pipeline и обсудили, какие тесты необходимо запускать на каждом из этих этапов. Если у вас есть опыт в использовании и построении CI / CD / CD, буду рад увидеть ваши варианты в комментариях.

Также хочу порекомендовать бесплатные уроки от моих коллег из OTUS по темам:

Комментарии (4)


  1. Falseclock
    03.09.2022 09:32

    Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: “А в чем разница между CI и CD ?”

    И? Толк ест?

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

    Много лет занимался оупен сорсом, где все мои проекты были покрыты юнит тестами со 100% coverage и я знаю как автоматизировать многие рутинные задачи, как упростить сборку и деплоймент, сделать нормальные пайплайны, хорошо понимаю структуру и сущность того же GitHub Actions, Gitlab CI/CD, Travis CI. И мне глубоко фиолетово кто и что вкладывает в значение CI/CD.

    Так вот вопрос: вам шашечки или ехать?


    1. alexeyQA Автор
      03.09.2022 09:58

      Спасибо за комментарий. Кандидат, который отвечает на подобный вопрос показывает свою осведомленность. Значит читал / изучал / интересовался. Толк в том, что потом этот вопрос раскручивается дальше и человек объясняя CI/CD подробнее рассказывая про свой опыт, например, как вы писали: «как упростить сборку и деплоймент, сделать нормальные пайплайны, хорошо понимаю структуру и сущность того же GitHub Actions, Gitlab CI/CD, Travis CI. »

      Или ничего не рассказывает, что означает, что сам ничего не настраивал, а только слышал. Этот вопрос стартовый для начала диалога про CI / CD.

      “И мне глубоко фиолетово кто и что вкладывает в значение CI/CD.”

      Тут все верно, я не требую именно такой формулировки, которую даю я в статье. Мне интересно не «кто и что», а именно виденье самого кандидата . Его наличие и адекватность.

      Плюс это проверит Soft Skills :) На сколько он готов будет подробно рассказать или начнет кидать понты и говорить, что вся ваша теория херня, я автоматизатор 80-ого уровня


  1. Odnokletochnoe
    03.09.2022 15:12

    Не понял момент с интеграционным тестированием, где вы делаете изоляцию, с чем тогда интеграция ?


    1. alexeyQA Автор
      03.09.2022 23:30

      Специально не стал вдаваться в подробности пирамиды, так как это статья о другом. Пирамида тоже у всех своя и огромное количество вариантов. Для меня интеграционной слой состоит из 3 этапов:

      1) Компонентный тест на UI, где мы мокаем бэкенд

      2) Компонентный тест на API, где мы мокаем БД и 3rd parties

      3) Теперь когда UI и API в отдельности протестированы, то накидывает контрактный тест, который уже и проверяет правильную интеграцию UI с API. Контрактное тестирование тоже использует моки.

      При этом компонентные тесты на слой выше Unit, так как Unit это про методы и функции на уровне кода

      Подробнее в этой статье