Bug prod что это

GitFlow в его простоте от dev до prod

В какой ветке вести разработку? Из какой ветки деплоить на PROD? В какой ветке чинить багу, выявленную на IFT? Многие команды закрыли для себя этот вопрос, но для многих он остаётся открытым.

Этот пост не будет содержать каких-то особых ноу-хау и киллер-фич. В нём я расскажу наиболее простую и понятную (лично мне) практику релизных циклов на основе git flow. И постараюсь объяснить каждое своё решение и каждый подход.

Сколько понадобится стендов?

В идеале, в дополнение к проду, хорошо иметь ещё два стенда: интеграционно‑функциональный (далее — IFT) и, конечно, DEV. Опишем каждый стенд, его задачи и назначение более подробно:

Основной минимум стендов

DEV. Стенд для разработки. Все новые фичи и починенные баги в рамках спринта в первую очередь выкатываются на этот стенд. Активное тестирование фич и исправленных багов происходит тут. Деплоит на него в основном команда разработки. Содержит синтезированные данные.
IFT. Стенд для интеграционно‑функционального тестирования. На этапе отладки фичи и исправленные баги тестируются на нём. Как правило, размещается в тестовом окружении заказчика и содержит реальные обезличенные данные. Если у Вас проект чуть сложнее CRUD, а стенда IFT у Вас нет, разрабатывать будет больно.
PROD. Продуктивный стенд, с реальными посетителями. Вершина иерархии окружения. Деплоем на такие стенды занимается специальная команда внедрения. Лучше, если у разработчиков вообще не будет к нему доступа.

Как управлять разработкой для этого минимума стендов, мы и поговорим в этом посте.

Как мы поделим спринт?

Спринт мы поделим на две неравные части: разработка и отладка.

Активная разработка — это бо́льшая часть спринта, во время которой реализуются фичи, заявленные в спринте и исправляются баги, найденные на DEV‑стенде.

Отладка — это вторая часть спринта, которая наступает после реализации фич спринта, а тестирование переносится на IFT‑стенд.

Какие основные ветки потребуются для разработки?

Итак, у нас 3 стенда. Для каждого из них лучше создать свою ветку, назвав её соответствующим образом: prod/master , ift/test , dev/develop — как угодно, главное, чтобы по названиям было понятно их назначение или они хотя бы были в понятийной среде разработки. В нашем примере, ветки будут master , test и develop .

Правило первое. Каждый стенд имеет свою одну-единственную мастер-ветку. Разворачивание приложения на стенд происходит только из неё.

Выглядеть это будет следующим образом:

Правило деплоя на стенды.

Этот контракт необходимо поддерживать всеми силами.

Этап активной разработки.

Активная разработка ведётся только из ветки develop . Реализуете фичу — ответвляете ветку feature/XXX от develop . Исправляете баг — пожалуйста, bug/XXX . По окончании разработки, ветка вливается обратно в develop , а оттуда уже изменения попадают на DEV-стенд.

Активная разработка.

Правило второе. Вся активная разработка ведётся в ветках, образованных от ветки develop , которые по окончании разработки в них вливаются обратно в develop .

На DEV-стенде размещено приложение в состоянии, соответствующем текущему спринту; на IFT и PROD — предыдущему. Выглядит это так:

Версии приложения во время активной разработки

Как видно из картинки, на IFT и PROD код ещё в версии спринта А, тогда как на DEV-стенде уже в версии спринта Б.

Этап отладки.

По окончании активной разработки, весь код из ветки develop вливается в ветку test . Тестирование на DEV‑стенде прекращается и переносится на IFT‑стенд. Этот процесс можно назвать code freeze в рамках спринта.

С этого момента, разработчик уже может брать задачи следующего спринта и продолжать реализовывать обычным способом, в ветках от develop , по окончании реализации которых он в обычном режиме деплоится на DEV‑стенд. Происходит разделение стендов на уровне спринтов: IFT‑стенд принадлежит текущему спринту, тогда как DEV‑стенд — будущему.

С момента отладки уже можно проводить планирование следующего спринта, чтобы определить scope задач, которые разработчик уже может брать в работу.

Таким образом, на этапе отладки каждый стенд находится в версии своего спринта: тогда как PROD всё ещё в версии предыдущего спринта, то IFT уже в версии нынешнего, а DEV — в версии спринта будущего.

Версии приложения на время отладки

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

Этап отладки: что, если был найден баг на стенде IFT?

Интеграционно‑функциональный стенд имеет несколько важных отличий от стенда разработки: а) он находится в окружении заказчика, что позволяет отладить взаимодействие с этим окружением, и б) он наполнен не синтезированным мусором, а обезличенными данными с PROD. Это позволяет тестировщику провести тестирование фич на уровне, наиболее близком к продуктивному.

