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

Um dos critérios do teste Joel é compilações diárias. A idéia é que, se a compilação for quebrada, quem a quebrou estará por perto para consertá-la. 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 parece apenas um pequeno incômodo para o controle de versão distribuído. Você concorda com isso? Existem outras razões pelas quais as compilações diárias são importantes?

Acho importante observar aqui que as compilações regulares ajudam a detectar erros mais cedo ou mais tarde . Não precisa ser diário, mas com bastante frequência. Idealmente, ele também pode executar seus testes de unidade.

O objetivo é descobrir quando uma construção é interrompida antes da fase final do teste, para encontrá-lo o mais rápido possível.

Basta configurá-lo para criar seus principais ramos de desenvolvimento.

Usamos no trabalho (embora construamos a cada hora) e, muitas vezes, quando esquecemos de configurá-lo, encontramos problemas apenas algumas horas antes da liberação.

Precisa adicionar um pouco a isso (e @GoodEnoughs):

mas isso parece apenas um pequeno incômodo para o controle de versão distribuído.

Enfaticamente não - o que uma compilação de "servidor" faz é dizer que seu tronco construirá e passará seus testes mais ou menos a partir da limpeza (menor é a quantidade de configuração que você precisa fazer no seu ambiente).

Estou pensando em mudar para o DVCS, mas mesmo tendo feito isso, você arrastará minha integração contínua das 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 momento, é necessário juntar tudo - se, ao confirmar, você esquecer de adicionar um arquivo que o aplicativo criará na sua máquina, mas não em nenhum outro lugar. Portanto, quando você envia a compilação para o seu "tronco", a integração contínua será acionada e a compilação falhará e você saberá, esperançosamente, antes que alguém insira seu código não tão completo, você poderá executar as etapas.

Se você estiver trabalhando em um projeto com vários desenvolvedores, poderá definir de onde vêm as versões - o tronco em vigor - isso é verdade independentemente de como o controle de versão funciona.

Se você adicionou um recurso - especialmente um do qual as outras pessoas dependem - para ter certeza de que, quando pressionado para "viver", ele cria e passa nos testes em outro lugar que não o seu ambiente de desenvolvimento é enorme. Mais do que isso, implanto a partir de compilações do meu servidor de compilação - é o tipo de como se especifica a compilação "definitiva". Por fim, terei compilações de implantação acionadas pelo usuário. A sua não é bom dizer que você pode trabalhar em volta dele - você não pode se você precisar dele (e eu ter mexidos caixas dev redondos em um escritório para encontrar e comprometer os arquivos ausentes).

Tudo isso é um pouco forte? Não sei - mas meu servidor de compilação é uma daquelas coisas que, após obter, não desejo retribuir.

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

Nos dias dos sistemas de controle de fonte central, eu defendia as compilações contínuas em execução a cada 5 a 10 minutos, quando qualquer coisa é alterada no código-fonte. Como um erro de compilação pode diminuir a velocidade da maioria da equipe. Para organizações que executam sistemas de controle de origem distribuído, uma compilação contínua pode não ser necessária, pois os desenvolvedores tocam a base de código 'primitiva' diretamente com menos frequência.

Idealmente, a menos que você esteja construindo algo maciço que leve 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 ocorrerão automaticamente, geralmente a cada hora ou em cada confirmação, e você será notificado se houver algum problema.

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

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

Compilações diárias estão bem. Você definitivamente precisa deles se não tiver mais nada, mas para ser sincero, acho que o teste de Joel está um pouco ultrapassado atualmente.

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

Se os tempos de compilação ou implantação forem excessivos, considere otimizar alguns desses problemas com discos ram físicos ou de software, conexões mais rápidas à Internet, compilações paralelizadas etc. O tempo que você economizará ao identificar rapidamente as quebras de compilação irá amaatizar o custo do hardware rapidamente .

Compilações diárias não são importantes. Compilações diárias que sempre são bem-sucedidas são (ou aquelas em que é interrompida apenas por uma hora). Ter o IC quando a construção é interrompida 70% das vezes não é muito útil, porque se a coisa é interrompida principalmente, não ajuda a identificar um erro.

Acho que deve ser compilado, testado e implantado diariamente no servidor intermediário.

A idéia 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 do estado real do projeto.

No passado, com aplicativos de desktop após a 'compilação diária', um testador ou gerente de projeto pode executá-lo imediatamente, para que nenhuma etapa de implantação tenha que ser mencionada.