Вопросы по стратегии автоматической сборки TFS - PullRequest
Новая
       52

Вопросы по стратегии автоматической сборки TFS

9 голосов
/ 01 сентября 2011

Я новичок в Team Foundation Server, и в настоящее время я работаю над настройкой стратегии автоматической сборки для моего проекта. У меня возникает путаница в том, как настроить автоматические сборки, соответствующие нашей структуре управления исходным кодом / разработки.

В соответствии с политикой компании в проект TFS мы включаем папки «ствол» и «ветки». «Магистраль» представляет и содержит наш производственный код. «Ветви» явно держат ветви в стадии разработки.

Я бы хотел настроить сборки CI (непрерывная интеграция) для филиалов и сборку «Gated check-in» для «trunk». Я думаю, что это фактически устранит любые проблемы со сборками «ствола», когда придет время перейти к производству. Однако у меня есть несколько вопросов обо всем этом:

1. Имеет ли смысл моя стратегия? (слишком ли она избыточна? Создает ли она непредвиденные проблемы? И т. Д.)

2. Является ли 'слияние' 'регистрацией', которая будет запускать CI или сборку Gated? Если разработчики объединят свои ветви разработки в 'trunk', я бы хотел, чтобы это инициировало сборку trunk. (Возможно, сборка «Gated» здесь является ненужной избыточностью?)

Любое руководство, которое вы можете дать мне, очень ценится. Заранее спасибо!

(Среда разработки: TFS 2010, VS 2010 Ultimate, Windows Server 2008 R2)

Ответы [ 3 ]

9 голосов
/ 01 сентября 2011

  1. Я так думаю.Мы делаем то же самое с большим успехом.Сборки gated могут быть довольно шаткими для каждодневной разработки, поскольку после сборок происходит постоянное объединение, но с точки зрения объединения между ветвями у вас не будет слишком многих проблем.Имейте в виду, что когда вы регистрируете не выгружаемый двоичный файл во время регистрации, вы не можете сохранить свои изменения локально, когда включена сборка со стробированием.

  2. Да.Слияние происходит локально, а затем вы проверяете объединенные файлы.Это вызовет любую сборку, которую вы настроили для этой ветви.

Я обнаружил, что эти стратегии довольно хорошо объединяют кодовую базу.Я столкнулся с проблемами, когда gated-сборки просто не практичны, потому что становится очень трудно исправить некоторые проблемы.Мне пришлось прибегнуть к отключению шлюза, чтобы «объединить» определенные изменения, а затем снова включить его.

3 голосов
/ 01 сентября 2011

Любая регистрация контроля источника (включая слияние) будет инициировать событие изменения контроля источника и иметь связанный с ним набор изменений.

Наша нормальная настройка 

Project 
Project\trunk
Project\branches
Project\releases
1 голос
/ 01 сентября 2011

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

Эта ссылка содержит кучу информации, которая помогла мне создать стратегию слияния.

...