TFS2010 Build-Definition für die Bereitstellung auf mehreren Servern?

Habe ich in TFS2010 neue build-und deployment-Funktionen mit MSDeploy. So weit alles gut geht (obwohl Ihr seit schwer zu finden, Informationen zu bestimmten Szenarien).

Kann ich ändern, meine Build-Definition angeben, 2 oder mehr Server bereitstellen? Was ich tun müssen, ist die Bereitstellung auf mehreren Servern (wie ich zwei in meiner Testumgebung, die über eine NLB).

Was ich jetzt haben, ist eine Build-definition Aufbaut, läuft meine tests, und dann Setzt zu EINEM meiner Test-Servern (die das MsDeployAgentService ausgeführt). Es funktioniert gut, und jedes web-Projekt bereitgestellt wird entsprechend der Konfiguration in Ihr Projekt-Datei. Der MSBuild-Argumente, die ich benutze 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: I dont use /p:DeployIISAppPath="xyz" als es nicht bereitstellen, alle meine Projekte und überschreibt mein Projekt config.

Kann ich hinzufügen, eine andere build-argument, um es zu nennen, mehr als ein MSDeployServiceURL? Wie so etwas wie eine zweite /p:MSDeployServiceURL argument, dass gibt einen anderen server?

Tun oder muss ich mich für eine andere Lösung, wie die Bearbeitung der WF?

Sah ich eine fast exakt gleiche Frage hier gepostet vor 2 Monaten: TFS 2010 - Bereitstellung auf Mehreren Servern Nach Bauen , so sieht es nicht aus, ich bin der einzige Versuch, diese zu lösen.

Ich auch geschrieben auf der IIS.NET Foren, in denen MSDeploy diskutiert wird: http://forums.iis.net/t/1170741.aspx . Es hatte eine ganze Menge von Ansichten, aber wieder keine Antworten.

