TFS2010 Erstellen Sie Definition für die Bereitstellung für mehrere Server?

Question

Ich habe mich mit MSDeploy mit MSDeploy mit MSDeploy und Bereitstellungsfunktionen befasst. Bisher läuft alles gut (obwohl es schwierig war, Informationen über bestimmte Szenarien zu finden).

Kann ich meine Build -Definition ändern, um 2 oder mehr Server anzugeben, um es bereitzustellen? Was ich tun muss, ist auf mehrere Server bereitzustellen (da ich zwei in meiner Testumgebung habe, die ein NLB verwendet).

Was ich jetzt habe, ist eine Build -Definition, die meine Tests erstellt, meine Tests ausführt und dann an einem meiner Testserver eingesetzt wird (in dem der MSDeployagentService darauf läuft). Es funktioniert gut und jedes Webprojekt wird wie in seiner Projektdatei konfiguriert. Die MSBuild -Argumente, die ich verwende, sind:

* /p:DeployOnBuild=True
* /p:DeployTarget=MsDeployPublish
* /p:MSDeployServiceURL=http://oawww.testserver1.com.au/MsDeployAgentService
* /p:CreatePackageOnPublish=True
* /p:MsDeployPublishMethod=RemoteAgent
* /p:AllowUntrustedCertificated=True
* /p:UserName=myusername
* /p:Password=mypassword 

NB: Ich verwende nicht /p: diplyiisapppath = "xyz", da es nicht alle meine Projekte bereitstellt und meine Projektkonfiguration überschreibt.

Kann ich ein weiteres Build -Argument hinzufügen, damit es mehr als einen MSDeployServiceurl anrufen kann? Wie so etwas wie ein Second /P: MSDeployServiceUrl Argument, das einen anderen Server angibt?

Oder muss ich nach einer anderen Lösung suchen, z. B. das Bearbeiten des WF?

Ich habe hier vor 2 Monaten eine fast genau gleiche Frage gesehen: TFS 2010 - Nach dem Build auf mehrere Server bereitstellen Es sieht also nicht so aus, als wäre ich der einzige, der versucht, dies zu lösen.

Ich habe auch in den IIS.NET -Foren gepostet, in denen MSDeploy besprochen wird: http://forums.iis.net/t/1170741.aspx . Es hatte ziemlich viele Ansichten, aber wieder keine Antworten.

Answer 1

Sie müssen das Projekt nicht zweimal erstellen, um auf zwei Servern bereitzustellen. Der Build -Prozess erstellt eine Reihe von Bereitstellungsdateien. Sie können dann den InvokeProcess verwenden, um auf mehreren Servern bereitzustellen.

Erstellen Sie zuerst eine Variable mit dem Namen ProjectName. Fügen Sie dann der Sequenz "Das Projekt kompilieren" eine Aktivität zuweisen. Dies befindet sich in der Sequenz "Versuchen Sie, das Projekt zusammenzustellen". Hier sind die Eigenschaften der Zuweisung:

To: ProjectName
Value: System.IO.Path.GetFileNameWithoutExtension(localProject)

Hier sind die Eigenschaften unserer InvokeProcess -Aktivität, die für den Testserver bereitgestellt werden:

Arguments: "/y /M:<server> /u:<domain>\<user> /p:<password>"
FileName: String.Format("{0}\{1}.deploy.cmd", BuildDetail.DropLocation, ProjectName)

You will need to change <server>, <domain>, <user>, and <password> to the values that reflect your environment.

Wenn Sie manuell auf einem Server bereitstellen müssen, können Sie den folgenden Befehl aus Ihrem Build -Ordner ausführen:

deploy.cmd /y /M:<server> /u:<domain>\<user> /p:<password>

Answer 2

Ich konnte die Lösung, nach der ich gesucht habe, nicht finden, aber hier ist, was ich am Ende ausgedacht habe.

Ich wollte die Lösung einfach und konfigurierbar in den TFS MSBuildArguments Methode, die viel gefördert wurde. Also habe ich eine neue Build -Vorlage erstellt und ein neues TFS -Workflow -Argument auf dem Namen hinzugefügt MSBuildArguments2 In der Registerkarte "Argumente" des Workflows.

Ich habe den Buildtemplate -Workflow nach allen Vorschlägen der durchsucht MSBuildArguments (Es gab zwei Auftreten).

Die beiden Aufgaben, die verwendet werden MSBuildArguments werden genannt Run MSBuild for Project. Direkt unter dieser Aufgabe habe ich einen neuen "If" -Block mit der Bedingung hinzugefügt:

Not String.IsNullOrEmpty(MSBuildArguments2)

Ich habe dann die Aufgabe "MSBuild for Project" kopiert und sie in den neuen IF "dann" -Block eingefügt, wodurch der Titel entsprechend aktualisiert wurde. Sie müssen auch die ConmandLineArgument -Eigenschaft der neuen Aufgaben aktualisieren, um Ihr neues Argument zu verwenden.

CommandLineArguments = String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments2)

Nach diesen Modifikationen sieht der Workflow so aus:

Speichern und überprüfen Sie den neuen Workflow. Aktualisieren Sie Ihre Build -Definition, um diesen neuen Workflow zu verwenden. Auf der Registerkarte "Build Definition" finden Sie einen neuen Abschnitt namens MISC mit dem neuen Argument, das zur Verwendung bereit ist. Da ich dieses neue Argument für die Bereitstellung einfach verwende, habe ich genau die gleichen Argumente kopiert, für die ich verwendet habe, MSBuild Arguments und hat den MSDeployServiceurl auf meinem zweiten Bereitstellungsserver aktualisiert.

Und das ist das. Ich nehme an, eine elegantere Methode wäre die Umwandlung von MSBuildArgumenten in eine Reihe von Zeichenfolgen und schaufelt sie während des Workflow -Prozesses durch. Dies passt jedoch zu unseren 2 Serveranforderungen.

Hoffe das hilft!

Answer 3

Meine Lösung dafür ist ein neues Ziel, das nach dem Paket ausgeführt wird. Jedes Projekt, das ein Paket erstellen muss, enthält diese Zieldatei, und ich habe mich entschieden, die Bedingung auf eine externe Set-Set "Dodeployment" -Sache zu machen. Zusätzlich definiert jedes Projekt die Eigenschaft für die DeploymentServerGroup so, dass die Zielservers (en) je nach Projekt ordnungsgemäß filtriert werden.

Wie Sie von unten sehen können, führe ich die Befehlsdatei einfach mit der Serverliste aus, ziemlich einfach.

<!-- 
This targets file allows a project to deploy its package  

As it is used by all project typesconditionally included from the project file 

-->

<UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.BuildStep" AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.ProcessComponents.dll" />

<!-- Each Server needs the Group metadatum, either Webservers, Appservers, or Batch. -->
<Choose>
    <When Condition="'$(Configuration)' == 'DEV'">
        <ItemGroup>
            <Servers Include="DevWebServer">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="DevAppServer">
                <Group>Appservers</Group>
            </Servers>
        </ItemGroup>
    </When>
    <When Condition="'$(Configuration)' == 'QA'">
        <ItemGroup>
            <Servers Include="QAWebServer1">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="QAWebServer2">
                <Group>Webservers</Group>
            </Servers>
            <Servers Include="QAAppServer1">
                <Group>Appservers</Group>
            </Servers>
            <Servers Include="QAAppServer2">
                <Group>Appservers</Group>
            </Servers>
        </ItemGroup>
    </When>
</Choose>

<!-- DoDeploy can be set in the build defintion -->
<Target Name="StartDeployment" AfterTargets="Package">

    <PropertyGroup>
        <!-- The _PublishedWebsites area -->
        <PackageLocation>$(WebProjectOutputDir)_Package</PackageLocation>

        <!-- Override for local testing -->
        <PackageLocation Condition="$(WebProjectOutputDirInsideProject)">$(IntermediateOutputPath)Package\</PackageLocation>

    </PropertyGroup>

    <Message Text="Tier servers are @(Servers)" />

    <!-- A filtered list of the servers.  DeploymentServerGroup is defined in each project that does deployment -->
    <ItemGroup>
        <DestinationServers Include="@(Servers)" Condition="'%(Servers.Group)' == '$(DeploymentServerGroup)'" />
    </ItemGroup>

    <Message Text="Dest servers are @(DestinationServers)" />

</Target>

<!-- Only perform the deployment if any servers fit the filters -->
<Target Name="PerformDeployment" AfterTargets="StartDeployment" Condition="'@(DestinationServers)' != ''">

    <Message Text="Deploying $(AssemblyName) to @(DestinationServers)" />

    <!-- Fancy build steps so that they better appear in the build explorer -->
    <BuildStep
                    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                    BuildUri="$(BuildUri)"
                    Message="Deploying $(AssemblyName) to @(DestinationServers)...">
        <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <!-- The deployment command will be run for each item in the DestinationServers collection.  -->
    <Exec Command="$(AssemblyName).deploy.cmd /Y /M:%(DestinationServers.Identity)" WorkingDirectory="$(PackageLocation)" />

    <BuildStep
                    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                    BuildUri="$(BuildUri)"
                    Id="$(StepId)"
                    Status="Succeeded"
                    Message="Deployed $(AssemblyName) to @(DestinationServers)"/>
    <OnError ExecuteTargets="MarkDeployStepAsFailed" />
</Target>

<Target Name="MarkDeployStepAsFailed">
    <BuildStep
            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
            BuildUri="$(BuildUri)"
            Id="$(StepId)"
            Status="Failed" />
</Target>

Answer 4

Ich bin der Autor des anderen ähnlichen Beitrags. Ich habe noch keine Lösung gefunden. Ich glaube, es wird den Workflow ändern, um eine Postverarbeitungs -MSBuild -SYNC -Aufgabe hinzuzufügen. Das scheint das eleganteste zu sein, hoffte aber immer noch, etwas weniger aufdringlich zu finden.

Answer 5

Ich bin mir nicht sicher, ob das Ihnen bei TFS 2010 helfen könnte, aber ich habe einen Blog -Beitrag für TFS 2012: Mehrere Webprojekte Bereitstellung von TFS 2012 bis zur NLB -fähigen Umgebung.