Конечно, целью такого тестирования является обнаружение новых багов.

Итак, тестировщик нашёл новый баг. Как мы помним, IFT находится в состоянии текущего спринта, а DEV — будущего. Если мы для устранения бага создадим ветку от develop , то к тому моменту в develop уже могут оказаться фичи следующего релиза, которые не были ещё протестированы и не должны попасть в текущий релиз. Тогда, после устранения бага, нам придётся черри‑пикать изменения из develop в test и держать потом эти черри‑пики в уме, но это плохой выход из ситуации (в целом, практика черри‑пиков является костылём и в разработке может применяться только от безысходности).

Отсюда вытекает правило третье:

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

Иными словами, если на IFT был найден баг, для его устранения мы образуем ветку из test . После исправления бага, ветка вливается обратно в test , происходит деплой на IFT, баг тестируется повторно, и если всё ок, ветка test вливается в develop .

Исправление багов IFT

При таком подходе, сохраняется следующая взаимосвязь: ветка test содержит в себе версию кода, актуальную по текущий релиз; ветка develop содержит в себе версию кода, актуальную по текущий релиз + изменения в рамках следующего релиза.

Окончание этапа отладки и заход на новый спринт.

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

После окончания этапа отладки изменения из ветки test переносятся в ветку master и деплоятся на PROD. Версионность стендов возвращается к состоянию активной разработки (в следующей итерации), начинается новый спринт, с его победами и поражениями.

Начало нового спринта

Как будет выглядеть полный релизный цикл?

В соответствии с вышеописанным, полный релизный цикл будет выглядеть так:

Полный релизный цикл

Вместо заключения: что делать, если баг найден на проде?

Мы приложили все усилия для того, чтобы это не произошло. Но мы точно знаем, что это произойдёт. Что делать?

В первую очередь, попробуйте воспроизвести баг на стенде IFT. Если вы держите IFT в состоянии, актуальном PROD, он в очень высокой долей вероятности воспроизведётся. Если воспроизвёлся, переходим к разделу «Этап отладки: что, если был найден баг на стенде IFT?«, правилу 3 и далее вниз по посту: исправили на IFT, влились из IFT в develop , влились в master , зарелизились на PROD повторно.

Если баг не воспроизвёлся на IFT, значит, это проблема чисто PROD и применяем правило 3 уже к нему: бранчуемся из master , исправляем проблему, далее переливаем изменения из master → test → develop .

Программирование
Системы управления версиями
Управление разработкой

Home

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

Шаг 1: сохраняйте спокойствие.

Так как именно мы – те самые люди, которые тестировали продукт и передавали его в релиз, легко удариться в панику при обнаружении бага на проде. Мы тут же спрашиваем себя «Как же это могло произойти?», и можем начать агонизировать в поиске ответов. Однако это непродуктивно – нашей приоритетной задачей должно быть убеждение, что баг исправлен. Если мы не сохраним спокойствие, то можем недоисследовать проблему или недотестировать исправление.

Шаг 2: воспроизведите проблему.

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

Шаг 3: узнайте как можно больше.

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

Шаг 4: выявите первопричину.

На этом этапе ваш разработчик уже занят разбирательством, что вызывает проблему. Когда он(а) это выяснит, удостоверьтесь, что вам сообщили, что это была за проблема, и убедитесь, что вы все поняли. Это поможет вам разобраться, как тестировать исправление, а также определить, какие регрессионные тесты тут понадобятся.

Шаг 5: решите, когда исправлять проблему

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

Решая, когда исправлять баг, подумайте вот о чем:

Сколько пользователей им затронуто?
Насколько он серьезен?

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

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

Шаг 6: протестируйте исправление.

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

Шаг 7: проанализируйте, что пошло не так.

Крайне заманчиво вздохнуть с облегчением и перейти к чему-то другому, когда баг прода исправлен. Однако тут очень важно найти время на то, чтобы понять, как именно он попал на прод. Это не относится к поиску виноватых и козлов отпущения – все совершают ошибки, неважно, разработчики ли, тестировщики, продакт-оунеры, менеджеры или релизные инженеры. Суть в том, чтобы понять, что произошло, чтобы не допустить такой проблемы впредь.

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

Неважно, в чем было дело – убедитесь, что вы внятно донесли причину до вашей команды. Н бойтесь взять ответственность за свою роль в возникновении проблемы. См. статью про семь оправданий тестировщиков, чтобы узнать больше.

Шаг 8: проведите мозговой штурм для выявления способов предотвращения схожих проблем.

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

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

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

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