[b]Integração Contínua
Por Cauê Guerra em 04/11/08
[color=green]"Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente - podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente." Martin Fowler.[/color]
[/b]
Bom lendo esse texto, me causou uma certa curiosidade sobre a forma esclarecedora sobre o assunto, entretando também duvidas, sobre a maneira gerencial ágil a ser resolvida baseado em testes continuos, no texto acima tem uma introdução sobre a [color=green]Integração Contínua[/color], no texto abaixo uma explicação, retirada do texto completo.
"Outro ponto importante, é garantir ao menos um build limpo, com todos os testes passando, ao final de cada dia. Assim, teremos software pronto para entrar em produção tão cedo seja necessário. "
[i]Pergunta:
Então se tenho um build limpo, quer dizer que este é o build que vai ser considerado o final para todos os testes, ou esse builds que são quebrados em pequenas partes vão se completando fazendo atualização desses testes, à ter o software pronto para entrar na produção ?
[/i]
:arrow: http://blog.caelum.com.br/ {fonte no blog, veja o texto completo}
“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 ???
[quote=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 ???[/quote]
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.
[quote=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.” [/quote]
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.
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
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.