Git стратегия ветвления, интегрированная с процессом тестирования/QA

Наша команда разработчиков использует стратегию ветвления GitFlow, и это было здорово!

Недавно мы наняли пару тестеров для улучшения качества нашего программного обеспечения. Идея состоит в том, что каждая функция должна быть проверена /QA с помощью тестера.

В прошлом разработчики работают над функциями в отдельных ветвях функций и после этого сбрасывают их обратно в ветвь develop. Разработчик сам проверит свою работу в этой ветке feature. Теперь с тестировщиками мы начинаем задавать этот вопрос

На какой ветке тестер должен тестировать новые функции?

Очевидно, есть два варианта:

в отдельной ветки функции
на ветке develop

Тестирование в области разработки

Изначально мы полагали, что это верный путь, потому что:

Эта функция протестирована со всеми другими функциями, объединенными с ветвью develop с момента ее создания.
Любые конфликты могут быть обнаружены раньше, чем позже
Это облегчает работу с тестером, он имеет дело только с одной ветвью (develop) в любое время. Ему не нужно спрашивать у разработчика, по какой ветке есть какая функция (ветки функций - это личные ветки, управляемые исключительно и свободно соответствующими разработчиками).

Самые большие проблемы с этим:

Филиал develop загрязнен ошибками.

Когда тестер обнаруживает ошибки или конфликты, он сообщает их разработчику, который исправляет проблему в ветке разработки (ветвь функции была оставлена после объединения), и после этого может потребоваться больше исправлений. Множественная подпоследовательность совершает или объединяется (если ветвь снова отлажена с develop ветвью снова для исправления ошибок) делает возможным откатывание функции из ветки develop очень сложно, если это возможно. Есть несколько функций, которые объединяются и фиксируются на ветке develop в разное время. Это создает большую проблему, когда мы хотим создать выпуск только с некоторыми функциями в ветке develop

Тестирование по ветке функций

Итак, мы снова подумали и решили протестировать функции на ветвях функций. Перед тем, как мы проверим, мы сменим изменения из ветки develop на ветвь функции (догоним с ветвью develop). Это хорошо:

Вы все еще проверяете функцию с другими функциями в основном
Дальнейшая разработка (например, исправление ошибок, разрешение конфликта) не будет загрязнять ветвь develop;
Вы можете легко решить не выпускать эту функцию до тех пор, пока она не будет полностью протестирована и одобрена;

Однако существуют некоторые недостатки

Тестер должен выполнить слияние кода, и если есть какой-либо конфликт (очень вероятно), он должен обратиться за помощью к разработчику. Наши тестеры специализируются на тестировании и не способны кодировать.
функция может быть протестирована без наличия другой новой функции. например Функции A и B одновременно тестируются, две функции не знают друг о друге, потому что ни одна из них не была объединена с ветвью develop. Это означает, что вам придется снова протестировать ветку develop, когда обе функции будут объединены в ветку разработки в любом случае. И вы должны помнить, чтобы проверить это в будущем.
Если функции A и B проверяются и утверждаются, но при объединении конфликт идентифицируется, обе разработчики для обеих функций считают, что это не его собственная ошибка/работа, потому что его функция проходит мимо теста. В общении есть дополнительные накладные расходы, и иногда тот, кто разрешает конфликт, разочаровывается.

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

Ответ 1

То, как мы это делаем, следующее:

Мы тестируем ветки признаков после того, как мы объединим последний код ветвей разработки на них. Основная причина заключается в том, что мы не хотим "загрязнять" код ветки разработки до того, как функция будет принята. В случае, если функция не будет принята после тестирования, но мы хотели бы выпустить другие функции, которые уже были объединены, чтобы развиться, что было бы адским. Разработка - это ветвь, из которой сделан релиз, и, следовательно, лучше быть в состоянии освобождения. Длительная версия - это то, что мы тестируем на многих этапах. Более аналитически:

Разработчик создает ветвь функции для каждой новой функции.
Развертывание функции (автоматически) развернуто в нашей среде TEST с каждой фиксацией для тестируемого разработчика.
Когда разработчик работает с развертыванием, и эта функция готова к тестированию, он объединяет ветвь разработки в ветки функций и развертывает ветвь функции, содержащую все последние изменения в TEST.
Тестеры тестируют TEST. Когда он закончит, он "принимает" историю и объединяет ветвь функции при разработке. Поскольку разработчик ранее объединил ветку разработки на функцию, мы обычно не ожидаем слишком много конфликтов. Однако если это может помочь разработчик. Это сложный шаг, я думаю, что лучший способ избежать этого - сохранить возможности как можно более мелкие/конкретные. В конце концов, всевозможные функции должны быть объединены, так или иначе. Конечно, размер команды играет определенную роль в этой сложной сложности.
Развернутая ветка также (автоматически) развертывается в TEST. У нас есть политика, что, несмотря на то, что сборки ветвей функций могут потерпеть неудачу, ветка разработки никогда не должна терпеть неудачу.
Как только мы достигли замораживания функции, мы создаем выпуск от разработки. Это автоматически развертывается при STAGING. Обширные тесты заканчиваются до развертывания производства. (хорошо, может быть, я немного преувеличиваю, они не очень обширны, но я думаю, что они должны быть). В идеале бета-тестеры/коллеги, то есть реальные пользователи должны там протестировать.

