Поделиться через

Publicação de ASP.NET com Web Deployment Tool Service(sem passar credenciais)

  • Статья

Problema:

Surgiu uma necessidade de fazer deploy de uma aplicação ASP.NET no IIS6 utilizando Team Build. A abordagem mais utilizada que é passando parâmetros para o MSBuild, porém dessa maneira as credenciais ficam expostas. Neste post vamos ver como customizar o Build Template para chamar o executável do MSDeploy e fazer a publicação utilizando NTLM para autenticação.

 

Solução:

Há bastante tempo o Web Deployment Tool tem sido utilizado com o Team Build para fazer deploy de aplicação Web. Normalmente o que vemos nos exemplos é passar os seguintes argumentos para parâmetros do MSBuild no Build Definition:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc /p:MSDeployServiceUrl=localhost /p:DeployIisAppPath="Default Web Site/NewOrleansJazz" /p:UserName=domain\user /p:Password=myPassword

Eu não  vou entrar em detalhes sobre essa abordagem, quem quiser saber mais a respeito basta acessar: https://vishaljoshi.blogspot.com.br/2010/11/team-build-web-deployment-web-deploy-vs.html

Essa abordagem é bem legal, o problema é que as credenciais ficam expostas, o que é péssimo em um ambiente corporativo.
Surgiu uma necessidade de fazer essa publicação automatizada de uma aplicação ASP.NET em um servidor II6.

Estou utilizando o lab instalado no post sobre TFS Enterprise. Apenas adicionei mais uma máquina com o Windows 2003 R2 SP2 e configurei o IIS 6 nesta última.

Nas imagens abaixo pode ser vista a configuração do meu Build Definition:

image

image

image

image

image

Como vocês podem observar na verdade não tem nada de especial no meu build definition. O único ponto que vale a pena observar é que eu passei o seguinte para MSBuild Arguments: “/p:DeployOnBuild=true /p:Configuration=Release”.

O argumento /p:DeployOnBuild=true fará com que seja gerado  o pacote (.zip) para deploy. Já o argumento /p:Configuration=Release é opcional. Eu utilizei esse parâmetro porque também estou utilizando o recurso de Web.Config Transformation.

Agora vamos fazer a customização no nosso Build Template.

Eu utilizei o DefaultTemplate.xaml que está localizado em $/<TeamProjectName>/BuildProcessTemplates/DefaultTemplate.xaml.

Para adicionar esse comportamento no Build eu adicionei duas atividades, uma chamada ExpandEnvironmentVariables e outra chamada InvokeProcess. Estas duas foram adicionadas dentro da atividade Try Compile, Test, and Associate Changesets and Work Items. Elas são as últimas a serem executadas dentro do escopo dessa atividade mãe (ou pai hehe).

image

Eu criei duas variáveis no escopo da atividade Try Compile, Test, and Associate Changesets and Work Items:

  • MSDeployPath com o valor "$(ProgramFiles)\IIS\Microsoft Web Deploy V2\MSDeploy.exe"
  • MSDeployPathExpanded – sem valor.

Para a atividade ExpandEnvironmentVariables eu passei a variáveis MSDeployPath em Input e MSDeployPathExpanded em output. Com isso eu vou ter o caminho do executável do MSDeploy dentro do meu Build Agent.

Para a atividade InvokeProcess eu passei MSDeployPathExpanded em FileName. Em arguments é que vem a parte mais importante:

String.Format("–verb:sync -source:package=""{0}"" –dest:auto,computername=""10.0.0.5/MsDeployAgentService"" –allowUntrusted -setParam:""IIS Web Application Name""=""WebApp""", System.IO.Path.Combine(BinariesDirectory, "_PublishedWebsites\SimpleWebApp_package\SimpleWebApp.zip")).

 

Valor entender por partes essa linha:

  • –verb:sync -source:package=""{0}" – aqui estou indicando o caminho do package. Isso será substituído pelo valor que está sendo gerado em System.IO.Path.Combine(BinariesDirectory, "_PublishedWebsites\SimpleWebApp_package\SimpleWebApp.zip")
  • –dest:auto,computername =""10.0.0.5/MsDeployAgentService"" – aqui estou indicando o computador destino. O endereço é o endereço do MsDeployAgentService
  • -setParam:""IIS Web Application Name""=""WebApp"" – aqui estou indicando a aplicação no IIS que vai receber o pacote.

*Não esqueça de fazer check-in do Build Template depois que terminar a customização.

Um ponto importante é que a conta que está rodando o serviço de build precisa ser adicionada como Administrador no servidor do IIS6.

Com isso basta executar o build e ver a aplicação sendo publicada no IIS:

image

 

Para quem utilizada o IIS7+ existe uma maneira melhor de fazer isso que é utilizando o Web Management Service. Logo farei uma versão desse post utilizando o Web Management Service e o Web Deployment Tool Handler.

No Visual Studio 11 tem algumas novidades muito legais sobre publicação de aplicações. Aguardem posts sobre isso também! Smile

Thanks to Jim Lamb who suggested me to do it using this approach.

 

Daniel Oliveira

Comments

  • Anonymous
    May 29, 2012
    Bélo post Daniel... Agora fico no aguardo do post para IIS7...

  • Anonymous
    October 11, 2012
    Daniel, vale ressaltar que essa abordagem só funciona se o usuário que está rodando o build tiver permissão de administrador na maquina de destino. Além disso, a outra abordagem de passar parâmetros para o MSBuild, funcionará muito bem sem usuário e senha, caso o usuário do build tenha permissão na maquina de destino.

  • Anonymous
    February 28, 2013
    @Igor - Eu comentei sobre precisar ser administrador no post. :) Nos meus testes a abordagem de passar os parâmetros do MSBuild no Build Definition não funcionam, mesmo que o usuário possua permissão na máquina de destino.