Integração Contínua: qual frequência?

Sempre lancei compilações após cada confirmação, mas nesse novo projeto, os arquitetos apenas me pediram para alterar a frequência para "uma compilação a cada 15 minutos", e não consigo entender por que isso seria uma boa razão vs " com base em cada confirmação ".

Primeiro, alguns detalhes:

• Projeto Objective-C (iOS 5)
• 10 desenvolvedores
• cada construção leva aproximadamente 1 minuto e inclui testes de construção e unidade.
• o servidor de integração é um Mac Mini, então o poder da computação não é realmente um problema aqui
  • usamos Jenkins com o plugin XCode

Meus argumentos eram de que, se você criar em cada commit, poderá ver agora o que deu errado e corrigir diretamente seus erros, sem incomodar os outros desenvolvedores com muita frequência. Além disso, nosso testador é menos incomodado por erros de UT dessa maneira. Seus argumentos eram de que os desenvolvedores serão inundados por e-mails com "erro de construção" (o que não é completamente verdade, pois o Jenkins pode ser configurado para enviar um e-mail apenas para a primeira compilação interrompida) e que as métricas não podem ser feitas corretamente se a frequência de compilações é muito alto.

Então, qual sua opinião sobre isso?

Falhar rápido é um bom princípio - quanto mais cedo você souber que a compilação é interrompida, mais cedo a confirmação incorreta pode ser identificada e a compilação corrigida.

Construir sobre cada commit é a coisa certa a se fazer.

Construir a cada 15 minutos pode ser inútil se o projeto tiver um alto volume de confirmações dentro desse prazo - rastrear a confirmação incorreta levaria mais tempo e pode ser difícil de determinar (pode ser também uma situação em que várias confirmações têm coisas diferentes que quebrar a compilação). Também existe a possibilidade de que, em períodos de silêncio (noite?), Você acaba se reconstruindo, embora nenhuma alteração tenha sido feita.

Se a compilação for interrompida com tanta frequência que for um problema, responda-a para reeducar a equipe sobre a importância de não interromper a compilação e em técnicas que garantam que isso não aconteça (buscas frequentes, dança no check-in, compilação e execução de testes de unidade localmente etc ...).

Não há sentido em fazer uma compilação a cada 15 minutos se nada mudou. Mas, igualmente, não há desvantagem; depois, o jenkins enviará apenas um e-mail em caso de falha e, em seguida, sucesso e nem tudo o mais (por exemplo, 10 falhas).

Fazemos isso em todos os commit. No entanto, pesquisamos o repositório a cada quinze minutos e verificamos as alterações, talvez seja a isso que seus colegas estão se referindo.

Você espera que seus 10 desenvolvedores estejam cometendo mais de uma vez a cada quinze minutos? Parece uma estimativa bastante alta. 10 dev's significa que, a cada 150 minutos, a mesma pessoa está cometendo novamente, o que significa 2,5 horas. Assim, em seu dia normal, cada dev comete 3 vezes. Pessoalmente, faço um commit ~ 2 dias ... às vezes mais às vezes menos.

Vai inundar os desenvolvedores com mais emails a cada 15 minutos. Isso porque não saberá com certeza quem quebrou a compilação e, portanto, enviará mais pessoas.

Quanto às métricas, se é realmente um problema - o que não sei dizer porque não sei com quais métricas eles acham que há um problema -, você sempre pode fazer outro trabalho para coletar as métricas.

Talvez o requisito seja "criar no máximo uma vez a cada 15 minutos". Isso pode fazer sentido para projetos com atividade de confirmação muito frequente (ou seja, várias confirmações em poucos minutos) e talvez longos tempos de compilação. Obviamente, depende também de como as compilações são usadas. Para os testadores, pode ser um pouco confuso obter várias compilações em 15 minutos ...

Mas concordo que não faz sentido construir se nada mudou.

Alguns desenvolvedores desejam permitir confirmações de uma maneira em que os arquivos pertencentes a uma alteração funcional não sejam confirmados em um único procedimento atômico. Eles precisam de dois ou três minutos para realizar uma "confirmação lógica", que consiste em algumas "confirmações físicas". Normalmente, esse é o caso quando seus desenvolvedores se comprometem diretamente com um repositório central, sem usar um DVCS.

Nesses casos, pode ser uma boa ideia deixar o servidor de IC aguardar algum tempo após a última confirmação antes de iniciar uma nova compilação. Mas 15 minutos parecem ser um número muito alto, 5 minutos ou menos devem ser suficientes.

Ou melhor (!), Tente orientar seus desenvolvedores a trabalhar apenas em pequenas porções, apenas uma coisa de cada vez, tornando muito mais fácil realizar somente confirmações físicas "completas funcionais". Em seguida, uma compilação após cada confirmação funcionará aparentemente.

Mesmo se você tiver o Jenkins configurado para construir uma confirmação de controle de origem em um projeto ou em qualquer uma de suas dependências, isso não impedirá que um desenvolvedor implante no repositório de artefatos sem primeiro se comprometer com o controle de origem. Se eles implantarem uma alteração descoordenada da API ou um bug em uma dependência do repositório de artefatos, isso poderá interromper sua construção sem acionar o trabalho Jenkins. Eu, pessoalmente, gostaria de saber sobre isso o mais rápido possível.

Idealmente, você criaria para cada confirmação e também em um cronograma para verificar situações como eu acabei de descrever. Conceitualmente, isso significa que você cria pelo menos uma vez a cada 15 minutos .

Se você tiver seus trabalhos do Jenkins configurados para execução em implantações de artefatos de dependência (e se você fizer ... Bravo), poderá tentar a compilação agendada se seus testes de unidade forem sólidos (o que significa que eles não testam as dependências) e seu testes de integração / funcionais não fazem parte do trabalho de Jenkins.

Quanto ao problema "inundar com email", eu digo que ficar inundado com email em uma versão quebrada é uma coisa boa. Certifique-se de forçar os desenvolvedores a responderem ao e-mail com uma descrição e você verá suas compilações quebradas decair, confie em mim.

Você disse que não pode entender o raciocínio deles, então precisa perguntar a eles. Não apenas adivinhe o que eles querem e tente implementar isso, e certamente não apenas implemente o que eles pediram sem entender por que eles pediram.

Dito isto, para responder à pergunta geral, depende da filosofia de desenvolvimento que você usa. Se todo commit deve funcionar, todo commit deve ser testado. Se você usar um DVCS com a filosofia de que cada push deve funcionar, teste cada push.

Em geral, é melhor dizer às pessoas algo que elas não sabem e depois repetir o que elas sabem. Por exemplo, se eles querem reduzir o número de e-mails redundantes que recebem, ajuste as configurações de e-mail, não a frequência de criação.