Ежедневные релизы — это не так уж страшно
Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.
Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).
Что такое Continuous delivery и Сontinuous integration?
Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.
Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.
Как работает непрерывная интеграция?
Разработчики выкачивают исходный код из репозитория, делают какие-либо изменения, а затем отправляют свои изменения обратно в репозиторий. После чего автоматически проходит сборка проекта, прогоняются тесты и отсылается отчет, что в измененном коде всё хорошо, и он сохранен.
А здесь детально показано, что происходит на этапе тестирования после сохранения измененного кода:
Первое, что прогоняется, — jar-файлы, затем параллельно:
- war-файлы;
- внешние сервисы,
- интеграционные тесты;
- JS-тесты;
- статический анализ кода;
- тесты с базой данных.
Затем друг за другом выполняются следующие действия: валидационная сборка, инсталляция сборки, развертывание на тестовом окружении и, наконец, Selenium-тесты.
Хочу оговориться, что так происходит не в каждом проекте — это просто то, что разработчики решили сделать для себя, чтобы быть уверенными, что их изменения ничего не сломали.
Вот так построен процесс непрерывной поставки. Стоит еще сказать, что практику непрерывной поставки (continuous delivery) не нужно путать с практикой непрерывного развертывания (continuous deployment). Разница в том, что при непрерывной поставке на определенном этапе присутствует ручное тестирование, а непрерывное развертывание выполняется полностью автоматически:
Здесь я рассказываю именно о непрерывной поставке — далее поясню, в чем суть ручного вмешательства в тестирование.
Гибкая методология разработки
В проекте мы используем гибкую методологию разработки — Agile. Гибкая методология предполагает разработку ПО циклами. Каждый цикл представляет собой уменьшенный вариант IТ-проекта: анализ требований, планирование, разработка, сборка, тестирование, развертывание. По окончанию итерации заказчик получает готовую версию IТ-системы, и, если требуется, — дальнейшие приоритеты проекта пересматриваются. Затем цикл разработки запускается снова. В итоге создается решение, которое соответствует требованиям заказчика.
Хотя релизы происходят каждый день, это, конечно, не значит, что мы каждый день добавляем новый функционал. Когда происходит разработка нового функционала, мы проходим все вышеозначенные стадии. При этом у нас нет ограничения по времени: если мы разрабатываем новый функционал, это не обязательно будет делаться два дня, две недели или месяц — сколько времени отложено на этот проект, столько времени и может длиться процесс разработки, и нужно учитывать, что новый функционал не сразу пойдет в готовую версию продукта.
Однако тут возникает следующий вопрос: если код хранится в репозитории постоянно и если у нас непрерывная интеграция, как скрыть код, который будет реализовать новый еще не готовый функционал? Это делается с помощью конфигурационного флага, при помощи которого разработчики скрывают код, который отвечает за неготовый функционал (хотя, конечно, бывают и такие изменения, которые невозможно скрыть под конфигурационным флагом).
Процесс разработки нового функционала:
Итак, как мы разрабатываем новый функционал? Сначала получаем требования, после чего QA-команда, проанализировав и выяснив требования, начинает писать тест-кейсы. В это же время идет процесс разработки. После того как разработчики, дав добро на тестирование, включают конфигурационный флаг на тестовом окружении, QA-инженеры начинается функциональное тестирование. Пока QA-инженеры тестируют и находят ошибки, которые разработчики исправляют, автоматизаторы или Selenium-команда (так мы их называем), начинают процесс автоматизации тест-кейсов. После функционально тестирования проводится регрессионное тестирование.
Процесс релиза
Если всё хорошо, принимается решение, что новый функционал пойдет в продакшн. Как это делается? Все очень просто: разработчик коммитит включение конфигурационного флага, под которым был скрыт новый функционал. После коммита происходит развертывание новой версии продукта на тестовом окружении с уже доступным новым функционалом. Разработчик делает включение конфигурационного флага непосредственно перед днем, когда назначен релиз, чтобы изменение вошло в новую версию приложения, ту, которая будет выпускаться на продакшн.
Итак, после того, как флаг включен, и наш функционал доступен на тестовом окружении, прогоняются приемочные тесты. Процесс прогона приемочных тестов повторяется каждую ночь, вне зависимости от того, релизим мы новый функционал или исправленные баги. Набор тестов за ночь прогоняется дважды, чтобы минимизировать случайные падения. Эти приемочные тесты покрывают все высокоприоритетные случаи. Когда QA-команда приходит утром, то просматривает отчеты о ночном тестировании, и бывает так, что всё прошло не гладко: 1 — 2% тестов упали или были не пройдены. Дабы убедиться, что это были всего лишь случайные падения или, наоборот, что автоматизированые тест-кейсы выявили ошибку, QA-команда перепроходит эти тестовые случаи вручную.
Затем, если всё хорошо, мы сообщаем об этом заказчику, и можем выпускать изменения в готовую версию продукта.
После одобрения заказчиком, наше приложение разворачивается на промежуточном окружении, которое очень схоже с продовским, — и тут проводится приёмочное тестирование. Оно проводится и QA-командой, так и Selenium-тестами — ручное и автоматизирование тестирование происходит параллельно. Если всё прошло хорошо, мы сообщаем об этом заказчику и выпускаем нашу версию в продакшн, где проводится smoke-тестирование. Это идеальный вариант развития событий.
Как быть, если утром обнаруживается существенный баг? В этом случае процесс релиза останавливается до исправления ошибки. Если есть возможность исправить ошибку быстро (до конца дня, например), в этой ветке отрезается новый тег, и эта же ветка, но с новым тегом, выпускается на промежуточное окружение, и процесс релиза повторяется снова.
Каждую ночь в случае успешного релиза от trunk отрезается branch, т. е. наша ветка приложения, которая отправляется на продакшн. Пока не будет выпущено то, что было отрезано, новая ветка не будет релизиться. Конечно, бывает, что у нас нет релиза дня три — когда мешает какой-то баг или происходят сбои в процессе отрезания ветки.
Небольшие же ошибки исправляются к следующему релизу. В этом преимущество ежедневных релизов: если сегодня вы нашли небольшую ошибку, вы ее быстро исправите, и завтра её уже не будет.
В целом процесс релиза выглядит следующим образом:
- Просмотр отчета прохождения автоматических приемочных тестов на тестовом окружении.
- Запуск упавших и пропущенных тестов вручную.
- Приёмочное тестирование в промежуточном окружении, который наиболее схож с продовским.
- Smoke-тестирование на продовском окружении.
Обратите внимание, что новый функционал выпускается на продакшн не каждый день, но это не значит, что релиза не будет. Будет! Машина запущена, процесс релиза отлажен и происходит каждый день. Если нет нового функционала, всегда есть фиксы уже существующих багов.
Роль и обязанности QA-инженера
У вас может сложиться впечатление, что у нас всё так заавтоматизировано, что QA-инженеру больше нечего делать. Но на самом деле, работы достаточно.
- Во-первых, выяснение и анализ требования. Этим занимаются QA-инженеры — ведь, когда менеджер проекта составляет требования, зачастую упускается очень многое.
- Во-вторых, оценивание затраты времени на работу с проектом. Когда менеджер проекта спрашивает, сколько нужно времени на написание тестовых случаев, функциональное тестирование и т. п., нужно всё это подсчитать.
- В-третьих, работа с тестовой документацией, написание тест-кейсов, составление чек-листов и баг репортов.
- В-четвертых, в нашем проекте проводится функциональное, регрессионное и кросс-браузерное тестирование (т. к. у нас — веб-приложение, и в каждом браузере — свои ошибки).
- В-пятых, QA-инженеры занимаются поддержкой релиза: каждое утро перепрохождение упавших ночных тестов, а также acceptance- и smoke-тестирование. Но это не значит, что вся команда занята релизом. Релизом заняты люди, у которых меньше приоритетных заданий — наша команда самоорганизующаяся.
Еще есть координатор релиза — человек, который отвечает за релиз. Он готовит отчет об обнаруженных ошибках для заказчика и ведет с ним переговоры. Со стороны заказчика также есть специальный человек, который общается с нашей командой.
Также стоит рассказать, чем именно занимаются автоматизаторы в нашем проекте.
Роль и обязанности автоматизатора:
- Разработка автоматизированных тестов.
- Поддержка существующих автоматизированных тестов, чтобы они были актуальными.
- Поддержка релиза. От Selenium-команды у нас тоже есть координатор релиза, который отвечает непосредственно за ночные тесты, их поддержку. Таким образом, он отвечает за релиз и тоже может общаться непосредственно с заказчиком.
- Поддержка регрессионного тестирования.
Принципы непрерывной поставки
Наконец, я бы хотела рассказать о главных принципах, на которых, по моему мнению, основывается практика непрерывной поставки.
1. Процесс релиза и разворачивания должен быть повторяемым и надежным. Однажды запущенный процесс останавливать больше нельзя — даже если вы ничего нового не выпускаете.
2. Автоматизированные тесты должны покрывать 80 — 90% функционала — без этого процесс не пойдет.
3. Нужно часто проходить тестами по уязвимым местам. Если вы видите, что в каком-то месте у вас часто падают тесты или много ошибок, это место нужно тестировать почаще и убеждаться, что наступают улучшения и что-то исправляется.
4. Качество нужно строить сразу. Это относится не только к разработчикам, но и к тестировщикам. Бывает, что QA-инженеры проверяют баг-репорты на локальных машинах разработчиков, чтобы не допускать попадания не исправленных багов в общей репозиторий. Тогда разработчик исправляет ошибку у себя локально, это гораздо дешевле и быстрее.
5. Каждый несет ответственность за релиз. Благодаря этому, у нас хорошо налажена коммуникация. Если у QA-инженеров, возникают вопросы, мы можем спокойно написать разработчику, и разработчик тоже может нас о чем-то просить.
Несмотря на достоинства, у концепции непрерывной поставки есть, конечно, и минусы. Эта практика не подходит для всех проектов — удастся ли ее реализовать, зависит от проекта и от команды, которая занимается проектом. А для меня главный минус — рутинность процесса. Приходя каждый день, мы видим одно и то же приложение, прогоняем тесты и, естественно, можем что-то упустить, потому что бдительность теряется. Поэтому мы в команде стараемся разбивать всё на части, и один человек не занимается долго одной частью — в разные дни человек можно выполнять разные задачи. Это вносит разнообразие в процесс.
Главное же достоинство непрерывной поставки — довольный заказчик, потому что он может получать то, что хочет, очень быстро, и иметь с этого доход.
