It is published on Microsoft Research and I highly encourage anyone involved in software projects to watch.
URL: https://research.microsoft.com/apps/video/default.aspx?id=103754&l=i 

Below my notes about the presentation (good luck to understand my hand-writing ).

A URL para o post é: https://blogs.msdn.com/b/visualstudiobr/archive/2013/02/14/dicas-dos-pfes-deploy-de-aplica-231-245-es-web-com-visual-studio-e-team-foundation-server-2012.aspx

Daniel

I’ve just found out this great Project called TFS 2012 Demo Setup created by the MVP Tarun Arora.

With the tool you can populate your TFS Server/Service with data for your demonstrations. Check more info at: https://tfsdemosetup.codeplex.com/.

Daniel

Now we have three certifications for ALM. That is really great, because now, besides the Administration Certification we have two more. The complete list is:

• Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management (https://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-498)
•  Software Testing with Visual Studio 2012 (https://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-497)
• Administering Visual Studio Team Foundation Server 2012 (https://www.microsoft.com/learning/en/us/Exam.aspx?ID=70-496)

Regarding material to study we have two books already published, and one on the way:

Published:

To be published soon:

Off course, we also have our great friend MSDN. The documentation for the 2012 suite is better than ever – Application Lifecycle Management with Visual Studio and Team Foundation Server 2012: https://msdn.microsoft.com/en-us/library/fda2bad5.aspx.

I had the opportunity to deliver a presentation in the U.S.

My speak was about Continuous Deployment with Team Foundation Server 2012. Not the Azure deployment though. It was about automation to on-premises environments.

It was a great experience and all the work to create the presentation and the demonstrations made even more interested in build automation and deployment than before.

Speaking about the content, I’ve done three demonstrations:

• Automate web application deployment with Publishing Profiles and Web Deployment Tool
• Deploy and Rollback of: web application, WCF service library to IIS, Windows Service and SQL Server Database;
• Staged deployment with TFS Deployer

During the next weeks or months I’ll write in this blog about the scenarios, share my build templates and all this.

That’s it. I  just wanted to give a heads up about what is coming.

Daniel

Teremos uma trilha de ALM sobre plataforma Microsoft. O evento vai contar com importantes nomes em ALM no Brasil e uma série de palestras interessantes, dentre as quais: Continuous Deployment, DevOps, Visual Studio Scrum 2.0, etc...
Faça a inscrição em https://www.thedevelopersconference.com.br/tdc/2012/saopaulo/trilha-alm#programacao .

Eu apresentarei uma palestra sobre Continuous Deployment com Team Foundation Server 2012.

Daniel

Para se inscrever basta acessar https://tfspreview.com/ 

Para mais info sobre o que está disponível e passo a passo de como se inscrever basta ver no blog do Brian:  https://blogs.msdn.com/b/bharry/archive/2012/06/11/team-foundation-service-preview-is-public.aspx

Espero que gostem!!

Daniel

There was a request to deploy an ASP.NET Application to IIS 6 using Team Build. The common approach is to  use MS Build Arguments. Using this approach you need to pass the credentials to deploy the application, which make them (the credentials) exposed. In this post we are going to see how customize the Build Template to call MSDeploy.exe and publish the application using NTLM authentication.

Solution:

Web Deployment Tool is largely used to deploy Web Application. It gets even more interesting when you integrate with Team Build to automate the deployment. Usually the samples show how to use MS Build Arguments in the build definition and deploy the application. For instance you can use something similar to the following:

/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

I won’t get in details about this approach, but if you are willing to learn more about you can read this great blog post: https://vishaljoshi.blogspot.com.br/2010/11/team-build-web-deployment-web-deploy-vs.html

This approach is really interesting, the problem I see is that the credentials are exposed, what is terrible in an enterprise scenario.

To use a different approach I have created a build definition like in the images below:

As you can see there is nothing particularly special in this build definition. The only detail that is worth mentioning is that I’m passing two arguments to MS Build: “/p:DeployOnBuild=true /p:Configuration=Release”.

The argument /p:DeployOnBuild=true will tell MS Build to generate a package (.zip) to deploy. The argument /p:Configuration=Release is optional. I am passing it because I am using the Web Config Transformation feature.

Now lets customize our Build Template.

I am using the DefaultTemplate.xaml which is available at $/<TeamProjectName>/BuildProcessTemplates/DefaultTemplate.xaml.

To make it happen I have added two activities, one called ExpandEnvironmentVariables and another one called InvokeProcess. Both activities were added in the scope of the activity Try Compile, Test, and Associate Changesets and Work Items. They are the last ones to be executed in the scope of the Try Compile… activity.

I have created two variables in the scope of the Try Compile, Test, and Associate Changesets and Work  activity.

• MSDeployPath with the value"$(ProgramFiles)\IIS\Microsoft Web Deploy V2\MSDeploy.exe"
• MSDeployPathExpanded with no value

For the ExpandEnvironmentVariables activity I’ve passed the variable MSDeployPath in Input and MSDeployPathExpanded to Output. After the execution of this activity I will the path to the MSDeploy executable inside the Build Agent machine.

For the activity InvokeProcess I have paased the MSDeployPathExpanded to FileName. To arguments I have passed the following:

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")).

Lets understand each part of the argument:

• -verb:sync -source:package=""{0}" – here we are indicating the path to the package. It will be replaced by the value generated in System.IO.Path.Combine(BinariesDirectory, "_PublishedWebsites\SimpleWebApp_package\SimpleWebApp.zip")
• -dest:auto,computername =""10.0.0.5/MsDeployAgentService""  - here we are indicating the destination for our package. This is the address of the MsDeployAgentService.
• -setParam:""IIS Web Application Name""=""WebApp"" – here we are indicating the IIS Application that will receive the package.

Do not forget to check-in the Build Template after the changes.

One important point is that the account running the Team Build Service needs to the local administrator in the IIS6 server.

With that just execute the build to deploy the application:

If you are using IIS7+ there is a better way to do that, which is using the Web Management Service. I’ll post about this approach too, in a near future.

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

Daniel Oliveira

Hoje foi liberad a versão Release Candidate do Visual Studio 2012.

Essa versão está sensacional, traz muitos recursos novos e que vão ajudar times a entregarem mais valor de negócio aos clientes, terem software de maior qualidade e alcançarem mais produtividade no dia a dia. Claro que isso tudo associado às técnicas, práticas e processos necessários.

Os principais posts a respeito são do Jason Zander dando uma geral no Visual Studio e no .NET Framework: https://blogs.msdn.com/b/jasonz/archive/2012/05/31/announcing-the-release-candidate-rc-of-visual-studio-2012-and-net-framework-4-5.aspx

E claro, do Brian Harry passando pelos novos itens do TFS 2012: https://blogs.msdn.com/b/bharry/archive/2012/05/31/visual-studio-tfs-2012-release-candidate-available-today.aspx

Espero que vocês gostem tanto desta versão quanto eu estou gostando.

Enjoy!

Daniel

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:

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).

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:

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!

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

Daniel Oliveira