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

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

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

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

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

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

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

Тестирование На Ветке Разработки

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

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

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

  • на develop ветка загрязнена ошибками.

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

Тестирование На Ветке Функций

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

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

тем не менее, есть некоторые недостатки

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

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

5 ответов


Как мы делаем это следующим образом:

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

для больших функций multi-developer мы создаем отдельное общее РЕПО, но объединяем его в дерево тестирования так же, когда мы все готовы. Вещи имеют тенденцию отскакивать от QA, поэтому важно держать ваши наборы изменений изолированными, чтобы вы могли добавлять, а затем объединять/сквош в свой промежуточное дерево.

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

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


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