Otimizando seu build usando o MSBuild
O tópico de hoje não está realmente relacionado à liderança, ou ser um líder de equipe, mas achei que este post pode ser útil para você, além do meu eu futuro, pois às vezes costumo esquecer as coisas. Como você deve ter adivinhado no título, o tópico é otimizar o MSBuild para que eles sejam executados mais rapidamente e levem menos tempo. Então, sem mais deduções, vamos entrar nisso.
Processamento multi-core
/m Interruptor
Praticamente todas as máquinas hoje têm mais de um núcleo. Como todos sabem, ter vários núcleos permite que as tarefas sejam executadas em paralelo e o MSBuild também possui suporte integrado para isso.
Para usar vários núcleos durante o build, tudo o que você precisa é passar a opção /m para o MSBuild. Por exemplo
MSBuild.exe _project.msbuild /m /p:Platform="Any CPU"
Quando essa opção é usada, o MSBuild gerará vários MSBuild.exe que lidarão com parte do processo de build, diminuindo assim o tempo real de build.
Construir em paralelo Interruptor
Há outra opção, que está intimamente relacionada à acima, é a opção BuildInParallel. Isso só pode ser usado em conjunto com a opção /m e sua finalidade é criar vários projetos em paralelo, por instância do MSBuild. Um exemplo disso é o seguinte:
MSBuild.exe _project.msbuild /m BuildInParallel="True" /p:Platform="Any CPU"
Resumo detalhado Interruptor
O MSBuild tem uma boa opção que mostra um resumo do processo de compilação, incluindo o tempo necessário para compilar o projeto. Você pode habilitar isso usando a opção /detailedsummary, da seguinte maneira:
MSBuild.exe _project.msbuild /m /detailedsummary /t:Build
A saída do switch é a seguinte:
Na imagem acima, a coluna Id à esquerda é a ID do projeto que está sendo construído. Você pode ver que existem linhas verticais abaixo dos Id’s, que representam dependências. Portanto, para compilar o projeto 0, o MSBuild precisava compilar o projeto 1, que, por sua vez, precisava compilar 18,37,38 e assim por diante. A coluna Tempo Exclusivo é a quantidade de tempo necessária para criar esse projeto específico e a coluna Tempo Total é o tempo necessário para criar o projeto, bem como todas as suas dependências. Por fim, o caminho é apenas o local do arquivo de projeto que está sendo criado.
Como você pode ver, isso pode fornecer alguma orientação sobre quais projetos são lentos para serem construídos, para que você possa se concentrar neles primeiro.
Arquivos de links rígidos
Se você achar que seu build tem muita E/S de disco, pois está copiando a saída dos projetos para todos os tipos de diretórios, convém usar os recursos de vinculação forçada do MSBuild.
A vinculação física é simplesmente uma maneira pela qual um único arquivo pode ser “referenciado” por vários caminhos. Gosto de pensar nisso como um apelido para um arquivo. Se você habilitar esse recurso no MSBuild, os arquivos não serão copiados fisicamente, mas, em vez disso, farão referência a arquivos existentes, ignorando assim a parte de E/S e potencialmente economizando um pouco de tempo. Apenas por interesse, você pode medir a E/S do disco usando o ProcMon e filtrando os resultados no msbuild.exe e, em seguida, criando um Resumo do Arquivo no menu Ferramentas.
Os quatro tipos de links rígidos disponíveis no MSBuild são os seguintes:
- CreateHardLinksForCopyLocalIfPossible
- CreateHardLinksForCopyFilesToOutputDirectoryIfPossible
- CreateHardLinksForCopyAdditionalFilesIfPossible
- CreateHardLinksForPublishFilesIfPossible
Um exemplo de como eles seriam usados são os seguintes:
MSBuild.exe _project.msbuild /p:CreateHardLinksForCopyLocalIfPossible=true; CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true; CreateHardLinksForCopyAdditionalFilesIfPossible=true; CreateHardLinksForPublishFilesIfPossible=true;^
Em nosso cenário, passamos de cerca de 2 GB de E/S de disco para cerca de 250 MB, o que pode fazer uma grande diferença.
Itens Diversos
Também fizemos algumas coisas menores, como configurar a solução para não criar projetos de teste para compilações de versão. No entanto, ainda temos isso feito para nossas compilações de check-in / diário, etc.
A partir do relatório de resumo detalhado que mencionei acima, vimos que algumas de nossas tarefas pós-compilação também estavam levando um tempo significativo, então as otimizamos.
Com todas as mudanças acima que fizemos, conseguimos reduzir bastante nosso tempo de construção. Se você tiver outras coisas que descobriu que ajudaram a melhorar seu tempo de construção, deixe-as na seção de comentários abaixo.
Até a próxima… Continue aprendendo!