Uma das primeiras perguntas do teste do Joel é saber se você pode compilar todo o projeto em apenas um passo. Essa é uma questão essencial e um desafio para muitas equipes. Perdem-se horas sagradas para gerar um novo Release.
Compilação automática geralmente está disponível nas ferramentas de desenvolvimento. Se você estiver usando o Visual Studio, por exemplo, é possível fazer isso com uma linha:
devenv minha-solução.sln /Rebuild Release
Se não for exatamente o que você precisa, basta fazer uma pesquisa de quinze minutos e encontrar os parâmetros corretos. O objetivo é: eu rodo esse comando em cima do projeto inteiro em uma máquina zerada e ele simplesmente compila.
Múltiplas soluções
É lógico que ter apenas um solution/workspace para guardar projetos médios e grandes é inviável. Demora para carregar no ambiente e possuem dezenas de dependências. Isso já foi tentado duas vezes nas duas empresas em que trabalhei e não funcionou. Talvez por isso seja necessário criar um script que rode o comando acima para todas as soluções do projeto, o que não muda muito o modus operandi da coisa:
call :Build ..\Libraries\Libraries.sln call :Build ..\Services\Services.sln call :Build ..\Drivers\Drivers.sln call :Build ..\Tools\Tools.sln goto :eof
:Build echo %1... devenv "%1" /Rebuild Release exit /b %errorlevel%
Note que meu script usa a estrutura padronizada dos diretórios de um projeto, onde cada tipo de componente tem sua pasta e solução.
Aos poucos você pode ir colocando "frescurinhas" em seu build (executa Debug e Release, roda automatizado no servidor, faz testes unitários, incrementa o número da versão, ...), mas algumas premissas sempre se mantêm:
- Deve ser possível compilar o projeto inteiro em um passo
- Deve ser possível usar qualquer máquina de desenvolvimento para isso
Regras simples de ser seguidas se você usar sempre a máxima do KISS.
May 25th, 2009 at 9:35 am
Caloni,
A coisa complica mesmo é quando existem passos a fazer além de compilar/linkar. Lembro vagamente de um arquivo batch rodando no DOS (nos bons tempos) que além de tudo ainda gravava um relatório de geração de versão. Em tempos mais recentes eu usava o MAKE. A partir do VS2005 a Microsoft passou a usar uma nova ferramente, o MSBuild. O único problema é que ele é controlado por um arquivo XML ao invés de um script tradicional. Taí uma sugestão para você: uma série de posts estudando o MsBuild.
Momento "grammar nazi": não seria "Perdem-se horas sagradas..." ?
[]
Daniel Quadros
May 25th, 2009 at 12:36 pm
Olá, DQ.
Então, não costumo usar o MSBuild nem o MAKE. De certa forma ainda não encontramos vantagens suficientes para tamanha "complexidade" maior do que uma batch de 20 linhas. No entanto, estou pensando em adicionar alguns problemas a mais na hora do build que tivemos em vários momentos que "automatizar era preciso".
Ah, atualmente usamos apenas o Cruise Control como servidor de build.
[]s
PS: Obrigado pela correção. Fui pego pelo "erro da tabuleta".
May 26th, 2009 at 4:47 pm
Aqui na empresa, nós criamos alguns builds em Python que com diretorios bem padronizados conseguimos fazer inclusive vários níveis de build, como pré-submit, integração continua e release build tudo isso executando um arquivo .py diferente.
Acredito que usar arquivos .bat não é uma boa solução (e nós já usamos por muito tempo), Python é a mais flexível, mas tem que tomar cuidado pra não deixar a coisa virar uma zona.
Um produto bom é o Visual Build (http://www.kinook.com), para sistemas de builds pequenos/medios ele é excelente. Já para builds de grande porte, pode não ser uma boa já que ele não permite o que, em alguns casos, dificulta o reaproveitamento dos scripts.
Mas o mais importante para qualquer bom sistema de build é a padronização de diretórios. Sem isso, fica difícil fazer um sistema de build e principalmente, reaproveitar para usar em outros projetos.
Por aqui, para integração continua usamos o QuickBuild, já usamos antes o CruiseControl, mas acabamos usando o QuickBuild por ele ser mais organizado, ser menos XMLizado (inventando termos do nada....) e mais bonitinho. Eu sou doido pra usar o Cruise (a versão paga do CruiseControl) mas ainda não achei justificativas pra substituir o QuickBuild por ele.
Bom, chega... se não eu escrevo um outro artigo como comentário...
June 2nd, 2009 at 8:10 am
Sem dúvida Python é mais flexível. Como meu tempo não é, então optamos por uma simples batch de 20 linhas que resolve o problema de compilar tudo.
[]s