Veja nessa artigo como construir Build Scripts com automatizando processos no desenvolvimento de software. Nesse artigo será apresentado a ferramenta MSBuild usando tecnologia Microsoft .NET

O que são build scripts?

Build Scripts são basicamente blocos de código que exercem funções, tais como compilação de código ou criação de pacotes para implantação de sistema.

Qual e a necessidade de um Build script?

 automatizar processos e economizar tempo,impedindo trabalhos manuais. Para entender melhor, segue a lista de funcionalidades de Build Scripts, que são:

  • Limpar solução
  • Versionamento em geral, criando de forma automática o AssemblyInfo para evitar duplicações e auto-versão.
  • Execução de testes automatizados, cobertura de código e métricas de código
  • Geração de relatórios e notas de versão
  • Construção de arquivos de ajuda e documentação
  • Implantação automática para todos os ambientes: DEV, TEST ou PROD (Por convenção é dito que processos manuais estão sempre sujeito a erros, nas quais devem ser evitados em ambientes de produção por exemplo). E isso inclui aplicações Web, Desktop ou serviços (Windows service).
  • Criação de instaladores (ex: pacote MSI)
  • Além de serem executados localmente, Build Scripts podem ser executados em um Servidor de Integração Contínua (C.I = Continuous Integration)
  • Novas etapas podem ser adicionadas facilmente

Casos práticos

Muitas empresas possuem seu próprio jeito de atualização de sistemas, seja via processos manuais, por programação em lote (arquivos BAT), por Microsoft ClickOnce ou programas terceiros. Porém, o MSBuild consegue prover soluções flexíveis que conseguem gerar o mesmo resultado que essas outras ferramentas de forma mais simples.

Trabalhos manuais: Via Branch ou transformação de XML sempre está sujeito a erros. Há uma grande probabilidade de ser esquecido algo e o processo de atualização demorar mais do que necessário (Na grandeza de horas) em decorrência dessas falhas, sendo que tudo que esse processo pode ser facilmente convertido e automatizado por um BuildScript.

O que pertence a um Build Script?

Praticamente tudo que pode ser feito via interface.

Como exemplo, será criado um Build Script que é identificado como um arquivo XML. Esse XML segue o schema do http://schemas.microsoft.com/developer/msbuild/2003. Que por sua vez é usado para construir os arquivos (.csproj|.vbproj) ou seja, os projetos são nada menos que BuildScripts.

Resumo dos BuildScripts que serão apresentados:

Primeiro Build Script – FirstBuildScript.build

  1. Limpar, preparar e compilar a solução.
  2. Execução de testes unitários usando NUnit
  3. Criação de pacotes para o uso na implantação/deploy.
  4. Implantação Automática de uma aplicação Web usando o Microsoft Web Deploy.

Segundo Build Script – WindowsService.build

  1. Parar o Windows Service
  2. Atualizar utilizando o novo pacote
  3. Iniciar o Windows Service

Apresentação do primeiro Build Script – FirstBuildScript.build

Para rodar o Script é necessário de um projeto ASP.NET qualquer.

O Build Script que será chamado de FirstBuildScript.build
Toda a explicação está localizada na Listagem 1, que representa um arquivo XML. As explicações encontram-se nos comentários.


<?xmlversion="1.0"encoding="utf-8" ?>

<!--Criando um projeto para o MSBuild. É necessário passar o schema

usado e também qual será o valor padrão para ser executado.

(Explicação logo abaixo)-->

<Projectxmlns="http://schemas.microsoft.com/developer/msbuild/2003"

ToolsVersion="4.0"DefaultTargets="Deploy">

<!--ItemGroup representa as variáveis globais

no arquivo de Build-->

<ItemGroup>

<!--É possível gerar o nome que quiser, No caso será criado as variáveis:

BuildArtifacts = Pasta que conterá os arquivos compilados

SolutionFile = Arquivo de solução do projeto-->

<BuildArtifactsInclude=".buildartifacts"></BuildArtifacts>

<SolutionFileInclude=".MySolution.sln"></SolutionFile>

</ItemGroup>

<!--Esse ItemGroup será usado só para declarar as variáveis em

relação a Testes, que no caso será usado o NUnit.

Essa pasta ThirdyParty Precisa ser criada na raiz do projeto,

