Как заставить MSDeploy работать на нашем сервере сборки / интеграции - необходимо ли обновление MSBuild? - PullRequest
13 голосов
/ 09 апреля 2010

У нас есть довольно стандартный процесс сборки: 1. Разработчик: проверьте в коде 2. Build: опрашивает репо, видит изменения и запускает сборку, которая: 3. Сборка: обновления из репозитория, Сборки с MSBuild, Запуск юнит-тестов с nunit, 4. Build: создает установочный пакет

Наша команда безопасности позволяет нам извлекать данные из сервера сборки, но не позволяет серверу сборки выдвигаться. Таким образом, мы, как правило, запускаем rdp, устанавливаем и устанавливаем их, что исключает использование сервисов развертывания, поэтому вместо этого мне нужно было бы создавать пакеты. Я хотел бы использовать MSDeploy, за исключением того, что у нас есть следующие проблемы:

  1. Мы находимся на .net 3.5, а для цели MSBuild (Package), которая использует MSDeploy, требуется 4.0. Есть ли что-нибудь, что мне нужно для установки, кроме .net 4.0 RC для этого? (Будет ли MSBuild частью этого обновления?)
  2. Когда я генерирую пакеты с помощью MSDeploy, я вижу, что у меня нет только 1 файла. Это zip, deploy.cmd, SourceManifest.xml и SetParameters.xml. Для чего нужны все остальные файлы и почему они не будут в «пакете»?
  3. Звучит так, как будто вы можете создавать пакеты, указав системе посмотреть на работающий сайт IIS. Но если пакеты собираются из среды CI, разве вам здесь не повезло? Такое ощущение, что они разработали некоторые из них для небольших разработчиков, развертывающих свою среду разработки. Это хороший вариант использования, но мне интересно посмотреть, что такое корпоративный опыт каждого с инструментом

Есть предложения?

1 Ответ

26 голосов
/ 10 апреля 2010

Если вы не используете Visual Studio 2010 для своего приложения, я бы посоветовал вам выбрать один из следующих вариантов:

  1. Использовать msdeploy.exe
  2. Установите Visual Studio 2010 на свой сервер сборки и сами задачи MSDeploy

Позвольте мне объяснить это немного подробнее.

Вариант 1

MSDeploy сам по себе не зависит от MSBuild, поэтому вы можете установить его самостоятельно на своем сервере сборки, чтобы создавать пакеты для вас. Вы можете скачать его с здесь . После этого вы можете создать сценарий развертывания MSBuild, используя задачу Exec , чтобы вызвать msdeploy.exe с командой для создания вашего пакета.

О втором варианте

Файлы .targets, а также задачи для MSDeploy развертываются не с .NET Framework, а с самой Visual Studio 2010. Поэтому, если вы хотите использовать какой-либо из них, вам придется установить VS 2010 на свой сервер сборки.

Вы упомянули об использовании пакета target в своем сообщении. Вы не сможете использовать это, потому что эта цель является частью более крупного процесса сборки для проектов .NET 4. Что вы можете сделать, это создать отдельный файл MSBuild ( отдельный, как в файле вашего проекта ), который использует MSBuild 4 для вызова tasks , которые поставляются с VS 2010 для веб-развертывания.

Здесь я специально отвечу на ваш нумерованный список

  1. Вам придется установить Visual Studio 2010, поскольку эти задачи поставляются с самой VS, а не с фреймворком.
  2. Эти файлы используются для взаимодействия с вашим пакетом. Ваша посылка представляет вашу заявку в целом. Deploy.cmd вызовет msdeploy.exe, чтобы выполнить развертывание для вас. SourceManifest.xml и SetParameters.xml используются для настройки развертывания вашего приложения. deploy.cmd будет использовать эти файлы при вызове msdeploy.exe. Другими словами, если вы хотите настроить путь, по которому будет установлено веб-приложение, вы должны указать его в SetParameters.xml вместе с другими параметрами.
  3. По вашему праву настройки могут исходить от IIS, но многие разработчики предпочитают использовать сервер приложений VS вместо IIS. Это мое предпочтение. В этом случае я бы предложил развернуть ваше приложение в среде, которую вы будете использовать в качестве шаблона. Выполните все необходимые настройки IIS, создайте пакет MSDeploy, а затем извлеките файл archive.xml из пакета и используйте его при создании собственного пакета. Другой вариант - настроить сервер IIS, на котором может быть развернут ваш процесс сборки, затем использовать MSDeploy, чтобы просто синхронизировать файлы, составляющие ваше приложение, и затем еще раз сгенерировать пакет с этого сервера IIS.
...