Определение процесса построения
После создания системы построения (как описано в разделе Настройка системы построения) почти все готово для начала использования Team Foundation Build для компиляции кода, проведения тестов и выполнения других важных задач. Следующий шаг — разработка процесса построения, содержащего инструкции относительно того, какие проекты кода следует компилировать, каким действием инициируется построение, какие тесты выполняются, а также множество других параметров.
Общие задачи
Общие задачи |
Справочные материалы |
|---|---|
Создание определения построений и работа с ним. Создание простого, но мощного процесса построения, содержащего инструкции относительно того, какие проекты кода следует компилировать, каким действием инициируется построение, какие тесты выполняются, а также множество других параметров, не займет много времени. |
Создание базового определения построения Определение построения с помощью шаблона по умолчанию |
Если требуется, можно поместить построение в очередь вручную, но потребностям вашей команды, как правило, будет соответствовать процесс построения, определенный с помощью автоматических триггеров. |
|
В определении процесса построения можно настроить загрузку полезных данных (например, имени определения построения и даты выполнения) в имя каждого завершенного построения. |
|
Агент построения следует вашей спецификации, создавая рабочую область в системе управления версиями для облегчения загрузки файлов (например, файлов исходного кода), с которыми он работает. Для эффективного выполнения процесса построения следует определить рабочую область. |
|
Рабочий процесс можно использовать для публикации символьных данных в PDB-файлах в хранилище символов SymStore. Если эти данные публикуются, команда может использовать для отладки IntelliTrace. |
|
Хотя обычно полезно иметь подробные сведения о завершенных построениях, процесс построения, записывающий в журнал избыточную информацию, способен перегрузить данными членов команды и серверы. Этих проблем можно избежать, контролируя избыточность информации. |
|
Можно определить процесс построения, который будет запускать тесты и анализировать влияние изменений в коде на тесты. Например, можно определить процесс построения, который будет запускать регулярный тест проверки построения. |
|
Создание пользовательских построений. С помощью шаблона по умолчанию можно создать процесс построения, отвечающий широкому набору наиболее распространенных требований. Однако многим командам требуются собственные процессы построения для выполнения специализированных задач или собственной логики. |
|
Обновление построений прежних версий MSBuild. Можно использовать существующие файлы MSBuild с помощью шаблона обновления. |
Использование построений, созданных в прежних версиях MSBuild, с помощью шаблона обновления |
Меры во избежание повреждения построения Ситуация, когда разработчик возвращает изменения, делающие построение недопустимым, может привести к существенным проблемам даже в небольших командах. В более крупных командах последствия могут быть еще серьезнее, приводя к потерям производительности и задержкам в расписании. Существует возможность создать определение построения с условным возвратом, чтобы целиком или частично защитить базу кода от этой проблемы. Можно также использовать политику возврата построений в качестве инструмента ограничения дополнительных изменений в базе кода до устранения повторяющейся проблемы, приводящей к прерыванию построения. |
Определение построения с условным возвратом для проверки изменений |
См. также
Основные понятия
Построение и развертывание баз данных в изолированной среде разработки
Построение и развертывание баз данных в тестовой или производственной среде
Другие ресурсы
Запуск построений и наблюдение за ними
Управление завершенными построениями и их просмотр