No nosso exemplo foi colocado apenas o NUnit e também

o Microsoft Web Deploy V3-->

<ItemGroup>

<NunitInclude=".ThirdyPartyNUnit-2.6.3binnunit-console.exe">

</Nunit>

<TestAssemblyInclude=".buildartifactsMySolutionWeb.Tests.dll">

</TestAssembly>

<TestResultsInclude=".buildartifactsTestResults.xml">

</TestResults>

</ItemGroup>

<!--

Variáveis responsáveis pelo Deploy, basicamente será preciso

dos seguintes itens:

msdeploy.exe

O arquivo do package resultante da execução do msdeploy.exe

Localização do Site, que é construido à partir do Build do MSBuild.

-->

<ItemGroup>

<MsDeployInclude=".ThirdyPartyMicrosoft Web Deploy V3msdeploy.exe">

</MsDeploy>

<WebSiteInclude=".buildartifacts_PublishedWebsitesMySolutionWeb">

</WebSite>

<PackageFileInclude=".buildartifactspackageMySolutionCityWeb.zip">

</PackageFile>

</ItemGroup>

<!--É possivel trocar de Debug para Release com uma PropertyGroup-->

<PropertyGroup>

<!--Caso não for passado nenhum parâmetro chamado Configuration,

ele será atribuido para Debug automaticamente.

Para acessar as PropertyGroup é necessário o uso de $ ao invés de @-->

<ConfigurationCondition=" '$(Configuration)' == '' ">

Debug

</Configuration>

</PropertyGroup>

<!--Targets são blocos de códigos para serem executados

É possível encara-los como se fossem métodos-->

<TargetName="Clean">

<RemoveDirDirectories="@(BuildArtifacts)"></RemoveDir>

</Target>

<TargetName="Init"DependsOnTargets="Clean">

<MakeDirDirectories="@(BuildArtifacts)"></MakeDir>

</Target>

<TargetName="Compile"DependsOnTargets="Init">

<!--

BuildArtifacts faz parte das variáveis globais.

Essas variáveis possuem propriedades.

Uma dessas propriedades é o FullPath

Para acessar as propriedades ao invés de usar @ é usado %

%(BuildArtifacts.FullPath) =>

C:SlipmpMySolutionbuildartifacts

O MSBuild aceita algumas propriedades como parâmetro, exemplos:

OutDir=Diretório de saída para o build

Configuration=Modo de compilação (Debug, Release, etc)

-->

<MSBuildProjects="@(SolutionFile)"Targets="Rebuild"

Properties="OutDir=%(BuildArtifacts.FullPath);

Configuration=$(Configuration)"></MSBuild>

</Target>

<!--Executando os testes usando NUnit-->

<TargetName="Test"DependsOnTargets="Compile">

<ExecCommand="@(NUnit) @(TestAssembly) /xml=@(TestResults)">

</Exec>

</Target>

<!--Esse target será responsável pela criação do package

que por sua vez será usado para o deploy no IIS-->

<TargetName="Package"DependsOnTargets="Clean;Init;Compile;Test;">

<PropertyGroup>

<!--RootDir contém apenas a letra do disco rígido.

Directory possui o endereço completo com exceção da letra

do disco rígido.

É necessário passar dessa maneira.-->

<PackageDir>

%(PackageFile.RootDir)%(PackageFile.Directory)

</PackageDir>

<Source>%(Website.FullPath)</Source>

<Destination>%(PackageFile.FullPath)</Destination>

</PropertyGroup>

<MakeDirDirectories="$(PackageDir)"></MakeDir>

<ExecCommand='"@(MsDeploy)" -verb:sync -source:iisApp="$(Source)"

-dest:package="$(Destination)"'>

</Exec>

</Target>

<!--Agora que o arquivo MySolutionWeb.zip foi criado (pacote completo

da aplicação), é necessário instala-lo de forma automática.

E para isso será preciso que o servidor que receberá a aplicação possua

instalado o Microsoft Web Deploy.

Link de download :

http://www.microsoft.com/web/downloads/platform.aspx

O nome da ferramenta é "Web Deployment Tool" ou em português

"Ferramenta de implantação da Web"

Após a instalação no servidor é necessário verificar se o

Serviço do Windows responsável pelo Web Deploy está rodando.

Nome em português: Serviço do Agente de Implantação da Web

