Integração Contínua e estratégias de branching

… qualquer estratégia que adotemos que não faça commit pelo menos diário em um branch “mainline” vai contra a Integração Contínua. E finalmente eu entendi o conceito principal de Integração Contínua que é utilizar a ferramenta de controle de versão como um meio de comunicação (Integração). Fazendo o commit todo dia fica fácil de identificar os conflitos nos merges que pelo fato de ser ao menos diário são menores. Quando acumulamos muitas diferenças os merges costumam ser grandes e trabalhosos. De qualquer forma ainda temos o desafio de manter a qualidade de código, fazer reviews, melhorar a qualidade do time de desenvolvimento, etc.

Além disso, percebi que o Martin Fowler (ThoughtWorks, Manifesto for Agile Software Development) e Scott Chacon (GitHub) fazem deploy diário em produção. Ter uma estratégia de branches simples e rápida é crucial para fazer deploy diário. Acredito que ainda não estamos prontos para deploy diário em produção mas talvez esse conceito sirva para pensar em como faremos no futuro.

“It’s important to note that, most of the time, feature branching like this is a different approach to CI. One of the principles of CI is that everyone commits to the mainline every day. So unless feature branches only last less than a day, running a feature branch is a different animal to CI. I’ve heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit. That’s continuous building, and a Good Thing, but there’s no integration, so it’s not CI.”

http://martinfowler.com/bliki/FeatureBranch.html

http://earlyandoften.wordpress.com/2011/09/14/dvcs-ci/

http://scottchacon.com/2011/08/31/github-flow.html

http://nvie.com/posts/a-successful-git-branching-model/

https://github.com/mborsuk/hubflow

Anúncios