TFS Build и Local Build

Question

Мне поручено обновить устаревший процесс сборки компаний. Все это делается в пакетных и perl-скриптах. Текущий процесс сборки:

1. Расписание строительства через веб-интерфейс.
2. Сервер сборки берет процесс сборки из очереди.
3. Сервер сборки проверяет все файлы с помощью источника источника TFS.
4. Сервер сборки запускает несколько сценариев ввода кода, которые изменяют источник перед сборкой.
5. Build сервер обновляет версии и подписывает код.
6. Сервер сборки использует визуальную студию для компиляции проектов.
7. После того, как это завершено, сервер сборки защелкнул выход и опустил его в место общего доступа к сети.

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

Моя конечная цель - запустить процесс сборки на локальных машинах-разработчиках, а также запустить CI на сервере TFS.

В моих поисках кажется, что нет способа эмулировать сборку TFS на локальной машине. Могу ли я использовать сценарии командной строки pre-/post-build в моих файлах cs.proj? Или есть лучший способ сделать сложные сборки на локальной машине и запустить те же сборки на TFS?

Я видел Using TFS build definitions on a local machine, но это кажется немного взломанным для меня. Думаю, это не было бы ужасным решением, если бы не было лучшего.

Answer 1

Я попытался сделать что-то подобное в прошлом сам. К сожалению, нет хорошего способа сделать это из-за всего, что требует рабочий процесс TFS Build Workflow. То, что я нашел, было то, что в основном есть два способа сделать это.

1. Создайте сценарий MSBuild, который будет работать как на сервере и локальном
2. Создание сценария MSBuild для локального и пользовательского деятельности для сервера.

Если вы намерены или имеете требование, чтобы вы могли воспроизводить сборку точно как на машине разработчика, так и на сервере сборки, тогда я бы выбрал # 1. В противном случае я бы пошел с №2. Второй вариант хорош, потому что тогда вы можете играть в рабочем процессе TFS для выполнения основных сборок, который предоставляет вам множество объектов, которые вам нужны, а также дает вам приятное место для настройки параметров без необходимости проверять/в файлах для изменения как происходит сборка.

Для любого метода вам, скорее всего, придется изменить свои сценарии Perl, чтобы принимать параметры для учета любой настройки, которую вы должны выполнять между системами. Затем вы можете попросить пользователя передать их или по умолчанию в сценарии MSBuild для локальных сборок и настроить их как параметры в TFS Build Workflow. Таким образом, они могут быть легко изменены при необходимости. Независимо от метода, однако, единственный хороший способ сделать это - стандартизировать, как нужно настраивать вещи на машинах разработчика и сервере сборки, чтобы вам не нужно было настраивать их.

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