Nome em inglês: Web Deployment Agent Service

Também será necessário criar um novo site no IIS para

receber nossa aplicação. No caso o site se chamará MySolutionWeb

e estará apontando para um diretório físico vazio dentro da pasta inetpub.

Quando o Build Script for executado os arquivos serão copiados para
esse diretório.

-->

<TargetName='Deploy'DependsOnTargets='Clean;Init;Compile;Test;Package'>

<PropertyGroup>

<Source>%(PackageFile.FullPath)</Source>

</PropertyGroup>

<!--Essa linha de código usa o arquivo zip gerado pelo próprio

MSDeploy no target de "Package" e implanta esse pacote no IIS

em um site chamado MySolutionWeb-->

<ExecCommand='"@(MsDeploy)" -verb:sync -source:package="$(Source)"

-dest:iisApp=MySolutionWeb'></Exec>

</Target>

</Project>

 

Apresentação do segundo Build Script – WindowsService.build

O segundo BuildScript apresentado na Listagem 2 é um exemplo de implantação automática de um Serviço Windows (Windows Service).

Listagem 2. Arquivo XML WindowsService.build

 


<?xmlversion="1.0"encoding="utf-8"?>

<!--Declaração do Projeto MSBuild-->

<Projectxmlns="http://schemas.microsoft.com/developer/msbuild/2003"
DefaultTargets="StopService;Deploy;StartService;">

<!--As seguintes variáveis devem ser criadas em um ItemGroup:

ServiceName

DestinationHost

DestionationFolder

CopyFiles-->

<!--Importação de algumas extenções do MSBuild-->

<ImportProject="$(MSBuildExtensionsPath)ExtensionPack
MSBuild.ExtensionPack.tasks"/>

<ImportProject="$(MSBuildExtensionsPath)MSBuildCommunityTasks
MSBuild.Community.Tasks.Targets"/>

<!--Target responsável por parar o Serviço - Essa é a sintaxe para
encerrar um Serviço Windows-->

<TargetName="StopService">

<MSBuild.ExtensionPack.Computer.WindowsServiceServiceName
="$(ServiceName)"MachineName="$(DestinationHost)"TaskAction="Stop"/>

</Target>

<!--Target responsável por copiar os arquivos para o Windows Service.

É recomendado que faça o Clean do diretório primeiro, conforme
o Primeiro BuildScript apresentado -->

<TargetName="Deploy">

<CreateItemInclude="..$(ArtifactPath)**" >

<OutputTaskParameter="Include"ItemName="CopyFiles"/>

</CreateItem>

<!--Sintaxe para copiar os arquivos-->

<Copy

SourceFiles="@(CopyFiles)"

DestinationFiles="@(CopyFiles->'\$(DestinationHost)
$(DestinationFolder)%(RecursiveDir)%(Filename)%(Extension)')" />

</Target>

<!--Sintaxe para Iniciar o serviço windows (Windows Service)-->

<TargetName="StartService">

<ServiceControllerServiceName="$(ServiceName)
"MachineName="$(DestinationHost)"Action="Start" />

</Target>

</Project>

 

Executando o Build Script

Utilize o command prompt do Visual Studio para executar o Build Script (Developer Command Prompt for VS2013), caso seja utilizado o command prompt padrão do Windows, será necessário especificar o caminho do MSBuild ao executá-lo. Segue o comando para abri-lo:

%comspec% /k “%PROGRAMFILES(X86)%Microsoft Visual Studio 12.0Common7ToolsVsDevCmd.bat”

Após localizar o diretório onde está localizado a solução, execute o seguinte comando:

msbuild FirstBuildScript.build

Caso deseje executar um Target especifico essa é a sintaxe:

msbuild FirstBuildScript.build /target:Clean

 

Referências

Link para o Microsoft Web Platform:

http://www.microsoft.com/web/downloads/platform.aspx

Link oficial do Microsoft MSBuild:

http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx

 

Conclusão

O Uso do MSBuild é extremamente poderoso, juntando isso com um Servidor
de C.I é possível construir um ambiente de desenvolvimento totalmente automático.

Crie os targets um de cada vez, sendo primeiro os Targets (Clean, Init e Compile) e após isso adicione Build Steps de acordo com a necessidade.

É isso ai, muito obrigado e Abraços!