Essa eu passei durante uma consultoria no cliente. A situação era a seguinte: O Team Build e os agentes estão instalados em máquinas 64bits. Tinha um projeto que precisava ser compilado com algumas informações e dll´s de x86.

Quando mandava rodar normalmente, ele apenas dava um erro falando que não conseguia carregar umas dll´s.

Após fazer um estudo percebi que o msbuild procurava as informações no diretório x64 dos projetos e as informações dentro do arquivo de csproj (que é o arquivo que contém o script de msbuild) mandava procurar dentro do x86. Se eu mudasse essa informação quebrava a compilação na máquina dos Devs e sem ela não funciona no servidor de build. E aí, como resolver ?

Dentro da Build Definition tem um parametro que nós podemos usar justamente para isso.

Como setar o parâmetro:

Vá na sua Build Definition –> Aba Process –> Advanced. Lá tem uma opção chamada: MSBuild Plataform e pronto, todos os seus problemas estão resolvidos!

Por padrão ele vem com a opção Auto, isso significa que ele vai identificar qual é a plataforma do sistema operacional que ele vai rodar e chama o MSbuild.exe daquela plataforma.

Para resolver o problema aqui, simplesmente coloquei a propriedade com o valor X86 e tudo funcionou perfeitamente!

Até a próxima

No último mês trabalhei em uma PoC e nela temos que validar alguns cenários especificos. Um desses cenários era trabalhar com códigos-fontes que são desenvolvidos apenas em máquinas que rodam Linux.

