Как QA тестирует код и сливается со стабильной веткой в ​​Mercurial?

Question

Моя команда разработчиков только начинает работу с Mercurial, и мы запутались в следующем:

Мы команда php webdev.

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

У нас есть 2 сотрудника QA. Все исправления и функции должны быть протестированы, прежде чем они будут запущены.

Пока что у каждого разработчика есть свой репозиторий. У нас есть центральный сервер под названием WebDev с собственным репо. Разработчик извлекает данные из WebDev, затем вносит некоторые изменения (т. Е. Исправляет ошибку) и передает Webdev. Затем тестер QA проверит код на центральном сервере (поэтому тестирует код в WebDev) и, если он сработает, отправит этот код на наш рабочий сервер.

Это не очень хорошо работает, потому что ... что происходит, когда Developer-1 (dev-1) исправляет ошибку и выдвигает WebDev. В то же время dev-2 исправляет другую ошибку и добавляет WebDev. специалист по тестированию тестирует там код и утверждает второе исправление, но не первое. Как бы он подтолкнул второй набор к производству без первого? Похоже, мы теряем все преимущества системы контроля версий.

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

Спасибо !!

---- UPDATE ----

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

1) dev-1 исправляет ошибку для bug-101. он тянет с webdev, сливается и фиксирует локально. он устанавливает это в тестировании. QA тянет прямо из своего хранилища и тестирует локально. если он пройдет, QA вытащит из webdev -> merge -> push в webdev (и, если это большое изменение, можно еще раз просмотреть там, чтобы убедиться, что все в порядке). поэтому мы тестируем только одну вещь за один раз, WebDev содержит только те изменения, которые были протестированы локально тестировщиками и всегда стабильны.

2) создавать ветки для всего. dev-1 создает ветку "bugfix-101", а затем передает ее в webdev, не объединяя ее. QA может протестировать разветвленный код и, если он утвержден, объединить его с веткой по умолчанию. У меня есть четыре вопроса по этому методу: (а) возможно ли отправить открытую ветку в удаленный репозиторий? (б) если QA объединит и закроет ветку на webdev, в следующий раз, когда я вытащу, будет ли локальное репо также закрываться и объединять ветку? и (c) как вы тестируете из разветвленного кода? когда я запускаю веб-приложение в браузере, как я могу выполнить тестирование из ветви? (d) есть ли проблемы с производительностью при создании такого количества именованных ветвей (при условии, что большинство из них будут быстро закрыты)?

Еще раз спасибо.

Answer 1

Фоллов до Бассама:

Ваша команда явно упускает (действительно простое) ветвление и слияние в Mercurial и работает с монолитной (?) Веткой по умолчанию.

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

1. Каждый член QA имеет постоянный клон репо и только тянет репо разработчика по запросу (быстрее, вытягиваетсяизменения более заметны);возможно, ветвь QA также имеет смысл
2. Использовать отдельную ветвь для каждого большого изменения (функция или исправление)
3. Когда у разработчика есть набор изменений X в ветке "ИсправлениеY "в своем репо закончен и готов к тестированию, он просит QA" вытащить и проверить ревизию X "
4. QA делает это, возможно, объединяет" Bugfix Y "с веткой" QA "в his repo (как знак «пройден тест»?) И объединяет ветвь «QA» с основной линией (ветвь «Стабильный» или «по умолчанию»), и, наконец, отправляет результаты в нужные места назначения (WebDev и Prod?)
5. При каждом следующем запросе шаг 4 должен повторяться

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

Answer 2

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

В качестве примечания, стоило бы взглянуть на эти два ответа на сайте стека обмена Kiln, чтобы увидеть стратегии репозитория Fog Creek (посмотрите, как они едят свои собственные).корм для собак):

• http://kiln.stackexchange.com/questions/354/release-repo-suggestions/355#355
• http://kiln.stackexchange.com/questions/500/should-i-use-more-than-one-repository/504#504

Обновление

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

Answer 3

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

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

Примечание. Мы работали по обеим стратегиям на моем рабочем месте.