No último dia 20 de Março, no Pipeline Conference em Londres, Dave Farley, co-autor do livro Continuous Delivery, fez uma palestra onde apresentou o slide acima, postado no Twitter. Na palestra, intitulada ‘Optimising Continuous Delivery’, Dave fala sobre a necessidade de adotar trunk-based development para efetivamente praticar Continuous Integration e Continuous Delivery.
A palestra gerou muitos posts, contra e a favor, tantos que ele resolveu escrever um artigo à respeito, que publicou no seu próprio blog no dia 30 de Março. No artigo ele já aborda muito bem o assunto, fiquem à vontade para ler, mas de qualquer forma vou me atrever aqui a colocar a minha visão, e tentar explicar por que trunk-based é o melhor modelo de desenvolvimento para DevOps.
De acordo com o trunk-based development, não é preciso criar branches, o código evolui numa única linha, o trunk. A regra neste modelo é que o código esteja sempre num estado tal que possa ser passado para a produção.
Ele difere portanto do GIT Flow, que contempla branches de tipos diferentes, cada um com seu propósito. Feature branches, por exemplo, são usadas para a criação de novas features. Quando o desenvolvimento da feature termina, o código é efetivamente integrado através de merge.
Por mais que o código seja super bem construído, e siga fielmente princípios de programação orientada a objetos como SOLID, por exemplo, sabemos que conflitos de merge ocorrem. Uma hora ou outra é inevitável que nos deparemos com a necessidade de resolver conflitos de merge.
Não tem jeito, o risco de merge precisa ser endereçado. Mas pensem comigo, o que é melhor: resolver o quanto antes conflitos de merge menores ou deixar pra depois a resolução de um conflito de merge enorme?
Quanto mais duradoura é uma feature branch, maior é a probabilidade dela gerar conflitos de merge. Agora imaginem várias feature branches paralelas que em determinado momento precisarão ser mergeadas para se criar uma nova release?
Outra questão é que quando se usa feature branch, seu código só é integrado quando o merge é realizado. Isto que dizer que a integração neste caso não é tão contínua assim, pelo menos não é tão regular quanto a prática da integração contínua requer. Não adianta se enganar.
Como consequência, não há como existir a entrega contínua de fato, se a própria integração contínua é capenga. A conclusão que se chega é que mesmo usando ferramentas que permitam a automatização e a adoção de práticas DevOps como integração contínua e entrega contínua, é possível que não esteja sendo feita nem integração contínua e tampouco entrega contínua de fato.
Muitos confundem DevOps com automatização, mas automatização não é tudo. A automatização, assim como o trunk-based development, vem como meio para otimizar o fluxo, aí sim um dos princípios do DevOps. Segundo este princípio, quanto antes uma linha de código estiver em produção, melhor, pois é quando efetivamente se entrega valor. Dentro desse contexto, o trunk-based development se encaixa perfeitamente.
O time que usa esse modelo, tem o costume de fazer vários commits ao dia. São commits menores, com o código suficiente para agregar algum valor. Essa regularidade permite que se tenha uma validação muito mais constante do que é feito. Ciclos mais curtos de feedback, portanto, que é outro princípio do DevOps. Visando a qualidade acima de tudo, este princípio defende que eventuais problemas sejam identificados e resolvidos o quanto antes no processo. O trunk-based development cai como uma luva, neste caso.
Ok, mas como então distinguir as features, se o código está todo no trunk? Aí entram as feature flags! Feature flag é uma técnica que habilita/desabilita para execução o código de uma feature específica, dependendo de determinadas condições. Isto quer dizer que uma feature pode ser passada para produção até parcialmente, sem problema algum, desde que esteja desligada. E mais, com este dispositivo, é possível ligar e desligar features em produção com facilidade, ou seja, features podem ser experimentadas.
DevOps tem como princípio o aprendizado contínuo, que justamente se consegue através da experimentação. A adoção de feature flags dentro do modelo trunk-based de desenvolvimento, portanto, se encaixa nesse princípio como nenhum outro modelo.
Resumindo, trunk-based é o modelo de desenvolvimento mais aderente ao DevOps, pois contempla seus três princípios: otimização de fluxo (First Way), ciclos curtos de feedback (Second Way) e aprendizado contínuo (Third Way). Espero que tenham gostado do artigo e não esqueçam de dar qualquer feedback. Afinal, melhoria contínua, sempre 🙂
