Советы по настройке нашего рабочего процесса для веб-приложений php и mercurial

Question

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

Команда состоит из 6 разработчиков, 2 из которых также являются специалистами по обеспечению качества.Я много гуглил тему, и это ошеломляет!Пока единственное решение, которое я принял, это то, что мы будем использовать Mercurial.

Справочная информация: это веб-приложение, разработанное на PHP.Постоянная разработка новых функций (что означает одинаково постоянное исправление ошибок :-P) Мы начали с аутсорсинга всей веб-разработки, что означает, что наш производственный код размещен в другой компании.Таким образом, мы можем использовать Mercurial для разработки и тестирования в нашей внутренней сети, но когда он будет готов к запуску, нам нужно будет передать файлы в вашу компанию.(глупо? так оно и есть ... они также выполняют сео и другую работу для нас, поэтому руководство не собирается с ними расставаться).

Вот требования к рабочему процессу:

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

Моя идея настроить это ...

• каждый программист имеет свой собственный репозиторий
• есть центральныйdev repo
• есть QA-репозиторий

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

QA человек будет тянуть из dev в репозиторий QA.Поскольку многие люди могут настаивать на разработке, и мы хотим сосредоточиться на тестировании по одной новой функции за раз, MrQA может выбрать, какие наборы изменений применить (или использовать любую терминологию).тестирует фичу - работает!ftp к производству.Затем можно начать тестирование следующей функции из dev.

Для ошибок - программист сделает исправление в своем локальном репозитории, отправит его непосредственно в QA, а затем из QA оно выйдет в эфир.

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

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

Заранее спасибо, что пришли на помощь !!

Answer 1

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

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

Я думаю, что проблемы начинают накапливаться вокруг QA.Вы говорите:

Сотрудник QA вытянет из dev в репо QA.Поскольку многие люди могут настаивать на разработке, и мы хотим сосредоточиться на тестировании по одной новой функции за раз, MrQA может выбрать, какие наборы изменений применить

Это означает, что парень из QA выбирает вишню издерево разработчиков, поэтому я предполагаю, что он будет использовать что-то вроде graft .В этом случае у QA есть ветвь, которая не существует нигде в экосистеме разработчика.Когда разработчику необходимо исправить ошибку, он исправит это в своем дереве разработки или в ветке QA?Если он исправляет это в ветке QA (вот где была ошибка), как он возвращается к dev?Здесь я вижу проблемы, когда dev и QA постоянно расходятся.

Лично я бы рекомендовал прочитать , как это делает проект mercurial .По сути, для каждого выпуска есть именованная ветвь, которую будет тестировать QA.Любые исправления для QA идут в эту ветку, и они могут быть объединены обратно в ветки разработки.Нет сбора вишни как части нормального потока, так как я ожидаю, что в долгосрочной перспективе будет трудно управлять им.

Есть и другие рабочие потоки (вероятно, столько, сколько людей используютmercurial ;-)), но это хорошая отправная точка, и вы можете настроить ее по мере необходимости.

Answer 2

Последующие записи Павла

• Для команды из 6 человек, я также думаю, что вы можете использовать или не использовать "Cental Server": в самой простой форме команда может p2p-pull, когда это необходимо, и какой-то центральный сервер появится автоматически как (возможно - один из) репо некоторых QA-персон
• Подумайте «на берегу» (прочитайте Стиву Лошу для начала), какую модель ветки вы выберете и будете следовать в процессе (названные ветки / расширены и расширены до «git-workflow»? /, Отдельные репозитории)
• Частичное РЕПО на стороне QA может стать источником дополнительных проблем (см. Текст Павла снова). Может быть, полный клон и крепкое общение (команда маленькая) "Тест ветки X против по умолчанию" будет более чистым способом

что, если у нас одновременно два QA-сотрудника, которые тестируют в QA-репо (тестируют две новые функции)?

У каждого есть свой репо (они могут быть одинаковыми, но QA-тесты используются для разных веток). Может быть, здесь будет место Центрального QA-репо, в котором только QA может зафиксировать пройденные все тестовые наборы изменений и хэндл после фиксации опубликовать каждое изменение для сторонней третьей стороны

Я прочитал о наличии отдельных веток для каждой ревизии. отдельные ветки для каждой поставляемой версии

Надеюсь, это было "ветвь на элемент | ветвь на исправление | ветвь на второстепенный выпуск", а не ветвь на набор изменений

Окончательные выводы (просто ИМХО)

пригоден ли описанный выше рабочий процесс?

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

Это излишне для нашей маленькой команды?

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

это слишком упрощенно?

Здесь не видно чрезмерной простоты