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

12

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

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

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

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


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

Murph
источник
Как вы думаете, почему слишком поздно запускать билды из центрального / «живого» репо?
c_maker
Если вы еще не были там, я предлагаю вам перейти на сайт обмена стеками Kiln ( kiln.stackexchange.com ). У них довольно много информации о том, как это настроить (вот один: kiln.stackexchange.com/questions/29/… Лично мы используем ветку для каждой функции и указываем сервер сборки на нашу "главную" ветку. )
Крис Филлипс
@Chris - у меня есть, на самом деле, нет, не затрагивая проблему CI ...
Murph

Ответы:

2

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

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

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

Уайетт Барнетт
источник
Wyatt, на мой взгляд, толчок должен произойти, когда у вас есть законченная единица работы (ish) - одно из преимуществ DVCS заключается в том, что мы можем локально фиксировать код, который не работает. Мне действительно очень не нравится идея что-либо делать по расписанию, потому что это конец дня. Существует отдельная проблема «резервного копирования», которая, для меня, заключается в настройке правила для бокового - при фиксации - другого клона, который существует просто для резервного копирования.
Мерф
2
Хитрость есть, что такое определение единицы работы? Это «эта функция завершена» или «этот кирпич успешно положен». Мы склоняемся к последнему, особенно с той моделью ветвления, где есть четко разграниченная ветвь разработки. Разбивать вещи лучше всего, чтобы показать ветки. Длительные из них могут получить сборки CI, если это возможно. Особенно, если на кухне несколько поваров.
Уайетт Барнетт
Я согласен с вашим определением «единицы работы», поэтому я немного борюсь со своей общей моделью (в которой уже есть несколько сборок для каждого проекта по-разному для размещения как сборок «CI», так и сборок «развертывания»). Вы правы, ответ состоит в том, чтобы подключить множество сборок, так что в конце концов моя настоящая проблема - подписать чек! Модель ветвления, на которую ссылаются, выглядит также правильно. Все еще рассматривая общую схему (и допустим, что это будет дополнительно скорректировано, чтобы учесть особенности килограмма)
Murph
2

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

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

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

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

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

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

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

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

Крис Филлипс
источник
1

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

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

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

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

psantosl
источник
Я бы сказал «лучше», а не «хорошо», так как я радостно, с энтузиазмом и успешно выполнил разветвление функций и обслуживания и слияние с Subversion (-:
Murph