Définition TFS2010 Construire à déployer sur plusieurs serveurs?

Question

J'ai cherché dans TFS2010 nouvelles fonctionnalités de construction et de déploiement avec MSDeploy. Jusqu'à présent, tout va bien (même si son été difficile de trouver des informations sur les scénarios de particuliers).

Puis-je modifier ma construction Définition pour spécifier 2 ou plusieurs serveurs à déployer pour? Ce que je dois faire est de déployer plusieurs serveurs (comme je l'ai deux dans mon environnement de test qui utilise un NLB).

Ce que j'ai maintenant une définition de construction qui construit, gère mes tests, puis à Déploie un de mes serveurs de test (qui a le MsDeployAgentService en cours d'exécution sur elle). Il fonctionne très bien, et chaque projet Web est déployé en tant que configuré dans le fichier de projet. Les arguments que je MSBuild utilise sont:

* /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: Je ne l'utilise / p: DeployIISAppPath = "xyz" comme il ne marche pas déployer tous mes projets et Dérogations ma config de projet

.

Puis-je ajouter un autre argument de construction pour l'obtenir pour appeler plus d'un MSDeployServiceURL? Comme quelque chose comme une seconde / p: l'argument MSDeployServiceURL un autre serveur qui spécifie

Ou dois-je chercher une autre solution, comme la modification du WF?

J'ai vu un presque exactement la même question posée ici il y a 2 mois: TFS 2010 -. déploiement de plusieurs serveurs après la version , il ne semble pas que je suis le seul à essayer de résoudre ce

J'ai également affiché sur les forums IIS.NET où MSDeploy est EXAMINER: http: // forum .iis.net / t / 1170741.aspx . Il a eu beaucoup de points de vue, mais encore une fois, pas de réponse.

Answer 1

Vous ne devez pas construire le projet à deux reprises pour déployer deux serveurs. Le processus de construction construira un ensemble de fichiers de déploiement. Vous pouvez ensuite utiliser le InvokeProcess à déployer sur plusieurs serveurs.

Tout d'abord créer une variable nommée ProjectName. Ensuite, ajoutez une activité d'affectation à la séquence « Compilation du projet ». Il est situé dans la séquence « Essayez de compiler le projet ». Voici les propriétés du Assign:

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

Voici les propriétés de notre activité InvokeProcess qui se déploie sur le serveur de test:

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.

Si vous devez déployer manuellement à un serveur, vous pouvez exécuter la commande ci-dessous à partir du dossier de construction:

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

Answer 2

Je ne pouvais pas trouver la solution que je cherchais, mais voici ce que je suis venu avec à la fin.

Je voulais garder la solution simple et configurable dans les arguments de TFS tout en même temps en restant en conformité avec la méthode MSBuildArguments déjà fourni qui a été promu beaucoup. Donc, j'ai créé un nouveau modèle de construction, et a ajouté une nouvelle TFS WorkFlow Argument appelé MSBuildArguments2 dans l'onglet Arguments des WorkFlow.

Je recherche à travers le BuildTemplate Dématérialisation occurences du MSBuildArguments (il y avait deux occurences).

Les deux tâches que l'utilisation MSBuildArguments sont appelés Run MSBuild for Project. Juste en dessous de cette tâche, j'ai ajouté un nouveau « Si » bloc à la condition:

Not String.IsNullOrEmpty(MSBuildArguments2)

Je puis copié la tâche « Exécuter MSBuild pour le projet » et collé dans le nouveau bloc «puis » de Si, mettre à jour son titre en conséquence. Vous aurez également besoin de mettre à jour la nouvelle propriété ConmmandLineArguments de la tâche d'utiliser votre nouvel argument.

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

Après ces modifications, les regards de WorkFlow comme ceci:

Enregistrer et archivez le nouveau WorkFlow. Mettez à jour votre définition de build à utiliser ce nouveau WorkFlow, puis dans l'onglet processus de définition de la construction, vous trouverez une nouvelle section MISC avec le nouvel argument prêt à être utilisé. Parce que je suis tout simplement en utilisant ce nouvel argument pour le déploiement, je copiais exactement les mêmes arguments que j'utilisés pour MSBuild Arguments et mis à jour MSDeployServiceURL à mon second serveur de déploiement.

Et que ce que. Je suppose une méthode plus élégante serait de convertir MSBuildArguments en un tableau de chaînes et ensuite en boucle à travers eux au cours du processus de WorkFlow. Mais cela convient à nos 2 exigences du serveur.

Hope this helps!

Answer 3

Ma solution est une nouvelle cible qui court après le paquet. Chaque projet a besoin pour produire un paquet comprend ce fichier cible, et j'ai choisi de faire la Inclure conditionnelle à une propriété « DoDeployment » en externe ensemble. En outre, chaque projet définit la propriété DeploymentServerGroup de telle sorte que le serveur de destination (s) sont correctement filtrée selon le type de projet, il est.

Comme vous pouvez le voir vers le bas, je suis simplement exécuter le fichier de commande avec la liste des serveurs, assez simple.

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

Je suis l'auteur de l'autre poste similaire. Je n'ai pas encore trouver une solution. Je crois qu'il va être modifier le flux de travail pour ajouter la tâche d'un MSBUILD de post-traitement. Cela semble être le plus élégant, mais espérait encore trouver quelque chose d'un peu moins intrusive.

Answer 5

Je ne sais pas si cela pourrait vous aider à TFS 2010, mais j'ai un blog pour TFS 2012: multiple déploiement de projets web de TFS 2012 NLB environnement activée.