Автоматизированное управление сборкой и выпуском VS2012

Question

Пытаясь сделать мою жизнь проще, в настоящее время в Visual Studio 2012 работают 4 разработчика, и мы используем TFS 2012 для управления исходным кодом. Проект, над которым мы работаем, представляет собой мультитенантное веб-приложение (один исходный каталог с несколькими базами данных), представляющее собой смесь устаревших компонентов asp и vb6 com в сочетании с новым кодом C#. Мы используем TFS для контроля исходного кода и для управления пользовательскими историями и ошибками. Из-за того, как работает наш сайт, он не может быть запущен или отлажен локально только на сервере. Source Control в настоящее время настроен с отдельной ветвью для каждого разработчика, рабочий каталог которого сопоставлен с общим сетевым путем на сервере dev, на котором указан веб-сайт в IIS. Dev01-Dev05 и т. Д. Разработчики работают над проектами в своей ветви, тестируют их на своем веб-сайте dev, затем регистрируют изменения в своей собственной ветви и объединяют их в магистраль. Рабочее пространство соединительной линии привязано к основному веб-сайту разработчика, так что разработчики могут проверить свои изменения по отношению к доменам разработчиков другого клиента, чтобы протестировать настройки и отклонения в функциональности на основе конкретных баз данных, к которым они подключены.

Очень длинное объяснение, но в основном каждый разработчик имеет ветку и сайт, которые затем объединяются в ствол со своим собственным сайтом.

Чтобы развернуть наш промежуточный сервер:

1. Я компилирую сайт транка через файл bat на сервере
2. Запустите приложение Windows, которое я создал, чтобы запросить TFS для наборов изменений, связанных с определенными WorkItems в определенном состоянии, и скопировать все файлы для этих наборов изменений из папки публикации в папку развертывания.
3. Запустите другой файл bat на сервере, чтобы использовать RedGate Deployment Manager для создания пакета из этих новых файлов.
4. Перейдите на сайт DM в нашей сети, чтобы создать и развернуть этот выпуск (я не смог заставить инструменты командной строки работать для этого, поэтому я должен сделать это вручную)
5. Запустите все сценарии SQL, которые были сохранены в папках, которые соответствуют номерам заявок в каждой базе данных (около 10 клиентских баз данных) для поддержки выпуска.

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

Мой идеальный сценарий будет:

1. Gated Checkin, Попытка сборки / публикации каждый раз, когда разработчик сливается со стволом, отклоняет и уведомляет разработчика в случае сбоя сборки.
2. Конец рабочего дня собирает элементы TFS определенного статуса и развертывает связанные с ними файлы на промежуточном сайте.
3. Развертывание сценариев SQL для этих элементов TFS на всех клиентских БД в стадии подготовки
4. В конце концов * запускать автоматизированные регрессионные тесты пользовательского интерфейса, создавать новые WorkItems или электронные письма для разработчиков в случае неудачи
5. Обновите TFS WorkItems до нового состояния, чтобы QA/ клиенты знали, что их изделия готовы к тестированию в нашей промежуточной среде.
6. Отправить отчет о том, какие элементы были успешно развернуты

Как я могу попасть сюда, чтобы не тратить часы на подготовку и развертывание релизов для постановки и, в конечном итоге, производства? Довольно открытые для потенциальных решений, вещи, которые было бы трудно изменить, были бы используемым нами управлением исходным кодом, не могли бы на самом деле переключиться на Subversion или что-то еще, поэтому мы довольно сильно застряли в TFS.

Спасибо

Answer 1

Вернулся и начал пытаться заставить TFS создать / опубликовать мое веб-решение. Я смог получить сборку для успешного завершения. добавив аргумент msbuild /p:DeployOnBuild=True и установив платформу msbuild на x86, похоже, удалось добиться этого. Затем я нашел https://github.com/red-gate/deployment-manager-tfs который дает вам шаблон процесса сборки для выполнения пакета и развертывания с использованием инструментов redgate. Немного поиграв с этим, я наконец получил возможность создавать, упаковывать и развертывать мою сборку в нашей промежуточной среде.

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

Answer 2

Действительно подробное описание вашего процесса. Спасибо, что поделился!

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

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

Используете ли вы Deployment Manager для развертывания базы данных из системы контроля версий, а также из приложения?

Это может быть способом дальнейшей автоматизации процесса. SQL Source Control и SQL CI позволяют вам контролировать источники структуры базы данных, поддерживать базу данных в актуальном состоянии при каждой регистрации и выполнять модульные тесты базы данных. Они также создают пакеты базы данных для Deployment Manager, поэтому вы можете развернуть выпуск, содержащий как приложение, так и базу данных.

Если вы хотите отправить мне команду, которую вы используете на шаге 4 для развертывания релиза с помощью Deployment Manager, я могу помочь с этим. Команды, которые я использую:

DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name

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

--packageversion=<package name>=<version>
--packageversion="application=1.5