TFS2010 Corporatura Definizione per la distribuzione su più server?

Question

ho cercato in TFS2010 nuove funzionalità di generazione e distribuzione con MSDeploy. Finora tutto sta andando bene (anche se il suo stato difficile trovare informazioni sugli scenari specifici).

Posso modificare la mia Corporatura Definizione per specificare 2 o più server per distribuire a? Che cosa devo fare è la distribuzione a più server (come ho due nel mio ambiente di test che utilizza un NLB).

Quello che ho adesso è una definizione di compilazione che costruisce, gestisce i miei test, e poi implementa a uno dei miei server di test (che ha il MsDeployAgentService esecuzione su di esso). Funziona bene, e ogni progetto web viene distribuito come configurato nel suo file di progetto. Argomenti MSBuild che uso sono:

* /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: Non uso / p: DeployIISAppPath = "xyz", come si pretende molto implementare tutti i miei progetti e le sostituzioni il mio progetto config

.

È possibile aggiungere un altro argomento di compilazione per farlo chiamare più di una MSDeployServiceURL? Come qualcosa come una seconda / p:? Argomento MSDeployServiceURL che specifica un altro server

O devo cercare un'altra soluzione, come ad esempio la modifica del WF?

ho visto una quasi esatta stessa domanda qui pubblicato 2 mesi fa: TFS 2010 -. Distribuire a più server dopo la generazione , in modo da non sembra come se fossi l'unico a cercare di risolvere questo

ho anche postato sul forum IIS.NET dove è discusso MSDeploy: http: // forum .iis.net / t / 1170741.aspx . E 'avuto un bel po' di punti di vista, ma ancora una volta, nessuna risposta.

Answer 1

Non c'è bisogno di costruire il progetto per due volte per la distribuzione su due server. Il processo di generazione costruirà una serie di file di distribuzione. È quindi possibile utilizzare l'InvokeProcess per la distribuzione su più server.

Per prima cosa creare una variabile denominata ProjectName. Quindi aggiungere un'attività assegnare alla sequenza "Compilare il progetto". Questo si trova nella sequenza "tenta di compilare il progetto". Qui ci sono le proprietà del Assegna:

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

Ecco le caratteristiche della nostra attività InvokeProcess che distribuisce al server di prova:

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.

Se è necessario distribuire manualmente a un server è possibile eseguire il comando di seguito dalla cartella di compilazione:

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

Answer 2

Non ho potuto trovare la soluzione che stavo cercando, ma ecco cosa mi è venuta alla fine.

ho voluto mantenere la soluzione semplice e configurabile nei argomenti TFS, mentre allo stesso tempo rimanendo in linea con il metodo MSBuildArguments già previsto, che è stato promosso un sacco. Così ho creato una nuova build modello, e ha aggiunto un nuovo argomento TFS WorkFlow chiamato MSBuildArguments2 nella scheda Argomenti del flusso di lavoro.

Ho cercato attraverso il BuildTemplate flusso di lavoro per tutte le occorrenze della MSBuildArguments (c'erano due occorrenze).

I due compiti che l'uso MSBuildArguments sono chiamati Run MSBuild for Project. Direttamente sotto questo compito, ho aggiunto un nuovo "caso" blocco con la condizione:

Not String.IsNullOrEmpty(MSBuildArguments2)

Poi ho copiato il "Run MSBuild per il progetto" compito e incollato in blocco "Allora", il nuovo caso, aggiornando il suo titolo di conseguenza. Avrete anche bisogno di aggiornare il nuovo Task proprietà ConmmandLineArguments per utilizzare il nuovo argomento.

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

Dopo queste modifiche, gli sguardi WorkFlow come questo:

Salva e check-nel nuovo flusso di lavoro. Aggiorna il tuo definizione di compilazione per utilizzare questo nuovo flusso di lavoro, quindi nella scheda Processo della definizione di compilazione, troverete una nuova sezione chiamata Varie con il nuovo argomento pronto per essere utilizzato. Perché io sto semplicemente usando questo nuovo parametro per la distribuzione, ho copiato gli stessi argomenti esatte che ho usato per MSBuild Arguments e aggiornato il MSDeployServiceURL al mio server secondo la distribuzione.

E questo è tutto. Suppongo che un metodo più elegante sarebbe quello di MSBuildArguments convertire in un array di stringhe e quindi ciclo attraverso di loro durante il processo di workflow. Ma questo si adatta alle nostre esigenze di server 2.

Spero che questo aiuti!

Answer 3

La mia soluzione a questo è un nuovo target che corre dopo il pacchetto. Ogni progetto che ha bisogno di produrre un pacchetto include il file target, e ho scelto di fare il Includere condizionale su un esternamente insieme di proprietà "DoDeployment". Inoltre ciascun progetto definisce la proprietà DeploymentServerGroup in modo che il server di destinazione (s) sono adeguatamente filtrato a seconda del tipo di progetto si tratta.

Come si può vedere verso il fondo sto semplicemente eseguire il file di comando con l'elenco dei server, piuttosto semplice.

<!-- 
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

Io sono l'autore del post di altri simili. Devo ancora trovare una soluzione. Credo che sta per essere la modifica del flusso di lavoro per aggiungere un compito post-elaborazione MSBUILD -sync. Che sembra essere la più elegante, ma era ancora sperando di trovare qualcosa di un po 'meno intrusivo.

Answer 5

Non sono sicuro se questo potrebbe aiutare con TFS 2010, ma ho un post del blog per TFS 2012: multiple distribuzione progetti web da TFS 2012 al NLB abilitato ambiente .