Шаблоны для непрерывной интеграции и DVCS

В настоящее время мы используем Subversion и TeamCity, мы собираемся перейти к использованию Mercurial (в частности, Kiln, поскольку мы пользователи FogBugz).

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

В SVN мы используем ограниченное количество центральных репозиториев - по одному на каждый проект (более или менее одно решение Visual Studio), поэтому легко запустить сборку и получить подтверждение того, что все файлы были зафиксированы и что нет паразитные зависимости и т. д., и т. д. Но если мы собираемся принять правильное продвижение меркуриала, нам нужно иметь больше экземпляров репозитория - где я ожидаю, что изменения, как правило, будут направлены к окончательному «живому» репо. Проблема, с которой я борюсь, заключается в том, что живое репо кажется мне слишком «запоздалым», чтобы запускать мои сборки CI OTOH, одна сборка CI на проект на разработчика, вероятно, чрезмерна (и вызывает другие проблемы).

Я немного ловлю рыбу, но это потому, что одна из вещей, которую дает центральный репозиторий Subversion (я, с нашей настройкой!), Это большая ясность о том, что и когда строить.

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

Во-первых, наличие нескольких сборок на проект в TeamCity - действительно правильный путь. Природа платформы делает это действительно легким - кнопка копирования есть по причине.

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

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

Мы используем Kiln около года и попробовали несколько разных вещей. В конечном итоге мы использовали именованные ветви (в отличие от клонов ветвей) со следующей стратегией ветвления:

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

Итак, работа начинается с создания ветви элемента из текущей подсказки по умолчанию . Когда функциональная ветвь завершена *, ветвь закрывается и возвращается в стандартное состояние .

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

Что касается непрерывной интеграции, мы делаем две вещи:

• Интеграция «всегда включен», которая контролирует состояние по умолчанию
• Новые интеграции для каждой ветки релиза

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

_{* Наше определение «готово» заключается в том, что эта функция обновлена ​​с учетом слияний по умолчанию и была одобрена при проверке кода.}

Если вы переходите на DVCS, например Hg, вы не только получаете «распределенную часть», но и получаете все возможности хорошего ветвления и слияния.

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

Паттерн «ветвь на задачу» не нов (см. Книгу Беркчука), но это определенно что-то, что можно попробовать.

Я объяснил это подробно здесь , и плюсы и минусы CI против "контролируемых" здесь .