Mercurial hg, я правильно делаю

Question

Мы находимся в процессе преобразования из CVS в Mercurial hg.

Наша инфраструктура - Windows 2003 / IIS6

• Каждый разработчик разрабатывает на своей машине
• 1xDevelopment server
• 1xStaging server
• Производственная среда

Вот что я сделал до сих пор:

Установил Mercurial на моей машине, в разработкесервер и на промежуточном сервере.

1. Создан репозиторий на dev.сервер.
2. Импортировал наш CVS-репозиторий туда.
3. клонировал этот репозиторий на мою локальную машину.
4. клонировал этот репозиторий на наш промежуточный сервер.

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

Теперь, если я правильно понимаю, мы должны делать это:

Local:

1. hg branch myfeature1 // Начать работу над feature1

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

обновление hg по умолчанию hg ветка bugfix1 // исправление ошибки hg commit --rev bugfix1 // готово исправление ошибки, которую мы фиксируем hg push --rev bugfix1-f // - здесь f выглядит странно, заставляя создать новую ветку hg update feature1 // мы возвращаемся к работе над feature1 hg commit --rev feature1 // готовая работа commit hg push --rev feature1

DEV

1. hg branch // мы видим исправление и feature1
2. hg merge --rev bugfix1
3. hg commit // коммит bugfix1
4. hg merge --rev feature1
5. hg commit // коммит feature1 // Мастер разработкитеперь наш основной ствол готов к новому разработчику, содержащему feature1 и bugfix1.

Staging (QA должен подписать это важное исправление перед тестированием feature1

1. hg входящие // мы видим новый материал
2. hg pull --rev bugfix1
3. hg merge --rev bugfix1
4. hg commit
5. // QAтестирование и завершение работы bugfix1 мы клонируем в производственное репо и синхронизируем.
6. // QA теперь может тестировать feature1, который мы завершили через несколько дней после bugfix1
7. hg pull --rev feature1
8. hg merge --rev feature1
9. hg commit // принятие функции merge feature1
10. // QA test feature1 и signoff
11. Мы клонируем в производственный репозиторий и синхронизируем.

Имеет ли этот способ смысл?Я усложняю вещи, и это укусит меня в задницу позже?

Answer 1

Похоже, вы поняли концепции отлично, но у вас есть некоторые странности и некоторые вопросы, я приведу их в виде списка ниже:

1. commit не принимает опцию --rev. Он фиксирует текущий рабочий каталог как новый набор изменений, чей родитель (или родители, если это слияние) возвращает то, что hg parents возвращает, то есть всегда то, к чему вы в последний раз hg update отредактировали.
2. вашему hg push --rev bugfix1 -f не потребуется -f в очень новых (1.5+) версиях Mercurial. Исторически предупреждение «вы создаете новую голову» обычно означало, что вы забыли объединить, но теперь, если новая глава - это новая именованная ветвь, предупреждение подавляется.
3. Если бы я был вашим человеком, который исправлял аварийную ошибку на моей локальной машине, я бы просто создал новый клон, выполнил ветвь и исправил там. Если вы настроили поддержку своего веб-сервера / веб-приложения, вы можете легко / автоматически разрешать новые экземпляры в новых местах пути
4. В вашей промежуточной среде я осознаю желание, чтобы они тестировали исправление независимо от функции, и это хорошая идея, ваша группа обеспечения качества не должна объединяться. Сделайте так, чтобы разработчики объединились, и чтобы команда QA подтвердила внесенные изменения в свою рабочую область. Например, набор изменений разработчика, созданный на шаге 3 DEV, уже обеспечивает правильную интеграцию исправления ошибки и того, что должно быть, поэтому команда QA ревизует эту ревизию, которая будет находиться в ветке «по умолчанию». Аналогично, после того, как QA утвердит исправление и будет готово перейти к функции, попросите их вытащить из dev набор изменений, созданный на шаге 5. dev.

Помните, что слияние - это тоже кодирование - человек, выполняющий слияние, делает выбор в отношении того, что должно и не должно быть. Специалисты по тестированию могут быть способны на это, но это работа разработчика. Кроме того, почему это дважды? Обычная передача обслуживания для этого - что-то вроде "QA, вытащите ревизию 897a9d9f9a7 и протестируйте, пожалуйста - разработчики". Если вы хотите получить фантазию, у вас может быть такой тег, как «readyforQA», чтобы разработчики двигались по ветке «по умолчанию» по ходу дела (в этом примере они будут hg tag после своих шагов 3 и 5 и дадут QA знать, что есть новые вещи для тяги.

Единственный совет, который я бы дал вам, - не пытайтесь чрезмерно спроектировать процесс. DVCS приводят к беспорядочному способу работы, сначала это немного пугает, но имеет тенденцию работать. Вы обнаружите, что у подгрупп и пар людей есть клоны, о которых вы никогда не знали, и, в конце концов, если у вас есть несколько жестких правил, таких как «ничего не идет в производство без первого прохождения QA», то все остальное работает само собой.