InformationsquelleAutor Arkiliknam | 2010-08-19
  1. 7

    Sie nicht haben, um das Projekt zu erstellen, zweimal, um die Bereitstellung auf zwei Servern. Der build-Prozess erstellt eine Reihe von deployment-Dateien. Sie können dann die InvokeProcess für die Bereitstellung auf mehreren Servern.

    Erstellen zuerst eine variable mit dem Namen Projektname. Dann fügen Sie eine Assign-Aktivität, um das "Projekt Kompilieren" - Sequenz. Diese befindet sich in der "Versuchen, Kompilieren Sie das Projekt" Sequenz. Hier sind die Eigenschaften des Weisen:

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

    Hier sind die Eigenschaften unserer InvokeProcess activity, setzt auf die test-server:

    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 die Bereitstellung auf einem server und führen Sie den Befehl unten aus dem build-Ordner:

    deploy.cmd /y /M:<server> /u:<domain>\<user> /p:<password>
    • Das sieht aus wie die richtige Sache zu tun, wenn ich eine chance hatte, zu wiederholen meine Umsetzung. Es ist nur schade, dass es nicht out of the box mit so etwas wie dieses. Danke!
    • Ich habe aktualisiert, unsere Prozess, so dass diese nun parametriert werden. Für die MSBuild-Argumente Sie können auch geben Sie dem IIS-App-Pfad. Diese können auch parametrisiert werden, wenn Sie brauchen, um stellen Sie mehrere Instanzen auf dem gleichen server.
    InformationsquelleAutor 37Stars
  2. 6

    Konnte ich nicht finden die Lösung, die ich suchte, aber hier ist was ich kam mit am Ende.

    Wollte ich die Lösung einfach und konfigurierbar innerhalb des TFS Argumente, während zur gleichen Zeit bleiben im Einklang mit den bereits zur Verfügung gestellt MSBuildArguments Methode, die gefördert worden ist, eine Menge. Also ich habe eine neue Build-Vorlage, und fügte hinzu, eine neue TFS-WorkFlow-Argument genannt MSBuildArguments2 im Arguments-tab des WorkFlow.

    TFS2010 Build-Definition für die Bereitstellung auf mehreren Servern?

    Ich durchsuchte den BuildTemplate WorkFlow für alle stellen der MSBuildArguments (es waren zwei Ereignissen).

    Den beiden Aufgaben, dass die Verwendung MSBuildArguments genannt Run MSBuild for Project. Direkt unter dieser Aufgabe, ich habe eine neue "If" - block mit der Bedingung:

    Not String.IsNullOrEmpty(MSBuildArguments2)

    Ich dann kopiert den "Lauf für MSBuild-Projekt" Aufgabe, und klebte es in die neue, Wenn die "Dann" - block, der Aktualisierung seiner Titel entsprechend. Sie müssen auch ein update der neuen Aufgabe ConmmandLineArguments Eigenschaft, um Ihr neues Argument.

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

    Nach diesen änderungen, wird der WorkFlow sieht wie folgt aus:

    TFS2010 Build-Definition für die Bereitstellung auf mehreren Servern?

    Speichern und Überprüfen Sie den neuen WorkFlow. Aktualisieren Sie Ihre Build-Definition zur Verwendung dieser neuen WorkFlow -, dann in der build-definition Registerkarte "Prozess" finden Sie eine neue Sektion namens " Misc mit dem neuen argument verwendet werden kann. Da bin ich einfach mit diesem neuen argument für die Bereitstellung kopiert habe ich die exakt gleichen Argumente, die ich für MSBuild Arguments und aktualisiert die MSDeployServiceURL zu meiner zweiten deployment server.

    TFS2010 Build-Definition für die Bereitstellung auf mehreren Servern?

    Dass. Ich nehme an, eine elegantere Methode wäre, um zu konvertieren MSBuildArguments in ein String-array und Durchlaufen während der WorkFlow-Prozess. Aber das passt unseren 2 server-Anforderungen.

    Hoffe, das hilft!

    InformationsquelleAutor Arkiliknam
  3. 2

    Meine Lösung dafür ist, ein neues Ziel, das läuft nach Paket. Jedes Projekt benötigt ein Paket enthält dieser targets-Datei, und habe ich mich entschieden, die bedingte auf einem extern-set "DoDeployment" - Eigenschaft. Zusätzlich wird jedes Projekt definiert die DeploymentServerGroup Eigenschaft so ein, dass die Ziel-server(s) korrekt gefiltert, je nachdem, welche Art von Projekt es ist.

    Wie Sie sehen können, nach unten bin ich einfach der Ausführung des Befehls Datei mit der server-Liste, 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>

    • Interessant... also du nimmst die Arbeit der TFS-Workflow und setzen es wieder in einem MSBUILD-Skript. Jedes Projekt in der Projektmappe Aufruf dieses Ziel nach bauen? Und hier dachte ich MSBUILD-tot und begraben war 🙂
    • Sobald ich besser auf zu schreiben MSBuild-Dateien, die ich begann, Sie bevorzugen, um mit dem klobig und crash-anfällig WorkFlow-designer. Jedes Projekt, die Anforderungen zu implementieren sein Paket umfasst dieser targets-Datei von Ihrer csproj und Ziel der Anrufung ist die automatische als es fertig ist, nachdem das Paket-Ziel.
    InformationsquelleAutor David Peters
  4. 0

    Ich bin der Autor von den anderen ähnlichen post. Ich habe noch eine Lösung zu finden. Ich glaube, es geht um das ändern der workflow hinzufügen, um eine Nachbearbeitung der MSBUILD -Aufgabe sync. Das scheint die eleganteste, aber war immer noch in der Hoffnung, etwas zu finden, ein bisschen weniger aufdringlich.

    • Ich ging zu gehen auf diesem Weg. Es gibt einen blog-Eintrag hier: blogs.blackmarble.co.uk/blogs/rfennell/Archiv/2010/08/13/... abdeckt, wie das zu tun. Aber am Ende habe ich Hinzugefügt, einem zweiten Aufruf von MSBUILD und wiederverwendet, die Argumente, die Idee, die Sie für uns (so ausführlich in meiner Antwort).
    InformationsquelleAutor Aaron Corcoran
  5. 0

    Ich bin mir nicht sicher, ob das dir helfen könnte mit TFS 2010, aber ich habe einen blog post für TFS 2012: Mehrere web-Projekte, Bereitstellung von TFS 2012 zum NLB-fähigen Umgebung.

    InformationsquelleAutor Dmitry Bogatykh
Schreibe einen Kommentar