TFS 2010 Создайте рабочие элементы в определенном состоянии

Question

Мы использовали TFS 2010 для управления рабочими элементами и спринтами некоторое время и недавно добавили отдельного человека QA. То, что мне нужно сделать, - либо создать определение сборки, которое я могу запустить по расписанию (например, по вторникам в 9 вечера), которые будут строить и/или развертывать рабочие элементы, находящиеся в состоянии «ReadyToDeploy», , Или способ получить список файлов для push на основе TFS API.

Моя конечная цель заключается в том, чтобы автоматизировать процесс выпуска, чтобы еженедельно отправлялись только те элементы, которые прошли QA. Затем клиент или QA могут утверждать, что элементы работают в стадии постановки, которая является зеркалом производства, а другое определение процесса или сборки будет развертывать те элементы, которые будут находиться в другом состоянии.

Я изменил рабочие элементы и рабочие потоки, чтобы выполнить разные состояния, но у меня возникла проблема с сборкой только исправлений или списком всех файлов, которые нужно нажимать на основании состояния рабочего элемента ,

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

Спасибо,

Edit: Как мы должны его установки в настоящее время является то, что каждый разработчик имеет свой собственный филиал и собственный веб-сайт, наше программное обеспечение на основе сервера и должен быть запущен на конкретном сервере. Наша магистраль связана с главным веб-сайтом dev. Именно здесь QA выполняет свое тестирование, чтобы переместить элемент в состояние готовности к развертыванию. Когда разработчик готов к QA, они проверяют свои изменения в своей ветке и сливаются в багажник. На данный момент сборки создаются из ствола. В наши ночи развертывания я открываю веб-сайт транка в VS и делаю публикацию, а затем беру эти файлы по сравнению с списком, предоставленным разработчиками и ftp скомпилированными файлами на наш производственный сервер.

Answer 1

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

Я думаю, что единственный способ достичь этого - создать ветку Release и выполнить ежедневное слияние наборов изменений, находящихся в состоянии «ReadyToDeploy». Когда вы сливаетесь, вы можете выбирать набор изменений, но они должны быть contiguous. Это означает, что вам необходимо выполнить несколько слияний, чтобы получить ветвь Release в соответствующее состояние.

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

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

Шаг за шагом Объяснение

1. Создать ответвление из trunk называется release
2. Если вы хотите сделать Deploy, слияние с trunk в release, но только вишневый выбрать ReadyToDeploy ревизии. Это может занять несколько слияний, поскольку изменения должны быть смежными.
3. Пожар от сборки/развертывания ветви выпуска.
4. Повторите шаги 2 - 3, как позволяет расписание выпуска.

Answer 2

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

1. Настройка процесса, который использует API TFS для поиска элементов в таком состоянии
2. Использование API для траверс Items, чтобы проверить модули прикрепленного
3. Используйте API, чтобы получить последние из исходной и целевой ветви
4. Использовать API для слияния с помощью набора изменений (указано в № 2) (это нетривиально, приходится обрабатывать множество случаев, но слияние должно быть одним способом без конфликтов, так что можно сделать)
5. Использовать API для регистрации
6. Kick off Compile Build
7. Если Compile построить успешный удар от Опубликовать Строить

Answer 3

Насколько мне известно, есть главная проблема с этим подходом. Скажем, у вас есть два набора изменений: # 1 и 2. Оба они содержат модификацию для того же файла. Теперь changeet # 2 содержит свои собственные изменения плюс изменения с # 1. Если вы решите вставить набор изменений 2 и пропустите # 1, догадайтесь, что произойдет. Вы собираетесь вносить изменения из # 1. Это, очевидно, проблема.