Автоматизация тестирования
CI/CD для тестировщика: что это, этапы конвейера и Jenkins
CI/CD – это конвейер, который сам собирает, проверяет и доставляет изменения кода на окружения. При непрерывной интеграции (continuous integration) каждый коммит запускает сборку и автотесты. При непрерывной доставке (continuous delivery) проверенная сборка доезжает до тестового окружения и готова к релизу, но на продакшн её выкладывают по решению команды, а при непрерывном развёртывании (continuous deployment) и этот шаг автоматический. Тестировщик запускает сборки на тестовое окружение, например в Jenkins, разбирает упавшие сборки и автотесты и проверяет то, что до него доехало.
- CI и CD
- сборка с автотестами после каждого изменения и доставка на окружения
- Delivery или deployment
- разницу между ними могут спросить на собеседовании
- Бесплатно
- урок с заданиями в моём базовом курсе
Что такое CI/CD простыми словами
CI/CD расшифровывается как continuous integration и continuous delivery, то есть непрерывная интеграция и непрерывная доставка. Это подход, который стоит за конвейером (pipeline): код от коммита до пользователя проходит цепочку автоматических шагов, и на каждом что-то проверяется. Ключевое слово здесь автоматизация, в том числе автоматизация тестирования. Цель в том, чтобы быстро довезти работающее приложение до всех, кому оно нужно: разработчиков, аналитиков, тестировщиков, заказчика и конечных пользователей.
Непрерывная интеграция означает, что изменение в код можно внести в любой момент. Разработчик добавил новую функцию или автотест, отправил коммит в репозиторий, например на GitHub, и изменение сразу проходит сборку и проверки. Непрерывная доставка означает, что из текущего кода в любой момент можно собрать рабочее приложение и отдать его заказчику, пользователям или на тестовое окружение. Эти процессы идут друг за другом, и доставке всегда предшествует интеграция.
Конвейер нужен потому, что код в редакторе сам по себе не работает. Его ещё надо собрать в программу и развернуть на окружении, и CI/CD проходит эту цепочку без ручных действий.
DevOps-цикл и где в нём тестировщик
CI/CD вырастает из DevOps. Так называют методологию, которая соединяет разработку (development) и эксплуатацию (operations), чтобы команда работала слаженно и вовремя исправляла ошибки. Конвейер обычно строит и поддерживает DevOps-инженер, он же подбирает инструменты, но влияет на процесс вся команда. Иногда отдельно выделяют TestOps, то есть специалиста, который отвечает за место тестирования в конвейере.
DevOps-цикл рисуют знаком бесконечности, потому что этапы повторяются по кругу. По моему опыту, тестировщик участвует почти во всех из них, хотя работает далеко не со всеми инструментами.
Планирование (plan)
Задачи по пользовательским историям заводят в трекере вроде Jira. Тестировщик читает истории и готовит по ним проверки.
Код (code)
Разработчики пишут код и отправляют его в Git, например на GitHub. Код тестировщик не пишет, но если есть доступ, читает изменения и использует их в тест-дизайне.
Сборка (build)
Код превращается в исполняемую программу. Сборку обычно настраивают за тестировщика, а запускать её на своё окружение ему приходится даже на ручном проекте.
Тестирование (test)
Юнит-тесты, например на JUnit, пишут разработчики. Selenium подходит для уровней выше: интеграционного и тестирования графического интерфейса. Ручной тестировщик смотрит результаты автотестов, разбирает падения и решает, где ошибка, в автотесте или в приложении.
Релиз и развёртывание (release, deploy)
Релизом на этом этапе называют отправку сборки туда, где она заработает, и это не обязательно продакшн. Развёртывание, или деплой, – установка приложения на конкретное окружение.
Эксплуатация и мониторинг (operate, monitor)
Серверы и логи. В Kibana и Elasticsearch видно, что отвалилась база данных, случилась фатальная ошибка или пришёл не тот статус-код. Настраивает мониторинг обычно DevOps-инженер, а тестировщик читает эти логи, когда разбирает дефект.
Как проходит конвейер: от коммита до продакшна
По дороге сборка проходит несколько окружений. Локальное стоит на компьютере разработчика, на dev проверяют отдельные фичи, на тестовом, или QA, работают тестировщики, stage держит стабильную версию перед релизом, а на продакшне работают пользователи. Пользователи видят только продакшн, остальные окружения изолированы от них и друг от друга.
Ниже конвейер в том виде, как я его описываю. Инструменты на проектах разные, но порядок этапов обычно такой. В идеале каждый этап сам запускает следующий и человек в цепочке не нужен, хотя так получается не везде, а важные изменения иногда перепроверяют вручную.
1. Коммит
Разработчик вносит изменение в код и отправляет коммит в репозиторий.
2. Сборка
Коммит сам запускает сборку (build): через GitHub Actions прямо на GitHub или в отдельном инструменте вроде Jenkins или CircleCI. Когда сборка готова, команде приходит уведомление в Slack, Telegram или другой мессенджер.
3. Юнит-тесты, интеграционные тесты и линтеры
Автотесты этого этапа чаще пишут разработчики. Линтер проверяет оформление кода, например точки с запятой и имена переменных, и функциональность не трогает. Если здесь что-то упало, код дорабатывают ещё до того, как сборка дойдёт до тестировщиков. Юнит-тестов в конвейере больше всего, потому что они проверяют код напрямую и работают быстрее остальных.
4. Приёмочные тесты
Проверки со стороны тестирования, в том числе автоматизированные.
5. Доставка на тестовое окружение
Здесь начинается непрерывная доставка. Сборка приезжает на QA-окружение, и тестировщики берутся за задачи, которые в неё вошли.
6. Выкладка на продакшн
Когда тестирование дало добро, сборку выкладывают для пользователей. При continuous delivery этот шаг запускают вручную, при continuous deployment он срабатывает автоматически.
Как это выглядит в работе
В интернет-магазине разработчик исправил округление скидки в корзине и отправил коммит в ветку задачи. Юнит-тесты прошли, сборка сама развернулась на QA-окружении, и в Slack пришло уведомление с номером задачи. Тестировщик проверяет скидку на товарах с копейками в цене и на корзине из одного товара, а потом проходит оформление заказа целиком, потому что сумма корзины попадает и в оплату.
Continuous delivery и continuous deployment: в чём разница
Разницу между доставкой и развёртыванием иногда спрашивают на собеседовании. Обе практики идут после непрерывной интеграции и расходятся на последнем шаге, когда сборка уходит на продакшн.
Continuous integration
Каждое изменение кода автоматически собирается и проходит юнит-тесты, интеграционные тесты и линтеры.
Continuous delivery
Проверенная сборка автоматически доезжает до тестового окружения или stage и в любой момент готова к релизу. На продакшн её выкладывают вручную, когда решение примут менеджеры проекта, часто в отдельном чате релизов.
Continuous deployment
Ручного шага нет. Как только тестирование дало добро, сборка уходит на продакшн сама, а при полной автоматизации она уходит туда сразу после зелёных автотестов.
Пример: мобильное приложение и сайт
Мобильное приложение банка не попадёт к пользователям сразу после автотестов, потому что сборку ещё проверяют App Store и Google Play. Поэтому там continuous delivery, и тестировщик успевает пройти регресс перед отправкой в магазин. Сайт интернет-магазина может выкатывать мелкие правки по continuous deployment несколько раз в день, и тогда основная проверка ложится на автотесты конвейера, а тестировщик смотрит изменение на продакшне сразу после выкладки.
Пример: сборка в Jenkins глазами тестировщика
В ролике я показываю Jenkins, который настроил для учебного интернет-магазина своих курсов: фронтенд, бэкенд и база данных связаны через Jenkins и GitHub. Скрипт сборки я писал вместе с ChatGPT и сам называю решение неидеальным, хотя и рабочим. Если понимать, как устроен процесс, минимальный конвейер настроить не так сложно.
Задачи в Jenkins называются джобами (jobs). У меня одна джоба разворачивает приложение, а другая удаляет старые сборки и оставляет десять последних, чтобы на сервере не кончилось место. На проектах бывают и отдельные джобы для прогона регрессионных тестов.
Перед сборкой тестировщик собирает набор задач, готовых к проверке. Коммиты привязаны к задачам в трекере, и по ссылке видно, что именно поменялось в коде. Ради одной мелкой задачи сборку лучше не запускать: если тестовое окружение одно на всех, она займёт его, а другим тестировщикам тоже нужно работать.
Собрать с параметрами
Кнопка "Собрать с параметрами" (Build with Parameters) открывает форму сборки. В ней базовый адрес, база данных, порт, ветка и сервис, который нужно перезапустить. Чаще всего поля заполнены заранее, и остаётся нажать "Собрать". Если нет, тестировщик вписывает их сам.
Ветка
Её выбирают под задачу: общую ветку qa или main, ветку отдельной фичи или ветку с исправлением дефекта, в названии которой стоит его номер.
Триггер
Сборку можно запускать и без кнопки. Если в настройках джобы включён GitHub hook trigger, после пуша в репозиторий вебхук сам запускает сборку.
Скрипт сборки
Это те же команды, которые человек набрал бы в терминале сервера: склонировать репозиторий или обновить код, переключиться на нужную ветку, поставить зависимости, перезапустить приложение. Jenkins вводит их сам.
Вывод консоли
Если сборка упала, первым делом открывают вывод консоли (Console Output): там видны все команды и ошибка. Рядом показаны параметры запуска и коммиты, которые вошли в сборку.
Если причина непонятна
Тестировщик перепроверяет свои параметры, а потом идёт к DevOps-инженеру или разработчику, смотря чья это зона. Стоит проверить и свободное место на сервере, потому что из-за него сборки падают очень часто.
Видеоурок, шпаргалки и задания
Я разбираю тему в ролике "CI/CD для тестировщика + Jenkins" на YouTube: DevOps-цикл, этапы конвейера, разницу между delivery и deployment и сборку в Jenkins на своём учебном проекте. В бесплатном базовом курсе по тестированию она идёт уроком "CI/CD для тестировщика + демо в Jenkins", и после теории в нём есть задания.
Шпаргалка по CI/CD раскладывает конвейер по стадиям и показывает окружения и артефакты сборки. Шпаргалка о прогоне билда начинается там, где сборка доехала до тестировщика: принять её или отклонить, что проверять первым и когда гонять регресс. В тренажёре по логам нужно найти в логе нужную запись и понять, что произошло.
Курсы по теме
Вопросы и ответы
Что такое CI/CD простыми словами?
Это конвейер, который после каждого изменения кода сам собирает приложение, прогоняет автотесты и доставляет сборку на окружения: тестовое, stage и продакшн. CI, непрерывная интеграция, позволяет вносить изменения в любой момент и сразу их проверять. CD, непрерывная доставка, позволяет в любой момент отдать рабочую сборку тестировщикам, заказчику или пользователям.
Чем continuous delivery отличается от continuous deployment?
Последним шагом. При continuous delivery сборка автоматически доезжает до тестового окружения и готова к релизу, а на продакшн её выкладывают вручную, по решению команды. При continuous deployment выкладка тоже автоматическая: если проверки прошли, сборка уходит к пользователям без участия человека.
Что делает тестировщик в CI/CD?
Запускает сборку на тестовое окружение, например кнопкой "Собрать с параметрами" в Jenkins, и выбирает в ней нужную ветку. Разбирает упавшие сборки по выводу консоли, смотрит результаты автотестов и перепроверяет упавшее руками, чтобы понять, ошибка в автотесте или в приложении. Сам конвейер обычно настраивает DevOps-инженер.
Что такое Jenkins?
Программа для CI/CD, в которой настраивают задачи, или джобы: собрать приложение из нужной ветки, развернуть его на окружении, запустить автотесты, удалить старые сборки. Джобу запускают кнопкой или автоматически, например после пуша в репозиторий. Похожие задачи решают GitHub Actions, CircleCI, TeamCity и Azure DevOps.
Нужно ли тестировщику уметь настраивать CI/CD?
На старте нет. Новичок обычно приходит на проект с готовым конвейером и пользуется им: запускает сборки и читает результаты. Строить конвейер – задача DevOps-инженера. Самому этим заниматься приходится, если тестировщик на проекте один или хочет расти в сторону DevOps и TestOps, и такой навык приходит с опытом.
Что делать, если сборка в Jenkins упала?
Открыть вывод консоли (Console Output) упавшей сборки и найти ошибку, проверить параметры запуска и коммиты, которые в неё вошли. Если причина непонятна, написать DevOps-инженеру или разработчику. Частая причина падений – закончившееся место на сервере.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.