Что вы думаете об этом подходе?

Ответ 2

Перед тестированием мы сменим изменения из ветки разработки на ветвь функции

Нет. Не стоит, особенно если "мы" - тестер QA. Объединение будет включать в себя устранение потенциальных конфликтов, которые лучше всего делать разработчикам (они знают свой код), а не тестером QA (кто должен протестировать как можно быстрее).

Сделайте разработчику его ветку feature поверх devel и нажмите ветвь (которая была проверена разработчиком как компиляцией и работой над самым последним состоянием ветвления devel).
Это позволяет:

очень простая интеграция в ветки признака (тривиальное ускоренное слияние).
или, как рекомендовано Aspasia ниже в комментариях, a запрос pull (GitHub) или запрос на объединение (GitLab): сопровождающий выполняет слияние между ветвью PR/MR функции и develop, но только если конфликт не обнаружен GitHub/GitLab.

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

исправить ошибку
rebase поверх недавно появившейся ветки разработки (опять же, чтобы убедиться, что его/ее код работает в интеграции с другими проверенными функциями)
нажмите ветвь feature.

Общая идея: убедитесь, что часть слияния/интеграции выполнена разработчиком, оставив тестирование в QA.

Ответ 3

Наилучшим подходом является непрерывная интеграция, где общая идея состоит в том, чтобы как можно чаще объединить ветки функций в ветвь разработчика. Это уменьшает накладные расходы при слиянии.

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

Тестеры/QA могут принимать участие в обзорах кода, проверять модульные тесты и записывать автоматические тесты интеграции, которые будут добавлены в набор регрессии по мере завершения функций.

Для получения дополнительной информации ознакомьтесь с этой ссылкой.

Ответ 4

Мы используем то, что мы называем "золото", "серебро" и "бронза". Это можно назвать prod, staging и qa.

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

Когда ошибка или функция готовы к тестированию, она переходит в "бронзу". Это вызывает сборку jenkins, которая подталкивает код к предварительно построенной среде. Наши тестировщики (кстати, не очень технологичные) просто попали в ссылку и не заботятся об исходном контроле. Эта сборка также запускает тесты и т.д. Мы пошли туда и обратно по этой сборке, фактически нажимая код в среду тестирования \qa, если тесты (единица измерения, интеграция, селен) терпят неудачу. Если вы тестируете отдельную систему (мы называем ее ведущей), вы можете запретить вносить изменения в среду qa.

Первоначальный страх заключался в том, что у нас было бы много конфликтов между этими функциями. Случилось так, что функция X показала, что функция Y ломается, но она редко встречается и на самом деле помогает. Это помогает получить широкий спектр тестирования вне того, что кажется контекстом изменений. Много раз удачи вы узнаете, как ваши изменения влияют на параллельную разработку.

Как только функция проходит QA, мы переместим ее в "серебро" или этап. Выполняется сборка, и тесты снова запускаются. Еженедельно мы переносим эти изменения в наше "золото" или дерево prod, а затем развертываем их в нашу производственную систему.

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

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

После нашего выпуска мы подталкиваем изменения в золоте (prod) к бронзе (тестирование), чтобы сохранить все в синхронизации.

Вы можете захотеть переустановить, прежде чем входить в свою промежуточную папку. Мы обнаружили, что очистка дерева тестирования время от времени сохраняет его чистоту. Бывают случаи, когда функции отказываются в дереве тестирования, особенно если разработчик уходит.

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

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

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

Ответ 5

Я бы не полагался только на ручное тестирование. Я бы автоматизировал тестирование каждой ветки функций с помощью Jenkins. Я настраиваю лабораторию VMWare для запуска тестов Jenkins для Linux и Windows для всех браузеров. Это действительно потрясающий кросс-браузер, кросс-платформенное тестовое решение. Я тестирую функциональность/интеграцию с Selenium Webdriver. Мои тесты на селен проходят под Rspec. И я написал их специально для загрузки jRuby в Windows. Я запускаю традиционные модульные тесты под тестами Rspec и Javascript под Jasmine. Я настраиваю безгласное тестирование с помощью Phantom JS.