Непрерывное развертывание нескольких проектов из одного решения c#

#c# #wcf #asp.net-mvc-4 #tfs #continuous-deployment

#c# #wcf #asp.net-mvc-4 #tfs #непрерывное развертывание

Вопрос:

У меня есть одно решение с несколькими проектами внутри:

Проект 1 — Библиотека классов Проект 2 — MVC проект 3 — Библиотека классов Проект 4 — WCF

Теперь я хочу, чтобы TFS создавала все проекты, а также автоматически развертывала проект MVC http://somehost/MVC и WCF http://somehost/WCF .

Я пытался изменить свое определение сборки, но развертывается только MVC.

Кстати: в TFS включена закрытая регистрация.

Ответ №1:

У меня была именно эта проблема, и я решил ее, вручную отредактировав файлы проекта.

Таким образом, TFS развернет оба проекта при сборке. Обратите внимание на имена конфигураций сборки — я создал их специально для того, чтобы указывать на мои определения сборки TFS (у меня есть 2 определения сборки: Dev amp; QA). Применение группы свойств к этим определениям означает, что проекты не развертываются каждый раз, когда вы создаете проекты в своей среде разработки при запуске конфигурации отладки. Это также означает, что я могу развертывать в разных местах в зависимости от того, выполняю ли я сборку QA или Dev.

Пример:

 <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'DEV-BUILD-|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <DeployOnBuild>true</DeployOnBuild>
    <DeployTarget>MsDeployPublish</DeployTarget>
    <MSDeployPublishMethod>RemoteAgent</MSDeployPublishMethod>
    <MSDeployServiceUrl>http://DEV-SERVER-ADDRESS</MSDeployServiceUrl>
    <DeployIisAppPath>PROJECTminder.API-MAINTENANCE</DeployIisAppPath>
    <UserName><MACHINE-NAME>BuildUser</UserName>
    <Password>*****</Password>
    <AuthType>Basic</AuthType>
    <AllowUntrustedCertificate>true</AllowUntrustedCertificate>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'QA-BUILD|AnyCPU'">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <DeployOnBuild>true</DeployOnBuild>
    <DeployTarget>MsDeployPublish</DeployTarget>
    <MSDeployPublishMethod>RemoteAgent</MSDeployPublishMethod>
    <MSDeployServiceUrl>http://QA-SERVER-ADDRESS</MSDeployServiceUrl>
    <DeployIisAppPath>PROJECTminder.API</DeployIisAppPath>
    <UserName><MACHINE-NAME>BuildUser</UserName>
    <Password>*****</Password>
    <AuthType>Basic</AuthType>
    <AllowUntrustedCertificate>true</AllowUntrustedCertificate>
  </PropertyGroup>

Обновить:

Я должен добавить, что это было мое решение для VS2010. Я считаю, что в более новых версиях (2012 ) вы действительно можете определить профили публикации для каждого проекта (.pubxml), которые будет получать TFS.

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

Ответ №2:

Для этого я использую Octopus Deploy. Используя шаблон процесса сборки по умолчанию, вы можете запустить сценарий Powershell после сборки. В этом скрипте вы можете создавать пакеты NuGet, создавать релиз и развертывать их на нескольких серверах. В документации Octopus Deploy есть способ создания пакетов для развертывания Создания пакетов с помощью TFS. Здесь есть сообщение в блоге об интеграции TFS и Octopus Deploy .