Наша команда разработчиков использовала стратегию ветвления GitFlow , и это было здорово!
Недавно мы наняли пару тестировщиков, чтобы улучшить качество нашего программного обеспечения. Идея состоит в том, что каждая функция должна быть протестирована / QA тестером.
В прошлом разработчики работали над функциями в отдельных ветвях функций и по завершении объединяли их обратно в develop
ветку. Разработчик сам проверит свою работу на этой feature
ветке. Теперь с тестерами мы начинаем задавать этот вопрос
В какой ветви тестировщик должен тестировать новые функции?
Очевидно, есть два варианта:
- в отдельной функциональной ветви
- на
develop
ветке
Тестирование в ветке разработки
Изначально мы считали, что это верный путь, потому что:
- Эта функция тестируется со всеми другими функциями, объединенными в
develop
ветку, с момента ее разработки. - Любые конфликты можно обнаружить раньше, чем позже
- Это облегчает работу тестировщика, он
develop
всегда имеет дело только с одной веткой ( ). Ему не нужно спрашивать разработчика, какая ветвь предназначена для какой функции (функциональные ветки - это личные ветки, управляемые исключительно и свободно соответствующими разработчиками).
Самые большие проблемы с этим:
develop
Филиал загрязняется с ошибками.Когда тестировщик обнаруживает ошибки или конфликты, он сообщает о них разработчику, который исправляет проблему в ветке разработки (ветка функций была заброшена после слияния), и впоследствии могут потребоваться дополнительные исправления. Множественные коммиты или слияния подпоследовательностей (если ветка заново создается из
develop
ветки для исправления ошибок) делают откат функции изdevelop
ветки очень трудным, если это возможно. Есть несколько функций, которые объединяются и фиксируются вdevelop
ветке в разное время. Это создает большую проблему, когда мы хотим создать выпуск только с некоторыми функциями вdevelop
ветке.
Тестирование в функциональной ветке
Мы подумали еще раз и решили, что нужно протестировать функции в ветках функций. Перед тестированием мы объединяем изменения из develop
ветки в функциональную ветку (догоняем develop
ветку). Это хорошо:
- Вы по-прежнему тестируете эту функцию с другими основными функциями.
- Дальнейшее развитие (например, исправление ошибки, разрешение конфликта) не приведет к загрязнению
develop
ветки; - Вы можете легко решить не выпускать функцию, пока она не будет полностью протестирована и одобрена;
Однако есть и недостатки.
- Тестировщик должен выполнить слияние кода, и в случае конфликта (что весьма вероятно) он должен попросить помощи у разработчика. Наши тестировщики специализируются на тестировании и не умеют кодировать.
- функция может быть протестирована без наличия другой новой функции. например, функция A и B тестируются одновременно, две функции не знают друг друга, потому что ни одна из них не была объединена в
develop
ветку. Это означает, что вам придется снова протестироватьdevelop
ветку, когда обе функции все равно будут объединены с веткой разработки. И вы должны не забыть проверить это в будущем. - Если функция A и B протестированы и одобрены, но при объединении обнаружен конфликт, оба разработчика обеих функций считают, что это не его собственная ошибка / работа, поскольку его ветвь функции прошла тестирование. В общении есть лишние накладные расходы, и иногда тот, кто разрешает конфликт, разочаровывается.
Выше наша история. Имея ограниченный ресурс, я бы не хотел тестировать все везде. Мы все еще ищем способ лучше с этим справиться. Я хотел бы услышать, как другие команды справляются с подобными ситуациями.
Ответы:
Мы делаем это следующим образом:
Мы тестируем ветки функций после того, как объединим с ними последний код ветки разработки. Основная причина в том, что мы не хотим «загрязнять» код ветки разработки до того, как функция будет принята. Если функция не будет принята после тестирования, но мы хотели бы выпустить другие функции, уже объединенные при разработке, это было бы адом. Разработка - это ветка, из которой создается релиз, и поэтому лучше быть в готовом к выпуску состоянии. Длинная версия состоит в том, что мы тестируем в несколько этапов. Более аналитически:
Что вы думаете об этом подходе?
источник
Нет. Не надо, особенно если «мы» - тестировщик качества. Слияние будет включать разрешение потенциальных конфликтов, что лучше всего делать разработчикам (они знают свой код), а не тестировщикам QA (которые должны приступить к тестированию как можно быстрее).
Заставьте разработчика выполнить перебазирование своей
feature
ветки поверхdevel
и протолкнуть этуfeature
ветку (которая была подтверждена разработчиком как компилирующая и работающая поверх самого последнегоdevel
состояния ветки).Это позволяет:
develop
, но только если не конфликта обнаруживаются GitHub / GitLab.Каждый раз, когда тестировщик обнаруживает ошибку, он / она сообщает об этом разработчику и удаляет текущую ветку функции.
Разработчик может:
feature
ветку.Общая идея: убедитесь, что часть слияния / интеграции выполняется разработчиком, оставляя тестирование QA.
источник
Лучшим подходом является непрерывная интеграция , при которой общая идея состоит в том, чтобы как можно чаще объединять ветки функций в ветку разработчика. Это снижает накладные расходы на боли слияния.
Полагайтесь на автоматические тесты, насколько это возможно, и пусть сборки будут автоматически запускаться с модульных тестов Jenkins. Попросите разработчиков выполнить всю работу по слиянию своих изменений в основную ветку и предоставить модульные тесты для всего своего кода.
Тестировщики / QA могут принимать участие в проверках кода, отмечать модульные тесты и писать автоматические интеграционные тесты, которые будут добавлены в регрессионный набор по мере завершения функций.
Для получения дополнительной информации перейдите по этой ссылке .
источник
Мы используем то, что мы называем «золотом», «серебром» и «бронзой». Это можно назвать prod, staging и qa.
Я назвал это моделью плавильного котла. Это хорошо работает для нас, потому что у нас огромная потребность в QA в сфере бизнеса, поскольку требования могут быть трудными для понимания по сравнению с техническими аспектами.
Когда ошибка или функция готовы к тестированию, они переходят в «бронзу». Это запускает сборку jenkins, которая помещает код в предварительно созданную среду. Наши тестировщики (кстати, не супертехнологи) просто нажимают на ссылку и не заботятся о системе контроля версий. Эта сборка также запускает тесты и т. Д. Мы ходили туда и сюда по этой сборке, фактически отправляя код в среду тестирования \ qa, если тесты (модульные, интеграционные, селеновые) терпят неудачу. Если вы тестируете в отдельной системе (мы называем ее ведущей), вы можете предотвратить внесение изменений в среду qa.
Первоначально опасались, что у нас будет много конфликтов между этими функциями. Это действительно происходит, когда функция X создает впечатление, что функция Y ломается, но это происходит достаточно редко и действительно помогает. Это помогает получить широкий спектр тестирования за пределами того, что кажется контекстом изменения. Много раз вам повезло, что вы узнаете, как ваше изменение влияет на параллельную разработку.
Как только функция проходит проверку качества, мы переводим ее в категорию «серебряных» или промежуточных. Выполняется сборка, и снова запускаются тесты. Еженедельно мы вносим эти изменения в наше «золото» или дерево продуктов, а затем внедряем их в нашу производственную систему.
Разработчики начинают свои изменения с золотого дерева. Технически вы можете начать с постановки, так как они скоро будут расти.
Экстренные исправления вносятся прямо в золотое дерево. Если изменение является простым и сложным для QA, оно может перейти непосредственно в серебро, которое попадет в дерево тестирования.
После нашего выпуска мы переводим изменения с золота (prod) в бронзу (тестирование), чтобы все было синхронизировано.
Возможно, вы захотите выполнить перебазирование, прежде чем вставлять в промежуточную папку. Мы обнаружили, что время от времени очищая дерево тестирования, оно остается чистым. Бывают случаи, когда функции забывают в дереве тестирования, особенно если уходит разработчик.
Для крупных функций, разработанных несколькими разработчиками, мы создаем отдельное общее репо, но объединяем его в дерево тестирования, когда все будем готовы. Что-то делается для того, чтобы отказываться от QA, поэтому важно держать ваши наборы изменений изолированными, чтобы вы могли добавлять, а затем объединять / сквошировать в свое промежуточное дерево.
«Выпечка» - тоже приятный побочный эффект. Если у вас есть какое-то фундаментальное изменение, которое вы хотите оставить на некоторое время, для этого есть хорошее место.
Также имейте в виду, что мы не поддерживаем прошлые выпуски. Текущая версия всегда является единственной версией. Даже в этом случае у вас, вероятно, есть основное дерево запекания, где ваши тестировщики или сообщество могут наблюдать, как взаимодействуют различные материалы участников.
источник
Я бы не стал полагаться только на ручное тестирование. Я бы автоматизировал тестирование каждой функциональной ветки с помощью Jenkins. Я настраиваю лабораторию VMWare для запуска тестов Jenkins в Linux и Windows для всех браузеров. Это действительно отличное кроссбраузерное решение для кросс-платформенного тестирования. Тестирую функционал / интеграцию с Selenium Webdriver. Мои тесты на селен выполняются под Rspec. И я написал их специально для загрузки jRuby в Windows. Я запускаю традиционные модульные тесты под Rspec и тесты Javascript под Jasmine. Я настраиваю безголовое тестирование с помощью Phantom JS.
источник
В нашей компании мы не можем использовать гибкую разработку и нуждаемся в одобрении каждого изменения со стороны бизнеса, это вызывает множество проблем.
Наш подход к работе с GIT таков;
Мы внедрили «Git Flow» в нашей компании. Мы используем JIRA, и в производство должны поступать только утвержденные билеты JIRA. Для утверждения Test мы расширили его, создав отдельную Test-Branch.
Шаги по обработке заявок JIRA:
Разделение каждого запроса на отдельную функцию гарантирует, что только утвержденные изменения попадут в рабочую среду.
Полный процесс выглядит так:
источник