Integração Contínua -Blog Caelum

Na minha experiencia, build limpo eh aquele que passou por todos os testes automatizados e portanto ja teria potencial para entrar em producao.

O que voce quiz dizer com builds sendo “quebrados em pequenas partes”?

Extraido do Blog (Integração Contínua) http://blog.caelum.com.br/

“Para tudo isso funcionar, no entanto, é preciso agarrar a idéia de commits pequenos. Fica mais fácil saber onde foi introduzido um erro quando o build quebrar se houveram pequenas mudanças, do que ter de verificar as ultimas 50 classes alteradas no ultimo commit.”

:idea: Quando ele se refere a commits pequenos ??? aqui ele esta se referindo a builds (quebrar) , seria isso ???, eu tenho builds que estão separados em pequenos commints ???

Marcio Duran:

“Para tudo isso funcionar, no entanto, é preciso agarrar a idéia de commits pequenos. Fica mais fácil saber onde foi introduzido um erro quando o build quebrar se houveram pequenas mudanças, do que ter de verificar as ultimas 50 classes alteradas no ultimo commit.”

:idea: Quando ele se refere a commits pequenos ??? aqui ele esta se referindo a builds (quebrar) , seria isso ???, eu tenho builds que estão separados em pequenos commints ???

O build eh incremental e por isso o autor sugere commits pequenos. Desta forma cada build novo contera menos mudanca e portanto sera mais facil identificar problemas. Alem disso commits pequenos normalmente tambem acabam se tornando mais frequentes e os possiveis problemas sao identificados mais cedo.

A ideia nao eh quebrar o build, e sim fazer builds mais frequentes e com menos mudancas em cada um.

Marcio Duran:

“Para tudo isso funcionar, no entanto, é preciso agarrar a idéia de commits pequenos. Fica mais fácil saber onde foi introduzido um erro quando o build quebrar se houveram pequenas mudanças, do que ter de verificar as ultimas 50 classes alteradas no ultimo commit.”

Marcio,
Acho que você entendeu um pouco errado. Ele diz pra fazer commits pequenos porque depois de ter feitos os testes e rodar tranquilo, se o próximo (ou os próximos) commit derem algum bug, é mais fácil de saber onde está o erro.
Uma analogia (acredito eu) pode ser feita assim (superficialmente): quando você desenvolve alguma coisa (código mesmo), e deixa só pra compilar no final, você pode levar muito mais tempo consertando do que integrando. Já, se você compila aos poucos, você consegue como as coisas estão acontecendo e se elas estão dando certo ou não. É (acredito eu) a mesma coisa com os commits: se você faz um commit grande, a quantidade de código a ser analisado é muito maior do que pequenos commits.

Nunca lidei com isso, mas pelo que eu pude perceber, é assim que funciona. Alguém me corrija se eu estiver errado, por favor.

Abraço.

Oi Marcio

Como os demais comentaram, a idéia é a seguinte: commits pequenos, pra se algo quebrar vc saber onde foi.
O que quis dizer com build limpo ao final do dia, é tentar garantir que todos seus testes estejam passando, pra assim SE for precisso, ir pra produção.

Entendo que talvez tenha ficado um pouco confuso a idéia de build limpo / commits pequenos / builds pequenos. Em resumo, chamo de commit toda e qualquer alteração de código que é submetida ao repositório. Já o build seria TODO o código testado e compilado. Independente de ainda ter código pra ir pro repositório ou não. Build seria o código que está no repositório naquele momento testado e compilado (ou pelo menos a tentativa disso), e build limpo o código em que passou em todas essas etapas com sucesso

Espero não ter gerado mais dúvidas

Cauê Guerra

Vamos lá:

Tu tem cinco bolinhas verdes, significando código okay e uma vermelha, significando uma falha no código. Se jogadas num pote, fica bem fácil achar a vermelha. Mas se tu tiver 100 bolinhas, entre elas: verdes, laranjadas, rosas, roxas e uma ou duas vermelhas, fica mais dificil/demorado achar as vermelhas.