Você não odeia quando algo quebra a construção de seu software? Os problemas de construção criam trabalho extra, não planejado. Eles parecem sempre acontecer quando você está correndo para resolver algum outro problema. Muitas vezes, a construção quebra por algum fator que não está relacionado a nada que você esteja fazendo no momento. Portanto, pode ser um pouco frustrante ter que largar o que você está fazendo, cavar o que causou a quebra da construção, consertar o problema e reiniciar a construção (esperando que você tenha apenas um problema para resolver).
Encontrei esta edição hoje, enquanto reconstruía alguns pacotes de código aberto. Há alguns meses, atualizamos nossa cópia do OpenSSL para a versão 1.0.0, mas não reconstruímos todos os pacotes que dependem dele. Acontece que, quando fui reconstruir o cliente subversion para pegar uma correção de bug, descobri que a compilação subversion estava quebrada devido ao fato de que o OpenSSL 1.0.0 introduziu algumas mudanças incompatíveis. Não demorei muito para encontrar a correção, porque este problema havia sido corrigido meses atrás, e uma simples busca na web encontrou tanto o relatório de bug quanto a correção. Mas ainda era um pouco irritante encontrar este problema quando eu estava apenas tentando reconstruir o produto.
Eu não tenho uma sugestão brilhante a fazer aqui. Mas tenho uma observação a fazer, que é que o tempo de máquina é agora abundante. Talvez devêssemos simplesmente reconstruir todo o nosso software todas as noites. Isso vai pegar problemas de construção quando as questões ainda estiverem frescas na mente de todos.
Além disso, caso você tenha algumas etapas manuais em seu processo de construção, a decisão de reconstruir freqüentemente será um bom incentivo para eliminá-las. As etapas manuais são uma fonte comum de erros.
Os testadores de software tendem a não gostar de software de reconstrução uma vez que o tenham testado. Eles o vêem como uma oportunidade de introduzir novos defeitos. Eu gosto de ter confiança suficiente em minhas ferramentas de construção (compiladores, linkers, makefiles) que eu posso reconstruir a qualquer momento. Dado que estamos trabalhando em idiomas de alto nível, devemos ter confiança em nossas ferramentas de construção. Mas há espaço suficiente para ambas as visões em um processo de desenvolvimento faseado.
Se você tiver sugestões sobre como gerenciar o desenvolvimento de software para minimizar as chances de quebrar a construção ou de minimizar o esforço necessário para corrigir problemas de construção, por favor, acrescente seus comentários a este post.
Empresa