Concrete Logo
Hamburger button

(2+2) Integração Continua com .NET (fazendo na mão) – Parte 1 de 3

  • Blog
  • 28 de Fevereiro de 2013
Share

“Change does not roll in on the wheels of inevitability, but comes through continuous struggle. And so we must straighten our backs and work for our freedom. A man can’t ride you unless your back is bent.”

Martin Luther King Jr

Este post vai parecer antiquado para quem conhece bem os produtos para desenvolvimento da Microsoft, ainda mais considerando o Visual Studio 2012 (e TFS 2012).

Se você trabalha com o framework 2012, em particular a partir da versão Premium, minha dica é o livro de um fellow trainer da scrum.org, Richard Hundhausen.

O livro aborda questões de Engenharia de Software e das ferramentas MS dentro do contexto de um projeto Scrum de uma forma bem completa.

Ainda assim, você pode estar em um projeto mais antigo, não ter acesso a alguma ferramenta específica, trabalhar com uma versão abaixo da Premium, etc. O que estou escrevendo aqui foi útil para mim, e acho pode ser útil para você, mesmo que você só utilize parte disso.

Se você tiver uma ideia melhor, mande no seu comentário para podermos evoluir o artigo.

  1. Configurações de Projeto
  2. Nos projetos do VS 2008 o Configuration Manager não facilita a substituição de arquivos de configuração para cada ambiente. Algo que o VS já faz sozinho.
    Para isso, cada membro do seu time pode criar um arquivo próprio de configuração.

    No meu caso, eu criei a configuração LOCAL_VO.

    Clique em Configuration Manager para criar a sua…

    EnterConfigurationManager

    NewConfigurationManager

    LocalVoceConfigurationManager

    Com sua configuração criada, você pode criar um arquivo de configuração seu, por exemplo, chamado de Web.LOCAL_Voce.config. Em seguida, coloque nos Pre-build events uma tarefa para copiar este arquivo sobre o arquivo de configuração do projeto.

    É interessante acrescentar os arquivos Web.config, App.config, etc ao seu .ignore do controle de versão (*Web.config), de forma que apenas os arquivos de cada ambiente façam parte do seu repositório. Isso vai te economizar muitos merges.

    PreBuildEvent

    Note que neste passo eu utilizei o comando cp do CygWin.

    O motivo para essa manobra (além de outras facilidades do CygWin citadas mais adiante) são as limitações do copy e do xcopy do windows para confirmações de sobreescrita, ou quando o arquivo de destino ainda não existe. Você também pode criar o seu próprio copy com um script em batch. Eu preferi usar o cp.

    O comando completo deve ficar algo parecido com: "cp" -Tuv "$(ProjectDir)config\Web.$(ConfigurationName).config" "$(ProjectDir)Web.config"

    Antes de prosseguir, verifique se você ainda consegue rodar o seu projeto no Visual Studio.

    Para finalizar a parte do Visual Studio, segue mais um truque.

    Quando estivermos executando o nunit, ao rodar apontando para toda a Solution e não apenas o projeto de testes, o nunit vai procurar na raiz da Solution um arquivo de config com o nome da solution.

    Como solução, acrescente ao post-build do seu Projeto de Testes a cópia da configuração para a raiz da Solution.

    PostBuildTeste

    Esta cópia fica algo como:"cp" -Tuv "$(ProjectDir)config\App.$(ConfigurationName).config" "$(SolutionDir)$(SolutionName).config"

    Na parte 2: configurando o seu Jenkins para rodar na sua máquina local.

    Na parte 3: configurando o seu Jenkins para rodar na máquina de DEV (1o ambiente integrado).