ti-enxame.com

Qual a importância das compilações diárias?

Um dos critérios do Teste de Joel são compilações diárias. A ideia é que se o build estiver quebrado, quem o quebrou está por perto para consertá-lo. Se a compilação não puder ser corrigida, todos terão que verificar uma versão antiga e trabalhar nela. Eu posso entender como isso pode ser muito ruim no controle de versão centralizado, onde é importante evitar a fusão e ramificação, tanto quanto possível, mas isso soa apenas como um pequeno incômodo para o controle de versão distribuída. Você concorda com isso? Existem outras razões pelas quais as compilações diárias são importantes?

21
Casebash

Acho que o que é importante notar aqui é que compilações regulares ajudam detectar erros mais cedo ou mais tarde. Não tem para ser diário, mas com freqüência suficiente. Idealmente, ele também pode executar seus testes de unidade.

O objetivo é descobrir quando um build é interrompido antes da fase final de teste, para encontrá-los o mais rápido possível.

Basta configurá-lo para construir seu (s) branch (s) principal (is) de desenvolvimento.

Nós o usamos no trabalho (embora construamos de hora em hora), e freqüentemente, quando nos esquecemos de configurá-lo, encontramos problemas poucas horas antes do lançamento.

19
mbillard

É preciso adicionar um pouco a isso (e @GoodEnoughs):

mas isso soa apenas como um pequeno incômodo para o controle de versão distribuída.

Enfaticamente não - o que uma construção de "servidor" faz é dizer a você que seu tronco irá construir e passar nos testes mais ou menos limpo (menos é a quantidade de configuração que você precisa fazer em seu ambiente).

Estou pensando em mudar para DVCS, mas mesmo tendo feito isso, você vai arrastar minha integração contínua de minhas mãos frias e mortas.

Para dar um exemplo simples - você está desenvolvendo o recurso "a", ele está desenvolvendo o recurso "b" distribuído ou não em algum ponto, você precisa juntar tudo - se, ao fazer o commit, esquecer de adicionar um arquivo que o aplicativo irá construir em sua máquina, mas não em nenhum outro lugar. Então, quando você enviar o build para o seu "tronco", a Integração Contínua irá disparar e o build irá falhar e você saberá e com sorte antes qualquer um puxar seu código não tão completo que você será capaz de pegar passos.

Se você está trabalhando em um projeto com vários desenvolvedores, precisa ser capaz de definir de onde vêm as versões de lançamento - o tronco em vigor - isso é verdade independentemente de como funciona o controle de versão.

Se você adicionou um recurso - especialmente um do qual outras pessoas têm uma dependência - ser capaz de ter certeza de que, quando for colocado "ao vivo", será criado e aprovado nos testes em outro lugar que não o seu ambiente de desenvolvimento. Mais do que isso, eu implanto a partir de compilações do meu servidor de compilação - é como se especifica a compilação "definitiva". Em última análise, terei compilações de implantação acionadas pelo usuário. Não é bom dizer que você pode contornar isso - você não pode, se precisar (e eu tenho mexido em caixas de desenvolvimento em um escritório para encontrar e enviar arquivos perdidos).

Isso tudo é um pouco forte? Não sei - mas meu servidor de compilação é uma daquelas coisas que não tenho desejo de retribuir.

5
Murph

As compilações diárias são muito importantes. Se você tem uma equipe distribuída em fusos horários diferentes, é melhor encontrar um horário que seja aproximadamente o 'fim do dia' para a maioria da equipe. Além disso, se as compilações diárias tiverem um componente de teste automatizado, é mais desejável.

Na época dos sistemas de controle de origem central, eu recomendaria compilações contínuas rodando a cada 5-10 minutos, quando algo é alterado no código-fonte. Já que um erro de compilação tem o potencial de desacelerar a maioria da equipe. Para organizações que executam sistemas de controle de origem distribuídos, uma construção contínua pode não ser tão necessária, uma vez que os desenvolvedores tocam a base de código 'primitiva' diretamente com menos frequência.

4
khivi

As compilações diárias estão bem. Você definitivamente precisa deles se não tiver mais nada além de ser honesto, acho que o teste de Joel está um pouco desatualizado atualmente.

Na minha opinião, você deve estar construindo continuamente ao longo do dia, executando seus casos de teste de nível de unidade, sistema e funcional e, idealmente, empacotando e implantando em um ambiente semelhante a um estágio ao mesmo tempo, enquanto verifica se quaisquer mecanismos de controle de versão de ambiente e banco de dados que você possui estão funcionando conforme o esperado.

Se os tempos de construção ou implantação forem excessivos, considere otimizar alguns desses problemas com discos RAM físicos ou de software, conexões de internet mais rápidas, paralelização de compilações, etc. .

2
Keith Brings

As compilações diárias não são importantes. Builds diários que sempre são bem-sucedidos são (ou aqueles em que só quebram por uma hora). Ter CI quando a compilação está quebrada 70% das vezes não é muito útil, porque se a coisa estiver quase sempre quebrada, isso não ajuda a identificar um erro.

2
anon

Acho que deve ser feito diariamente, teste e implante no servidor de teste.

A ideia por trás da 'construção diária' é sempre ter algo pronto que os testadores e gerentes de projeto possam executar, para que todos tenham uma ideia de qual é o estado real do projeto.

No passado, com aplicativos de desktop após a 'compilação diária', um testador ou gerente de projeto pode executar o aplicativo imediatamente, portanto, nenhuma etapa de implantação precisava ser mencionada.

1
Sarel Botha

Idealmente, a menos que você esteja construindo algo enorme que leva mais de meio dia para construir, você construiria mais de uma vez por dia. Depois de configurar um servidor de integração contínua, como Hudson ou TeamCity , as compilações acontecerão automaticamente, normalmente a cada hora ou a cada commit, e você será notificado se houver algum problema.

É uma boa maneira de detectar erros antecipadamente, especialmente se você também estiver executando testes automatizados como parte da construção. É particularmente útil para localizar erros de configuração onde a construção funciona na máquina de um desenvolvedor, mas não funciona em outro lugar porque algo foi omitido do repositório ou do ambiente.

Os servidores de integração contínua mais avançados também permitem que você rastreie as métricas ao longo do tempo (por exemplo, porcentagem de cobertura de código, tempo de construção, linhas de código, etc.)

1
Dan Dyer