Até aí nada demais vocês podem falar, afinal posso usar o Team Explorer Everywhere (TEE) que vai resolver meu problema, ou posso usar o TFS e Git como demonstrado pelo Giovanni Bassi nesse post (http://blog.lambda3.com.br/2013/01/tfs-agora-suporta-git/) .

Mas imagine que você está trabalhando com um ambiente de TFS local e não o TF Service (que é o único que suporta Git) e ainda tem aquele usuário de linux que gosta de usar apenas linha de comando, ou por algum outro motivo, não possa ou não queira instalar o Eclipse para rodar o TEE.

Para esse cenário, podemos usar o Cross-platform Command-Line Client for Team Foundation server.

Nesse link tem os passos necessários para você baixar e configurar o command line. Mas e aí, como eu uso para poder fazer o meu check-in e check-out ?

Primeiro temos que aceitar o End User License Agreement (EULA), para isso, na pasta onde você descompactou o zip digite:

tf eula

Vá até o final do arquivos e aceite os termos.

Depois de aceitar o EULA, vamos agora facilitar as coisas um pouco. Os comandos que vamos usar sempre pedem que passemos como parametros a collection vou realizar a operação, usuário e senha. Para evitar de ficar sempre digitando as informações, sugiro criarmos um alias no bash, assim além de em qualquer lugar você apenas digitar o tf  e o seu S.O entender podemos também já colocar essas informações que sempre precisariamos usar. Para isso, digite o seguinte na sua console:

alias tf=’local_onde_voce_descompactou_o_script/tf –login:(seu_usuario)@dominio.(Senha) –collection:http://end_servidor:porta/tfs/nm_collection

Com o nosso alias configurado vamos criar o nosso workspace, para isso, crie uma pasta na sua home, como por exemplo ProjetoNoTFS com o seguinte comando:

mkdir ~/ProjetoNoTFS

Agora vamos criar o nosso workspace no TFS, para isso digite:

tf workspace –new –location:local –permission:Private

Existem outros parametros, para ter uma lista completa, digite apenas ./tf

Depois de ter o workspace criado, vamos mapear a working folder, para isso, digite:

tf workfold –map (pasta_no_servidor) (pasta_local) –workspace:(nome_do_workspace)

Agora podemos baixar todos os arquivos que já estão no repositório. Entre na pasta que acabamos de mapear e digite :

tf get

Agora podemos editar as informações e fazer um checkin, no meu caso, vou adicionar um arquivo txt que criei no Linux. Para isso digite :

tf add  (nome_do_arquivo)

Agora vamos fazer um checkin, para isso digite:

tf checkin  (nome_do_arquivo) –comment:“comentario que quiser”

se quiser vincular um workitem no checkin, utilize o parametro –associate ou -resolve

e para fazer o checkout :

tf checkout  (nome_do_arquivo)

Espero que tenham gostado.

Até a próxima

Imaginem o seguinte cenário, um desenvolvedor que trabalhava no seu projeto pediu demissão e um novo desenvolvedor foi contratado para trabalhar em seu lugar. Antes de liberar a máquina para o novo desenvolvedor, geralmente a máquina com as configurações originais é formatada e preparada para o novo desenvolvedor.

Perfeito, temos tudo pronto e o desenvolvedor novo já pode começar a trabalhar. Assim que ele abre o Visual Studio, esse novo desenvolvedor vai criar seu workspace para “baixar” seu projeto em uma pasta padrão. Ao fazer isso ele pode receber uma mensagem, informando que já existe um workspace vinculado no Visual Studio.

E agora? o desenvolvedor antigo já foi embora. A máquina que ele usava já foi formatada. Como podemos apagar essa informação do servidor e libere a máquina para outro usuário?

Outra situação, seu desenvolvedor saiu de férias e esqueceu de fazer o check-in de alguma coisa que ainda estava trabalhando e outra pessoa da sua equipe precisa mexer nesse(s) arquivo(s). Como podemos liberar esses arquivos?

Existem duas maneiras, uma é via linha de comando, porém nada amigável e a outra é usando uma excelente ferramenta que ajuda na administração do seu Team Foundation Server: Team Foundation Sidekicks

Essa é uma das ferramentas que utilizo muito e sempre passo para o clientes para ajudar na administração do TFS.

Até a próxima!

Hoje dia 26.03 eu tive a oportunidade de palestrar no MVP Virtual Conference. Foi um grande prazer! Ser escolhido para falar junto com os MVP´s de ALM realmente foi uma honra, espero ter atendido a todas as expectativas e de todos!

Na palestra eu comentei sobre os  Alm Rangers, o Guide de Branch & Merge e o plug-in que instalado no Visual Studio nos ajuda a criar a nossa estrutura inicial de branch e guide.

•  Branch & Merge Guide
• Plug-in do Visual Studio 2012

Surgiram perguntas em como poderíamos trabalhar com o Xcode e o TFS, como trabalhar em sistemas não Windows e o TFS para gerenciar minhas branches. Vou preparar essa semana alguns post sobre esses cenários.

Eu já tinha feito uma palestra sobre Branch e Merge no ALM Summit 2012 e acabei escrevendo um post completando algumas informações, quem quiser, pode acessar o post no link: http://blog.lambda3.com.br/2012/05/minha-palestra-no-alm-summit-brasil-2012/

Querem conhecer mais sobre ALM, não percam o ALM Summit Brasil 2013!!

Já imaginou você ir para um evento, ver as melhores práticas de ALM e ainda poder ganhar um XBOX ??

Para maiores informações : http://www.almsummitbrasil.com.br/

Espero que tenham gostado da palestra e em caso de dúvidas, deixem seus comentários ou enviem por twitter ou e-mail.

Abs!

Nesse post vou falar um pouco de uma solução que implantei em um cliente. O Cenário lá é o seguinte: Eles possuem uma solution que contém mais de um projeto Web App e projetos WCF.

Nós já tínhamos implementado nesse projeto a Continuos Integration, criando uma Build Definition e setando a trigger de CI.

Depois de um tempo foi requisitado uma build noturna e que nessa build os projetos web e os serviços fossem publicados no ambiente de homologação, automatizando o processo de build e deploy.

Basicamente, iremos validar a compilação, rodar testes de unidade e integração (quando aplicável) e se tudo der certo, publicar no ambiente de homologação para que o usuário final pudesse validar as últimas alterações implementadas.

Para atender esse cenário, utilizamos uma funcionalidade do Visual Studio, o publish profile ( para infos sobre o que é e como criar, acesse o site: http://msdn.microsoft.com/en-us/library/dd465337.aspx )

Depois que criarmos os publishes profiles conseguiríamos publicar os sites e serviços se clicássemos com o botão direito e der o publish. Essa ainda não é a solução desejada.

Como fazer para encaixar isso na minha Build Definition e quando ela rodar os meus sites serem publicados?

Na sua Build Definition, vá na aba de processos e procure a opção MSBuild Arguments, conforme a figura abaixo:

Agora que a coisa começa a ficar interessante, o MSBuild tem um parâmetro que podemos passar que permite que eu informe o nome do meu Publish Profile para fazer o deploy logo após a compilação e execução dos testes.

Para isso digite o seguinte no MSbuild Arguments :

PublishProfile=”QA”

O “QA” é o nome que você deu para o seu publish profile. Para que todos os seus sites e serviços sejam publicados, basta dar o mesmo nome para o publish profile e tudo será publicado logo após a compilação e execução de testes.

Com isso, de forma simples e rápida montamos uma solução que compila e faz o deploy das nossas aplicações para qualquer ambiente que desejarmos.

Até a próxima.

Semana passada eu estava fazendo uma PoC em floripa e acabou que pude ir em uma reunião do grupo DotNetFloripa para falar um pouco sobre o TFS.

A palestra era para ser de 45 mins, mas acabou que ficamos conversando bem mais tempo. Também, falar de TFS é fácil, posso ficar horas conversando sem problemas.

Para comeplementar, quem quiser pode baixar a máquina virtual que eu utilizei para realizar as demos no seguinte link:

http://blogs.msdn.com/b/briankel/archive/2011/09/16/visual-studio-11-application-lifecycle-management-virtual-machine-and-hands-on-labs-demo-scripts.aspx

Foi um prazer conversar com vocês !! Espero que na próxima eu consiga ir com mais calma e assim podermos beber mais cervejas!

Até a próxima!

Esse post já estava para sair tem um bom tempo, mas antes tarde do que nunca.

Outro dia estava em um cliente e um pedido foi: “Claudio, eu já trabalho bem com os work items e sempre faço check-in vinculando meu código a uma tarefa especifica. Tem como quando eu for fazer a promoção do meu código entre os branches eu usar o work item e não o changeset ??? “

A resposta padrão é não, mas o consultor falou mais alto e rápido. “bom depende… ” e fui detalhando o modelo que já havia feito em outros clientes para as versões antigas (TFS 2008).

O único modelo seria através de algum programa customizado onde você acessaria a API do TFS para pegar todas as tarefas em algum determinado estado, depois você teria que pegar todos os changesets vinculados aí sim você conseguiria saber os arquivos para fazer o download para um workspace local e depois fazer o merge arquivo por arquivo para o branch desejado.

Dois dias depois, conversando com o Vinícius Moura da Lambda, ele me mostrou um plug-in para o TFS que fazia isso também, mas na hora não guardei o nome. Chegando em casa fui pesquisar, como não lembrava o nome específico, procurei pelo o que ele faz e o resultado da pesquisa me trouxe um link da Microsoft mostrando isso. Todo o trabalho agora já faz parte do produto!!!Vamos ver na prática como funciona.

Minha estrutura de branch é simples, usando a estratégia de ambientes, conforme imagem:

Agora precisamos de umas tarefas com changesets vinculados

No meu caso, criei um projeto simples e fiz algumas alterações vinculando a uma tarefa, conforme figura abaixo:

Imagina agora que a minha tarefa está pronta e todos os arquivos necessários estão vinculados a ela através dos changesets 151 e 152 e preciso saber em qual branch ela está publicada.

Para isso, temos um ícone novo na parte do work item, que é o Track Work Item

Ao Clicarmos nesse botão a seguinte imagem será apresentada :

É importante selecionar todos os branches, assim será possível ver em quais dos branches a tarefa já foi publicada ou não, feito isso clique em Visualize e pronto, você verá exatamente onde o seu work item está publicado!

Nesse meu modelo, eu consigo identificar que o Work Item 70 já está publicado em Dev e QA, mas ainda não foi para produção.

Espero que tenham gostado e até a próxima!

Antes de adicionarmos a tarefa de Deploy, vamos tirar dois itens que estão fixos no nosso comando e que o ideal é que pudessemos entrar com valores, assim quando formos utilizar essa build em outro team project, basta configurar os parametros na Build Definition e ele também iria funcionar.

Para criar esse parametros, basta usarmos as abas de configuração do DefaultTemplate.xaml (as abas ficam na parte de baixo do workflow) e mais algumas informações irão aparecer.

Vamos criar 3 parametros:

1 – Informando qual é o nome do website que queremos publicar. Esse é o nome que foi dado na criação do website no Visual Studio. Tem que ser exatamente igual.

2 – Informando qual é o diretório onde o pacote será escrito. Lembre que esse diretório o usuário do Team Build deverá ter acesso.

3 – Nome do pacote que iremos gerar.

Clique na última linha para criar esses parametros.

• NmWebSite
• Diretorio
• NmPacote

Agora vamos fazer os parametros aparecerem na tela da Build Definition

Na lista de parametros, vamos procurar o argumento Metadata. Ele é um argumento especial que nos permite criar parametros na área de Process de uma build definition. Ao achar o parametro, clique no ícone para abria a janela de configuração.

Na janela, iremos clicar no botão Add e preencher o formulario com os seguintes valores:

• Parameter Name : É o nome do parametro que ficará acessível para utilizarmos nas atividade do workflow
• Display Name: É o nome que aparecerá na Build Definition
• Category: Nome da categoria que será criada para armazenar os parametros que criarmos

Fazendo o check-in do template e abrindo novamente a nossa Build Definition, encontraremos os nossos parametros.

Agora vamos alterar a nossa tarefa de criação do pacote. Vamos alterar o valor do Arguments para :

Arguments: String.Format(“-verb:sync -source:contentPath=”"{0}\_PublishedWebSites\{1}\”" -dest:package=”"{2}\{3}”" “, BinariesDirectory, NmWebSite, Diretorio, NmPacote)

Vamos criar mais 2 parametros, esse conterão informações sobre onde iremos fazer o Deploy. Siga os procedimentos acima para criar mais esses dois parametros e coloque no mesmo grupo.

• ServidorDeploy
• IISPathServidorDeploy

Com o nosso pacote criado e os novos parametros configurados, vamos adicionar a tarefa que vai realizar o deploy.

Para isso, arraste outra tarefa de Invoke Process para ficar logo abaixo da tarefa de criação do pacote e a configure com os seguintes parametros:

Arguments: String.Format(“-verb:sync -source:package=”"{0}\{1}”" -dest:contentPath=”"{2}”",computername=”"{3}/MsDeployAgentService”" -allowUntrusted “, Diretorio, NmPacote, IISPathServidorDeploy, ServidorDeploy )

DisplayName: Deploy do Pacote

FileName: String.Format(” “”c:\Program Files\IIS\Microsoft Web Deploy V2\MSDeploy.exe”" “)

Preencha os novos parametros na build definition e execute uma build para ver a solução funcionando.

E pronto! com isso o seu Website será publicado no servidor indicado!

Nessa parte, vou fazer um paralelo de como faríamos se fizemos o mesmo procedimento usando uma WebApplication.

Inicialmente, vou falar um pouco da estrutura estrutura diferente dos dois tipos de projetos.

Quando criamos um WebSite project no Visual Studio, automaticamente um arquivo da solution é criado. Até aí nada demais, afinal o Visual Studio faz isso para qualquer novo projeto. O ponto diferente é que para o WebSite, nós não temos um arquivo de projeto! e aí começam alguns de nossos problemas…

O arquivo *.vbproj ou *.csproj nada mais é do que um script do MSBUILD, onde existem algumas configurações informando o que deve ser feito na hora da compilação do projeto e isso é essecial para o TeamBuild.

O Team Build encapsula algumas informações para nós, deixando toda essa configuração e customização mais fácil, mas em um dado momento de seu workflow ele simplesmente pega o arquivo do seu projeto, passa ele como parametro para o MSBUILD que irá realizar a compilação.

O MSBUILD por padrão aceita dois tipo de arquivo o *.vbproj ou *.csproj e o *.sln. A grande diferença é que nos *.*proj temos alguns scripts já implementados e quando usamos o *.sln o MSBUILD irá usar as configurações básicas instaladas, não tendo disponível nenhum target (tarefas que devem ser executadas para compilar o projeto) diferente que possuem alguns parametros a mais, como por exemplo o DeployOnBuild.

Qual é o impacto disso para o nosso deploy ? Simples, a primeira coisa que precisamos fazer para que possamos fazer o deploy automático é criar um pacote. Esse pacote que contém todos os arquivos necessários do nosso site e alguns arquivos de configuração que o MSDeploy irá utilizar.

Para criar o pacote, no caso de uma WebApplication, precisamos apenas passar um parametro para o MSBUILD e ele montará o pacote para nós. Vamos ver o exemplo:

Primeiro, teamos que criar uma  Build Definition para a Web Application (igual aos passos anteriores) e adicionar esse parametro, para isso abra sua build definition novamente e vá até a aba Process, conforme imagem abaixo:

Na aba de processo, vamos no item 3 Advanced e vamos procurar o parametro MSBUILD Arguments e vamos adicionar o parametro /p:DeployOnBuild=true a mais que vai fazer que um pacote já seja criado durante a compilação de uma Web Application.

Pronto, feito isso, enfilere uma build e depois vamos no diretório onde o Site foi compilado para ver o pacote criado.

Depois de gerar a build e a compilação ter sido concluída com sucesso, vamos no seguinte diretório: (Esse caminho é o padrão da configuração do Team Build e dos Agentes, então caso você tenha feito alguma configuração diferente o caminho pode variar).

Abra o Windows explorer e vá no seguinte caminho: C:\Builds\1 dali para frente, basta navegar nas pastas seguindo a seguinte lógica :

• Nome do team project
• Nome da Build Definition

Ao chegar na Build escolhida, vamos no diretório de Binários e no diretório onde contém os sites publicados. No meu exemplo esse caminho completo seria:

C:\Builds\1\TeamBuild\WebApp\Binaries\_PublishedWebsites

Olhando dentro desse diretório, veremos duas pastas. WebApp1 que contém os arquivos do Site e a pasta WebApp1_Package que contém o pacote que será utilizado para deploy.

(Não é escopo desses posts falar sobre a estrutura de arquivos do pacote, apenas como gerar de forma automática.)

Se fizermos a mesma coisa com a Build Definition do WebSite, ou seja, adicionar o parametro no MSBuild Arguments e formos no diretório, veremos que teremos quase todas as pastas iguais, menos a referente ao pacote.

Isso acontece porque o parametro de DeployOnBuild=true é um parametros que o script de MSBUILD (*.*proj) conhece e executa algumas atividades a mais para gerar o pacote. Como no projeto do WebSite não temos isso, teremos que montar “na mão” essa geração do pacote.

Para criar a geração do pacote, iremos utilizar o MSDeploy que é um componente utilizado para realizar deploy que foi desenvolvido pela microsoft e é instalado quando instalamos o Web Deploy. Para mais informações acesse : http://www.iis.net/download/webdeploy

Criando o Pacote para um WebSite

Já que não temos algumas facilidades, precisamos alterar o Workflow de build e adicionar uma tarefa que utilize o MSDeploy para realizar a geração do pacote. Para isso iremos utilizar como base da nossa customização o processo padrão o Default Template.

Para alterar o workflow de Build, vá no source control e entre nas seguintes pastas:

No nosso exepmlo: $/TeamBuild/BuildProcessTemplates e abra o arquivo DefaultTemplate.xaml

A seguinte tela será apresentada:

Esse é o workflow padrão utilizado pelo servidor de TeamBuild para compilar nosso projeto. Como não é escopo desse post, não entrarei em detalhes de como funciona esse procedimento e suas tarefas.

Para o nosso exemplo, vamos adicionar uma tarefa chamada da Invoke Process em um ponto especifico do workflow. A tarefa Invoke Process fica na toolbox no grupo Team Foundation Build Activities.

A nossa tarefa deve ser adicionada logo após a compilação do nosso website, por isso, procure dentro do workflow a sequencia de atividades chamada: Try Compile, Test, and Associate Changesets and Work Items e bem no final dela, arraste e solte a tarefa InvokeProcess, conforme figura abaixo:

Ao adicionar a tarefa bem no final dessa sequencia de atividades, a tarefa aparecerá com um ícone vermelho de exclamação, isso ocorre porque precisamos passar alguns parametros para que o Invoke Process funcione.

Para isso, abra as propriedade da tarefa (aperte F4) e vamos preencher os campos:

Arguments: String.Format(“-verb:sync -source:contentPath=”"{0}\_PublishedWebSites\WebSite1\”" -dest:package=”"c:\site\teste.zip”" “, BinariesDirectory)

DisplayName: Criação do Pacote

FileName: String.Format(” “”c:\Program Files\IIS\Microsoft Web Deploy V2\MSDeploy.exe”" “)

Como nesse primeiro momento queremos garantir apenas a criação do pacote, vamos deixar algumas informações do Arguments de maneira fixa, mais tarde iremos deixar mais dinâmico.

Obs: O caminho que você informar onde o pacote será criado, o usuário do teambuild tem que ter permissão de escrita, caso contrário o pacote não será criado. Para fins de exemplo, crie o diretório Site e dê permissão para todos.

Dica: Se você estiver com problemas para debugar, na tarefa Invoke Process tem dois espaços para você adicionar uma tarefa. Nela podemos adicionar uma tarefa que escreva no log da Build para identificar os possiveis problemas. para isso, arraste a tarefa do tipo WriteBuildMessage  e no parametro, coloque a string de Output de cada um dos Handles,

Feito isso, salve o template e faça o check-in do arquivo, caso contrário o TFS não irá executar essa nossa customização.

Depois de ter feito o check-in, gere uma nova build e quando ela finalizar com sucesso, vá no diretório onde definimos que estaria o nosso pacote para ver se ele foi criado.

Esse passo parece simples, mas pode trazer alguns problemas para o nosso ambiente de Build. Esses problemas podem ser criados por causa de dependências que o seu projeto tenha. Como estamos trabalhando com um servidor dedicado ao TeamBuild, ele precisará ter todas os componentes necessários para conseguir realizar a compilação do seu projeto.

Então para iniciar a nossa compilação, no servidor de Build, que nesse cenário que eu montei também está configurado o meu Agente de Build, será necessário instalar os componentes de terceiros que o seu projeto depende.

Como nesse exemplo eu não vou usar nada de terceiros não precisarei instalar, mas caso a aplicação de vocês necessite desses componentes instalados, vocês devem preparar esse ambiente com tudo que for necessário antes de iniciarmos a compilação.

Esse procedimento deve ser realizado em cada Agente de Build que você tiver, isso é muito importante, caso contrário o Team build não conseguirá compilar.

Como exemplo, eu criei 1 TeamProject Chamado TeamBuild e criei uma Build Definition WebSite1.

Vamos agora configurar a build definition, para esse exemplo, coloquei as seguintes configurações;

Nessa tela basta configurar o nome da sua Build Definition. O ideal é que seja um nome que faça referência ao que ela vai executar no sistema.

Como esse é apenas um exemplo eu coloquei a trigger como Manual.

Esse é um ponto muito importante e geralmente onde alguns erros de dependencia começam a ocorrer. Na aba Workspace é onde eu informo para o TeamBuild o que ele deve baixar para conseguir realizar a compilação do meu Website.

Assim que você cria a sua build definition, um dos pontos que o Visual Studio já configura para você é trazer qual pasta do Source Control será baixada e para qual diretório dentro do Agente de Build.

Um problema comum é que as vezes o Visual Studio coloca para baixar todo o seu repositório e isso acaba deixando muito lento o sistema de automação da build, pois cada vez que ele for executar uma build, ele baixará todo o seu repositório (vai baixar todos os arquivos que estão no seu source control, mesmo que sejam de outros team projects) e essa é uma tarefa um pouco demorada.

Imagina que seu repositória já tenha por volta de 1GB de arquivos mas o seu projeto só necessite de 10Mbs, toda vez o Team Build terá que realizar o download de 1GB de arquivos para utilizar os 10Mbs de arquivos que seu projeto precisa para ser compilado. Então tome cuidado configure bem quais os workspaces que você vai baixar.

Outro ponto importante é garantir que você baixe todas as pastas necessarias. Imagine a seguinte situação: Você possui um website e uma pasta de resources que contém algumas dll´s que foram adicionadas ao seu projeto de projetos externos que são necessárias para a compilação, um exemplo seria as dlls de algum framework desenvolvido na sua empresa. Essa pasta tem que ser mapeada para que seja realizado o download, caso contrário na hora de compilação irá ser gerado um erro por falta de recursos.

Para evitar esse tipo de problema, seria bom mandar baixar o repositório todo do seu Team Project, assim você terá uma garantia que tudo que está relacionado ao seu projeto será baixado para a compilação.

Para as telas de Build Defaults, Process e Retention Policy, nesse momento ficarão com as informações padrões. Iremos mexer na parte de Process mais tarde.

Agora vamos executar a nossa build e ver se a compilação vai funcionar.

Para isso basta enfileirar uma build, já que configuramos como trigger o modelo Manual e ver o resultado da Build.

E o resultado esperado tem que ser a compilação realizada como mostrado na seguinte tela:

Caso tenha dado algum erro de compilação, faça os ajustes necessários para podermos ir para o próximo passo.

Sem uma compilação realizada com sucesso, não conseguiremos realizar o deploy desse nosso WebSite.

Eu estou precisando montar uma solução para um cliente que temos que fazer o deploy automático de um site usando o Team Build. Existem milhares de posts explicando o procedimento de como usar o Team Build e o Web Deploy para fazer isso, mas como sempre, cada situação tem sua peculiaridade, essa não seria diferente.

Na situação atual nós temos que fazer o deploy de um site que foi criado usando o WebSite project do Visual Studio e por isso, várias da facilidades que teriamos com uma Web Application foram por água abaixo, obrigando a realizar um procedimento bem diferente do que temos publicado por aí.

Vamos primeiro aos desafios:

1 – Por utilizar o WebSite project, nós não temos um arquivo do vb.proj ou cs.proj, que já contém algumas definições de build e agrupa todos os projetos que devem ser compilados para que o site funcione corretamente.

2 – Precisamos fazer o controle do web.config por ambiente, e para variar, como não é uma WebApplication, a funcionalidade do WebConfigTransformation também não está disponível, nos obrigando a fazer esse procedimento na mão.

3 – Algumas máquinas de deploy não estão no mesmo dominio nem rede, o que complica um pouco mais o modelo de passagem do pacote do servidor de Build para as máquinas onde deveremos realizar o Deploy.

Vamos a solução proposta e aos poucos vou publicando um artigo para cada um dos passos descritos.

Preparando o ambiente:

Para que tudo funcione precisaremos ter instalado no nosso ambiente:

• 1 servidor de Build (preferencialmente uma máquina separada do servidor de aplicação do TFS)
• 1 servidor de homologação
• 1 servidor de produção

Para os servidores de homologação e produção, precisaremos ter instalado o IIS 7 ou superior, Web  Deployment Kit 2.1 ou superior, SO Windows 2008 Server (essa foi a configuração que eu usei no meu ambiente de teste).

Passos para a solução:

1 – Primeiro vamos configurar uma Build Definition que pelo menos compile o WebSite com todos os pré-requisitos que precisamos e depois faremos uma cópia manual desses arquivos para o IIS e ver se o site está funcionando como deveria

• Compilando o website com o teambuild

2 – Sabendo que nosso modelo de compilação está funcionando, vamos começar a realizar o deploy dessa compilação no IIS. Para isso iremos customizar um processo de build que contenham as tarefas de Web Deploy e faremos o deploy automático

• Gerando o pacote para deploy do WebSite
• Realizando o Deploy do Website com Msdeploy e TeamBuild

3 – Para finalizar, vamos criar o nosso web.config transformation. Iremos criar mais uma tarefa customizada para realizar essa atividade.

4 – Por ultimo, alguns pontos de verificação e modelos que talvez você tenham que implementar para comunicação entre as máquinas em dominios diferentes para a passagem do pacote de deploy.

Depois disso tudo, teremos o nosso deploy automático com web.config transformation em Website projects!

Qualquer dúvida, deixem seus comentários que irei ter o maior prazer em responder.

Até a próxima.

Esse é um procedimento bem simples, então vamos ao passo-a-passo :

Primeira etapa: Migrar a base de configuração do TFS

1. Entre no servidor do TFS e coloque as bases offline e depois pare os serviços do TFS. Nesse momento se no seu servidor de aplicação só tiver o TFS, basta para o IIS todo, caso contrário, pare apenas o site do TFS.
2. Depois de parar o site do TFS, pode parar o TFS Job, para isso, vá configuração dos serviços do Windows e de um stop no serviço do TFS.
3. Entre na máquina onde as bases do TFS estão e faça um backup de todas as bases, tanto as de configuração quanto as das Project Collections.
4. Entre no novo servidor do SQL e faça um restore nas bases que você quer subir nesse servidor.
5. Precisamos de um usuário de domínio que tenha permissão de Administrador no TFS. Porvavelmente você já tem essa conta que está apontando para o servidor antigo, por tanto podemos utilizar ela mesma. Caso você esteja em um amibente single server e utilizou apenas uma conta, siga o procedimento no link de instalação do TFS.
   Agora que vem a parte dificil, convencer o DBA que precisamos que esse usuário tenha permissão de sysadmin temporariamente, apenas para fazer uma configuração e depois podemos revogar esse acesso.
6. Volte  para o Servidor onde está o TFS abra o command do Visual Studio e rode o seguinte comando:

   TFSConfig ChangeServerID
   /SQLInstance:NM_Novo_Servidor_Onde_Esta_Sua_Base_De_Configuracao 
   /DatabaseName:TFS_Configuration(ou o nome que você deu para a sua base de configuração)
   

7. Depois de rearumar os IDs do novo servidor, para que não haja nada repetido, vamos registrar esse novo servidor no TFS, para isso execute o seguinte comando:

   TFSConfig PrepSQL
   /SQLInstance:NM_Novo_Servidor_Onde_Esta_Sua_Base_De_Configuracao
    

8. Com esse comando, estamos falando para o servidor do TFS que ele poderá usar esse novo servidor. Agora precisamos remapear a base de configuração, para isso, execute o seguinte comando:

   tfsconfig remapdbs
   /sqlinstances::NM_Novo_Servidor_Onde_Esta_Sua_Base_De_Configuracao
   /databasename:Tfs_Configuration

9. Agora, vamos arrumar o permissionamento das contas, para isso, execute o seguinte comando:

   TFSConfig Accounts
   /ResetOwner
   /SQLInstance:NM_Novo_Servidor_Onde_Esta_Sua_Base_De_Configuracao
   /DatabaseName: Tfs_Configuration
   

10. E para finalizar, vamos registrar esse banco de dados, para isso, digite o seguinte comando:

    tfsconfig RegisterDB
    /SQLInstance:NM_Novo_Servidor_Onde_Esta_Sua_Base_De_Configuracao
    /databasename:Tfs_Configuration
    

11. E pronto, agora o seu TFS está apontando para o novo servidor de banco de dados. Agora, para a felicidade do DBA, podemos revogar o acesso de sysadmin dado e deixar apenas como DB_Owner das bases do TFS.
12. Inicie novamente o IIS ou o site do TFS e o serviço de JOB do TFS
13. Entre no Console Administration e veja que o servidor já está apontando para o novo servidor de banco de dados. Agora só falta reconfigurar a(s ) das ProjectsCollections. Para isso selecione a project collection e clique para editar as configurações. Coloque no nome do novo servidor, salve e coloque a coleção on-line novamente. Faça isso para todas project collections que você tiver e pronto, sua migração estará completa.

Bom, esses são os passos necessários para a migração de servidor do SQL do TFS. Caso tenham alguma dúvida ou problema, deixe no comentário que responderei com o maior prazer.

Até a próxima.

Vamos lá, começando pelo básico. Para quem não pode copiar a máquina no dia do hands on ou quer uma versão digital do material dado, segue o link onde podem ser encontrados :

• Laboratórios e Máquina Virutal do Visual Studio ALM 2010
• Laboratórios e Máquina Virtual do Visual Studio VNext

Perfil  – Time de Desenvolvedores e Arquitetos:

• Lab 1 – Introdução ao Source Control:
  • http://msdn.microsoft.com/pt-br/library/ms181368.aspx – Link sobre source control no MSDN
  • http://social.msdn.microsoft.com/Forums/is/tfsversioncontrol/thread/85602e42-9c99-424c-9ed9-cebe883a847b – Thread no MSDN falando de como conectar versões antigas no TFS 2010.
• Lab 2 – Branch e Merge com Team Foundation Server 2010
  • Visual Studio Team Foundation Server Branching and Merging Guide – Esse é um guide escrito pelos Visual Studio ALM Rangers sobre algumas estratégias de Branch e Merge para as versões 2010 e já está disponível a versão beta do Vnext.
• Lab 3 – Customização de Workflow de Build
  • Team Foundation Build Customization Guide – Mais um guide dos Visual Studio ALM Rangers só sobre Team Build e como trabalhar com algumas customizações.
• Lab 4 – Depurando código com Intellitrace
  • Videos no Channel 9 sobre Intellitrace
• Lab 5 – Utilizando Code Analysis para Melhoria da Qualidade de Código
  • Video Channel 9
• Lab 6 – Code Discovery utilizando Architecture Tools
  • Doug Seven- Code Understanding and Systems Design with Visual Studio 2010
  • Entendendo Sistemas Existentes com Visual Studio 2010
  • Visual Studio Architecture Tooling Guide
• Lab 7 – Entendendo Acoplamento de Classes
  • Entendendo Sistemas Existentes com Visual Studio 2010
  • Visual Studio Architecture Tooling Guide
• Lab 8 – Utilizando o Architecture Explorer
  • Video Channel 9
  • Visual Studio Architecture Tooling Guide

Perfil – Líderes e Coordenadores :

• Lab 1 –Planejando Seus projetos com o TFS 2010
  • Planejando e acompanhando projetos
  • Proactive Project Management with Visual Studio 2010
  • Agile Planning Templates in Visual Studio Team System 2010
• Lab 2 – Acompanhamento da Qualidade
  • Acompanhamento de Bugs, tarefas e outros itens de trabalho
• Lab 3 – Utilizando Excel e Report Builder para Relatorios Customizados
  • Customização de relatórios no TFS 2010
  • Criação, personalização e gerenciamento de relatórios para ALM de Visual Studio

Perfil – Time de Qualidade e Testadores :

Links para o MSDN : Testando o aplicativo

Links que abordam o modelo completo :

• Tudo o que você precisa saber sobre testes no Visual Studio – Parte 1
• Tudo o que você precisa saber sobre testes no Visual Studio – Parte 2
• Tudo o que você precisa saber sobre testes no Visual Studio – Parte 3
• Lab 1 -Planejamento de Testes com o Microsoft Test Manager 2010
  • Introdução e visão geral sobre testes e qualidade na Plataforma Microsoft
  • Planejamento de testes com Test Manager 2010
  • Derrubando as barreiras entre testadores e desenvolvedores
• Lab 2 -Gerenciamento de Casos de Testes com o Microsoft Test Manager 2010
  • Gerenciando grandes volumes de teste em uma mesma solução
  • Tudo o que você precisa saber sobre testes no Visual Studio – Parte 3
• Lab 3 -Criando e Executando Testes Manuais com o Microsoft Test Manager 2010
  • Entendendo os testes manuais
  • Tudo o que você precisa saber sobre testes no Visual Studio – Parte 3
• Lab 4 -Testes Exploratórios com o Microsoft Test Manager 2010
  • Visual Studio Team System 2010: Exploratory Testing
  • Exploratory Testing
• Lab 5 -Testes em Diferentes Plataformas com o Microsoft Test Manager 2010
  • Tudo o que você precisa saber sobre testes no Visual Studio – Parte 3
• Lab 6 -Introdução a Coded UI com o Microsoft Visual Studio Ultimate 2010
  • Iniciando o uso dos testes de IU codificados
  • Building Robust, Maintainable Coded UI Tests with Visual Studio 2010
• Lab 7 -Ciclo de Correção de Bugs com o Microsoft Test Manager 2010
  • Tudo o que você precisa saber sobre testes no Visual Studio – Parte 3

Primeiro é onde vocês podem baixar  o Branch Guide dos ALM Rangers.

Nesse link ( Projetos dos ALM Rangers ), você pode encontrar todos os projetos que estão sendo desenvolvidos pela equipe, vale a pena dar uma olhada em tudo que estamos trabalhando e qualquer proposta nova ou problema encontrado não deixe de nos comunicar!

Mas especificamente sobre a minha palestra, segue o endereço do Visual Studio Team Foundation Server Branching and Merging Guide .

Outros pontos que não deram tempo de passar na palestra:

Melhores Práticas

• Usar nomes significativos para o Branch – Sempre que possível utilize nomes que realmente tenham algum siginifcado para o seu projeto. Isso parece um detalhe bobo, mas imagine a situação onde você está utilizando a estratégia por feature, e começa utilizando nomes não tão significantes. Com o andar do projeto, esse número de branches pode ficar alto e sem nomes significativos, pode começar a gerar problemas para a sua equipe, impossibilitando que ela saiba qual feature eles tem que trabalhar no momento.

• Sempre prefira Branch ao invés de code-freezen – Code-freezen é um dos ” porquês “ que queremos evitar. Então sempre que surgir uma situação onde a sua equipe de desenvolvimento tiver que ficar parada para que testes, deploys ou qualquer outra coisa que não seja desenvolver novos códigos, acertar bugs identificados em versões anteriores, pense em criar um branch. Isso já gera um valor para esse branch justificando a sua criação.

• Integre sempre que possível – Integrar sempre que possível tem que ser um mantra! deixar para fazer tudo na última hora, trazer as modificações geradas na main para o seu branch de trabalho apenas no final, pode gerar um tempo muito maior de resolução de conflitos e com isso impactar diretamente no seu prazo de entrega. Por isso, integre sempre, pelo menos 1 vez por semana, mais do que isso, você e sua equipe já estarão correndo riscos.

• Resolva conflitos no “Soft” branch – O Soft branch é onde você está desenvolvendo no momento, é o seu branch de desenvolvimento. Sempre resolva os comflitos nesse branch e nunca no que é considerado o mais estável, como o Main por exemplo. Isso que dizer que você antes de publicar alguma nova feature para a Main, baixa a versão do Main para a seu Branch de desenvolvimento resolva todos os conflitos e aí sim, faça a entrega para o Main.

• Evitar branches em cascatas – Tente evitar ao máximo o cascateamento nos branches, pois isso torna muito mais complicada a sua integração e trás um tempo muito maior para a liberação do seu código. Como vimos no início da palestra, isso vai impactar diretamente no custo de manutenção do branch, o que pode não trazer o valor esperado para o branch exigindo que a sua estratégia tenha que ser completamente revista.

• Isole a mudança – Isolar a mudança e não a equipe. Nós temos que isolar apenas  o que queremos modificar no nosso sistema sem impactar os outros membros do time e nunca isolar um grupo ou uma pessoa. Todos tem que saber o que está acontecendo no sistema e porque algum branch foi criado. Caso você comece a isolar as pessoas, você começará a criar silos na sua equipe o que trará muitos problemas para o seu projeto. TOME MUITO CUIDADO!

• Evitar Baseless Merge  – Como vimos, as vezes o Baseless Merge é necessário (Estratégia de Branch por Release com Mainline), mas tome cuidado com essa técnica, pois ela acaba abrindo caminhos novos caminhos para a release do seu sistema que podem forçar o seu código a não passar por áreas críticas e ser lançada uma versão sem todas as funcionalidades ou bugs que já foram corrigidos.

Anti-Padrões

• Merge Paranoia – Medo de realizar o merge entre dois branches. Se isso está acontecendo com o seu projeto, com certeza sua estratégia de branch não é a mais adequada para o seu problema. Pare agora e revise sua estratégia. Esse medo de realizar merges entre branches não pode existir.

• Merge Mania – Ao contrário da primeira, realizar merge todo o tempo também não é uma coisa boa. Esse item também sugere que a estratégia selecionada não está sendo a mais eficaz nesse momento para o seu projeto. Para um tempo e revise o seu modelo.

• Big Bang Merge – Deixar para fazer o merge apenas na última hora, na hora de realizar a liberação do código para Release. NUNCA FAÇA ISSO!

• Branch Mania – Um dos pontos para que um branch seja criado é descobrir qual o valor que ele trará para o projeto. Se ele não trouxer valor ou tiver alguma outra técnica que possa ser empregada no lugar, então não crie o branch! Cada branch que você criar, é mais uma complexidade que você está trazendo para a gestão do seu sistema. Por tanto, sair criando branches sem um bom motivo também é um problema.

• Branches Temporarios – Nunca crie branches para executar algum teste ou fazer pequenas alterações temporárias! Isso não trás valor para o seu projeto! para realizar esse tipo de tarefa, prefira usar shelve, com certeza ele vai resolver o seu problema e não trará complexidade desnecessária para o seu gerenciamento.

Escolhendo a sua estratégia

Esse não é um modelo único, porém é um ponto de partida para que você escolha qual estratégia de branch deve ser utilizada no seu projeto.

Utilize isso como um ponto de partida, mas adicione mais alguns pontos de validação para a sua decisão. Uma delas é, qual caminho que eu teria que percorrer para fazer a liberação do meu código ? Existe alguma compliance que eu devo seguir na minha empresa ? As vezes, como vimos na DEMO, teremos que utilizar mais de uma estratégia para atingir os objetivos que aquele projeto necessita.

Tenha em mente que cada projeto pode ter uma estratégia de branch diferente. Então sugiro que você tenha pelo menos 3 modelos padrões na sua empresa para projetos pequenos, projetos médios e um para projetos grandes ou críticos. Mas na hora de definir, faça uma simulação para validar se aquela estratégia não vai lhe trazer complexidade desnecessária.

Espero que tenham gostado da palestra e em caso de dúvidas, deixem seus comentários ou enviem por twitter ou e-mail.

Até a próxima!

Essas mesmas empresas também utilizam serviços internos como o Team Foundation Server para gerenciar seus projetos de desenvolvimento, independente da linguagem .NET, Java, Cobol, VB6 etc.

Nesse cenário surge a necessidade de integração entre alguns serviços internos com serviços externos. E como podemos fazer isso com o Team Foundation Server e o Gmail ?

Nativamente, não é possível passar informações de servidores e-mail, usuários e contas para autenticação, por isso temos que implementar uma funcionalidade do IIS, o SMTP Server, para criar um servidor virtual de SMTP e fazer ele “conversar” com o gmail, permitindo que o TFS envie seus alertas.

Para fazer isso, primeiro precisaremos instalar a feature do SMTP Server, para isso acesse o Server Manager, e selecione a feature do SMTP Server

Click em Next até chegar ao final da instalação. Depois de instalar, precisamos configurar o SMTP Server do IIS para isso, vamos acessar o IIS Manager abrir a Feature do SMTP E-mail

Na tela de configuração da Feature do SMTP E-Mail, deixaremos as opções padrões.

Agora precisamos configurar o nosso servidor virtual para conversar com o Gmail. Para isso, vamos acessar o IIS Manager 6.0

Ao abrirmos a console do IIS Manager 6.0, percebemos que o serviço está parado, então o primeiro passo é iniciar o serviço. Selecione o serviço ao lado direito e depois clique no botão iniciar (a figura igual ao botão play na barra superior)

Depois de iniciado, selecione o serviço e entre nas propriedades para começarmos as configurações

Na aba Access, vamos habilitar quais as máquinas vamos permitir que faça relay nesse servidor. Podem ser adicionadas máquina a máquina, uma rede válida ou um domínimo específico. No nosso exemplo, vou adicionar uma rede.

Agora na aba Delivery, acesse a opção Outbound Sercurity selecione a opção basic authentication e coloque o e-mail do gmail e a senha de acesso do e-mail. Tem que ser um e-mail válido. São com essas informações que o IIS realizará a conexão com o Gmail para enviar os e-mails de alerta. Importante não podemos esquecer de marcar a opção TLS Encryptation

No Outbound Connections precisamos alterar a porta de comunicação de TCP. Por padrão a porta é a 25, porém o gmail utiliza a porta 587

Por último, vamos na opção Advanced. Nessa tela vamos informar qual é o nome do nosso servidor virtual, tem que ser o nome do seu servidor que é conhecido na rede (nome + domínio)  e o smart host, precisamos informar qual é o smtp do gmail (smtp.gmail.com), conforme figura abaixo

Com isso, configuramos o Servidor de SMTP, agora vamos configurar os alertas do Visual Studio. Para isso, entre na console administration, selecione o application tier e role até a opção de configurar os alertas de e-mail.

Na opção SMTP Server, entre com o nome do servidor onde acabou de ser configurado o servidor de SMTP. No E-mail From Address coloque um endereço de e-mail, pode ser qualquer endereço.

Pronto, agora você pode gerar algum alerta no TFS que receberá o e-mail através do gmail configurada no passo 8.

Esse procedimento pode ser utilizado para qualquer servidor de e-mail externo que você possua um usuário válido ou se na sua empresa a porta padrão de conexão com o servidor de e-mail é diferente da padrão.

Com os Events Handlers, podemos fazer mais coisas além de verificação de comentários, podemos adicionar uma complexidade maior  que exigirá alguns testes prévios e debug.

Para debugar um Event Handler e facilitar a vida, vamos adicionar o output do projeto já para a pasta padrão do Team Foundation Server, com isso o nosso Event Handler já será publicado na área de instalação e começará a funcionar sem que seja necessárias nenhuma configuração a mais ou cópia de arquivos. Para isso acesse a propriedade do projeto

Na página de propriedades do projeto, vá para aba Build e vamos adicionar a propriedade Output Path para: C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\Plugins\

Feito isso, podemos mandar compilar o Event Handler que estamos trabalhando para que ele seja instalado.

Agora, para realizarmos um debug, vamos precisar atachar o processo do IIS que está rodando o TFS 2010. Para isso, vamos no menu Debug -> Attach Process

Irá aparecer uma lista de processos disponíveis. Procure o processo do IIS (w3wp.exe) que esteja rodando o .net framework 4.0 (caso no seu servidor possua outras aplicações no framework 4.0, você terá que identificar o processo por algum dos outros campos, o um exemplo, seria o User Name, que é o usuário que está rodando o TFS 2010)

Não esqueça de marcar a opção “Show processes in all sessions” para ver o processo do IIS. Caso você não encontre o processo do TFS, basta força uma “rodada” do TFS, para isso, vá no team explorer e dê um refresh. Isso fará que o processo “entre no ar” novamente. Feito isso, clique em Attach.

Para realizar o debug, abra uma nova IDE do VS2010, conecte no TFS e faça um check-in, com isso você poderá começar a debugar o seu código.

Espero que tenha ajudado e qualquer dúvida, não deixe de entrar em contato!

Até a próxima!

O primeiro post tinha que ser sobre essa experiência inicial que tenho tido com a empresa, não teria outra opção! Por que isso? Simples, a cultura da empresa realmente é muito diferente de outros lugares que eu já trabalhei. O pessoal aqui presa muito o trabalho em comunidade sempre incentivando que você vá e diga para todos as coisas que você vem realizando em clientes, aprendendo, que você compartilhe seu conhecimento.

Isso não é uma coisa muita comum, especialmente para empresas que vivem de consultoria como é o nosso caso, mas por ser orientada a comunidade, quando você não faz a sua parte, você se sente um peixe fora d’água.

Não falo isso com o sentido negativo, mas sim positivo, pois isso gera uma vontade, em nós “novatos” na empresa, em também querer fazer parte desse universo.

Essa é uma empresa que é realmente focada em comunidade e como até foi dito em um dos folhetos distribuídos em eventos: “… Nós realizamos consultorias de graça, publicando em nossos Blogs, falando em nossas palestras alguns feitos realizados … “. O texto em si não era exatamente esse, mas a idéia é essa, compartilhar todo o conhecimento sempre.

Isso ficou claro logo no início, quando em um trabalho para um cliente, conseguimos implementar uma customização que não tinha muita documentação e já foram e lançaram um post em como realizar aquela tarefa. E isso sempre contínua, sempre que apresento alguma coisa que desenvolvi para algum cliente vem a primeira pergunta: “Já publicou isso ?”.

Minha resposta, até hoje, era … “ainda não, vou escrever”. E finalmente agora comecei e espero não parar mais. Acho que agora realmente fui infectado por esse vírus de compartilhamento e entrei no clima da empresa.

Agora sobre o que vou escrever? Inicialmente irei estar bem focado na minha área de atuação que é ALM, porque é o  que eu trabalho aqui na Lambda, com o André Dias e o Igor Abade e fora dela no grupo dos Visual Studio ALM Rangers.

Isso vai permitir que eu exponha as experiências que venho vivendo com o Visual Studio 2010 nas consultorias da Lambda3 e as com o Visual Studio VNext através dos dois projetos que eu venho trabalhando (Microsoft Test Management Guide e Process Customization Guide).

Realmente espero poder contribuir muito com vocês e poder ajudar no que for preciso!

Agora sim, me sinto um Lambda por completo!

E até a próxima!