Как настроить систему DVCS, которая хранит некоторые вещи, которые нам нравятся в нашей централизованной VCS?

Question

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

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

1) Каждый раз, когда разработчик проверяет изменения в своей ветке, мы выполняем сборку и тестирование всего на серверах с последующим автоматическим развертыванием всех проектов в этой тестовой среде разработчиков.

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

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

Я пытаюсь понять, как это может работатьс DVCS (в частности, мы тестируем с Mercurial).

Я надеюсь, что смогу осуществить что-то вроде этого:

1) Мы настроим центральное хранилище и создадим ветки Main и Release в дополнение к 1 ветке для каждого разработчика.

2) Все разработчики клонируют репозиторий на свой локальный компьютер.

3) Вся работа выполняется в их личной ветке против локального хранилища.

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

5) Затем они отправят свои изменения в центральное хранилище.

6) Некоторые CI-сервисы восприняли бы это изменение, вызвав сборку / тестирование / развертывание для dev всех наших проектов в этой ветви.

7) Если бы все было в порядке, разработчикотправьте мне электронное письмо, в котором говорится, что их ветка готова к слиянию с Main.

8) Затем я могу объединить их изменения, подключившись напрямую к репозиторию remove, или выполнив pull-> merge->push.

Итак, чтобы справиться с нашими запросами:

1) Я предполагаю, что есть некоторые инструменты CI, которые могут наблюдать за веткой в ​​Mercurial и запускать процесс сборки / тестирования / развертывания(как CC.Net).

2) Я все еще могу управлять окончательным процессом слияния из DevX в Main, либо подключаясь к удаленному репо, либо вытягивая, объединяя и проталкивая мой локальный репо.

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

Так что у меня естьэто в основном верно?

Answer 1

Да, у вас есть все это право.Что касается ваших окончательных предположений:

1) Для CruiseControl.NET имеется Блок управления источником Mercurial Source .Еще один CI-сервер, о котором я слышал, используется в Mercurial: Jenkins .

2) Правильно.Для интеграции с Main я бы предпочел вытягивать (из любого) и объединять на своем собственном компьютере перед отправкой, а не объединять на сервере.

3) Точно так.

Звучит так, что ваши разработчики достаточно дисциплинированы, но на всякий случай вам нужно лучше контролировать определенные аспекты ваших операций:

• Вы можете использовать hooks для выдачи предупреждений, когдакто-то пытается слить свою ветку в Main.Внутрипроцессные хуки должны быть написаны на Python, но у них есть доступ к Mercurial API таким образом.Вы также можете разместить на сервере зацепки, которые отклоняют запросы, содержащие слияние с Main, которое не выполняется некоторыми пользователями.
• Один из способов, которым некоторые организации управляют интеграцией, - это сценарий "только по запросу".Лишь немногие разработчики могут отправить в официальный репозиторий, а другие разработчики отправляют им запросы на извлечение. глава 6 в книге Mercurial также охватывает эту проблему.

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