Fazendo o MSDeploy funcionar em nosso servidor de compilação/integração - É necessária uma atualização do MSBuild?

Question

Temos o que considero um processo de construção bastante padrão:1.Desenvolvedor:Verifique o código 2.Construir:Pesquisa o repositório, vê as mudanças e dá início à construção que:3.Construir:Atualizações do Repo, constrói com msbuild, executa testes de unidade com Nunit, 4.Construir:cria pacote de instalação

Nossa equipe de segurança nos permite fazer pull do servidor de build, mas não permite que o servidor de build faça push.Portanto, geralmente fazemos o rdp, d/l os instaladores e os executamos, o que exclui os serviços de implantação sofisticados, então, em vez disso, eu precisaria gerar pacotes.Gostaria de usar o MSDeploy, exceto que temos os seguintes problemas:

1. Estamos no .net 3.5 e o destino do MSBuild (pacote) que usa o MSDeploy requer 4.0.Há algo que eu precise instalar além do .net 4.0 RC para isso?(O MSBuild faria parte dessa atualização?)
2. Quando gero pacotes com o MSDeploy, vejo que não tenho apenas um arquivo.Há um zip, deploy.cmd, SourceManifest.xml e SetParameters.xml.Para que servem todos os outros arquivos e por que eles não estariam todos no 'pacote'?
3. Parece que você pode criar pacotes dizendo ao sistema para procurar um site IIS em funcionamento.Mas se os pacotes são construídos a partir de um ambiente de CI, você não está basicamente sem sorte aqui?Parece que eles projetaram parte disso para desenvolvedores de pequena escala, implantando em seu ambiente de desenvolvimento.Esse é um bom caso de uso, mas estou interessado em ver como é a experiência empresarial de todos com a ferramenta

Alguma sugestão?

Answer 1

Se você não estiver usando o Visual Studio 2010 para seu aplicativo, sugiro que escolha um dos seguintes:

1. Usar msdeploy.exe
2. Instale o Visual Studio 2010 em seu servidor de compilação e use as próprias tarefas do MSDeploy

Deixe-me explicar um pouco mais.

Opção 1

O próprio MSDeploy não depende do MSBuild, portanto você pode instalá-lo sozinho em seu servidor de compilação para criar os pacotes para você.Você pode baixá-lo em aqui.Depois disso, você pode criar um script de implantação do MSBuild usando o Executivo tarefa para chamar msdeploy.exe com o comando para criar seu pacote.

Sobre a segunda opção

Os arquivos .targets, bem como as tarefas do MSDeploy, não são implantados com o .NET framework, mas com o próprio Visual Studio 2010.Portanto, se você quiser aproveitar qualquer um deles, terá que instalar o VS 2010 em seu servidor de compilação.

Você mencionou usar o pacote alvo em sua postagem.Você não poderá usar isso porque esse destino faz parte de um processo de construção maior para projetos .NET 4.O que você poderia fazer é criar um arquivo MSBuild separado (separado como se não fosse o seu arquivo de projeto) que usa o MSBuild 4 para chamar o tarefas que são entregues com o VS 2010 para Web Deployment.

Aqui eu respondo sua lista numerada especificamente

1. Você teria que instalar o Visual Studio 2010, pois essas tarefas são fornecidas com o próprio VS e não com a estrutura.
2. Esses arquivos são usados ​​para interagir com seu pacote.Seu pacote apresenta seu aplicativo como um todo.O deploy.cmd invocará msdeploy.exe para realizar a implantação para você.SourceManifest.xml e SetParameters.xml são usados ​​para personalizar a implantação do seu aplicativo.deploy.cmd usará esses arquivos ao invocar msdeploy.exe.Em outras palavras, se você quiser personalizar o caminho para onde o aplicativo da web será instalado, você deve definir isso em SetParameters.xml junto com outras opções.
3. Você está certo, as configurações podem vir do IIS, mas muitos desenvolvedores preferem usar o servidor de aplicativos VS em vez do IIS.Essa é a minha preferência.O que eu sugeriria neste caso é implantar seu aplicativo em um ambiente que você usará como modelo.Faça todas as configurações do IIS necessárias, crie seu pacote MSDeploy e, em seguida, pegue o arquivo archive.xml do pacote e use-o ao criar seu próprio pacote.Outra opção é configurar um servidor IIS no qual seu processo de construção possa ser implantado e, em seguida, usar o MSDeploy apenas para sincronizar os arquivos que compõem seu aplicativo e, mais uma vez, gerar o pacote a partir desse servidor IIS.