Branches e integração contínua: o problema de feature branches

Integrar o código criado pelos desenvolvedores o mais frequentemente possível, com espaços de tempo mínimos, para que o feedback e consequências do código criado por um desenvolvedor entre em contato o mais rapidamente possível com os outros é o processo chamado de integração contínua.

Mas em diversos momentos existe a tentação de criar branches, linhas separadas de desenvolvimento, para cada funcionalidade: um feature branch, em cada um deles um conjunto de desenvolvedores trabalha de maneira isolada. O problema de desenvolver muito tempo sem integrar é que no momento que um feature branch terminar integrando-se ao mainline, os outros branches terão um processo de merge grande e custoso a ser feito.

Variações do “feature branch” são branches por cliente, onde cada um possui um conjunto distinto de funções que está disponível. Gerenciar esse trabalho é difícil e propenso a erro como por exemplo quando bugs que são corrigidos em determinados branches não são passados para outros. Para mantermos os benefícios da integração contínua, tentamos minimizar o impacto dos feature branches e encontrar uma maneira de remover o efeito negativo dos mesmos, mantendo os benefícios.

Se o branch vive menos de um dia, por exemplo, a prática de feature branches não vira uma discussão: o merge e seu respectivo impacto é pequeno, não é necessário se preocupar com o impacto dessa decisão na integração contínua pois o tempo no qual a integração não é contínua é relativamente baixo.

Por outro lado, existem dois possíveis motivos para um branch viver mais de um dia. O primeiro deles é o de criar uma história muito grande, que para ser implementada é necessário muitas horas de trabalho. A solução aqui é simples: quebrar as histórias em pedaços menores permitirá que os desenvolvedores terminem mais cedo algo entregável que possivelmente resultará em feedback para os próximos trechos a serem criados.

O segundo motivo, mais complicado, é para manter um branch master (ou trunk) limpo que pode ser deployado para produção a qualquer instante. O motivo é justo e nobre uma vez que boas práticas como integração contínua andam de mãos dadas com entrega contínua e feedback frequente mas ao invés de criarmos um bloqueio para algo melhor (a integração contínua), é mais interessante ganhar o benefício de ambos.

Durante o tempo de compilação, build do artefato de deploy ou ainda execução podemos utilizar técnicas para não registrar componentes de funcionalidades ainda não prontos. O exemplo a seguir mostra como utilizar um container simples de injeção de dependências para controlar diversos ambientes com features distintas. Todos os métodos que retornam objetos do tipo Ambiente são utilizados por convenção:

public class Ambientes {
  public Ambiente desenvolvimento() {
    return homologacao().com(OpenIdLogin.class);
  }

  public Ambiente homologacao() {
    return producao().com(ExcelExport.class);
  }

  public Ambiente producao() {
    return new Ambiente(new Container()).com(ClienteController.class).e(ProjetoController.class).e(LoginController.class);
  }
}

Da mesma maneira, em aplicações web, arquivos jsp templates de qualquer template engine podem ser customizados para mostrar determinadas partes de acordo com o ambiente atual:

<feature name="OpenId">
  ... codigo html ...
</feature>

E em qualquer ponto do sistema é possível verificar a disponibilidade de uma feature:

public class LoginController {
  private final FeatureSet features;
  public LoginController(FeatureSet features) {
    this.features = features;
  }

  public Usuario login(Map parametros) {
    LoginFeature login = features.for(Login.class);
    return login.valida(...);
  }
}

Toggles limpos e bem elaborados como esses permitem total customização do seu sistema sem ser um peso tão grande no desenvolvimento. Outras opções de implementações menos rebuscadas mas tão eficientes quanto envolvem a simples leitura de arquivos de propriedades. Ferramentas como o envie adicionam suporte a feature toggles em qualquer ponto de uma aplicação. O mesmo container acima funciona em Ruby da seguinte maneira:

production = Envie.production.with(:oauth)
development = production.derive.with(:openid)

feature(:oauth) do
   # codigo que utiliza oauth
end

feature(:openid) do
  # codigo que utiliza openid
end

Utilizando tais ferramentas de toggle, que são baseadas na criação de enviroments, é possível automatizar o processo de oficialização de uma feature. Dada que a feature “openid” foi aceita, um script é capaz de adiciona-la no ambiente de produção, ou uma variação que removeria as definições de chamada ao métod feature, resultando em um código mais limpo a partir do próximo commit.

Feature branches e toggles são uma alternativa extremamente popular no desenvolvimento open source e muito bem feita em alguns projetos como o kernel do linux que pode ser construído utilizando inúmeras combinações. Testes de integração não são mais capazes de garantir o comportamento através de todas as possíveis combinações mas continuam adicionando valor.

Durante o www 2010, Ian Robinson descreveu como o Neo4j pode ser utilizado como alternativa para propragação da configuração de nós diferentes em clusters de máquinas de determinadas aplicações de larga escala na web. A abordagem de feature toggles como esses é interessante e positiva para projetos grandes que envolvem a constante necessidade de integrar funcionalidades ainda não aprovadas por completo e serve como segunda opção durante a utilização de feature branches. Também serve como solução simples para feature toggle por grupos de clientes.

A primeira regra no instante de criar um feature branch é: evite criá-lo. A segunda regra é, integre-o ao mainline o mais rápido possível.

4 Comentários

  1. Bruno Braga 03/01/2011 at 23:27 #

    Bom ponto.
    O uso de toggle pode ser uma boa opção para uma equipe disciplinada… acho que é importante o “disciplinado” porque alguém (geralmente estagiário rs) que faça o commit de algo sem o toggle pode causar alguns problemas indesejáveis.

    E se você vai mesmo utilizar uma feature branch utilize uma ferramenta gerência de configuração que facilite a sua vida.
    Além dos recursos básicos de merge e gestão dos branchs se ela tiver rastreabilidade automática das tarefas (task, enhancement, bug) para o código facilita muito o processo de integração. Você pode fazer a integração do branch paralelo com o branch main orientado por tarefa em vez de código. Em outras palavras: você pode dizer que quer fazer a integração somente do defeito número 555 que está no branch paralelo com o branch main e a ferramenta tem que “se virar” para saber quais são os artefatos que tem que ser integrados e qual a parte desses artefatos devem ser integrados. (veja que na Classe1.java você pode ter alteração do defeito 555 e outra do 556 então dizendo o escopo a ferramenta saber qual parte do arquivo deve ser integrado).
    Existem outros recursos desse tipo que podem ser utilizados para facilitar.

    Então acho que se a idéia é praticar esportes radicais, que as pessoas pelo menos o façam com segurança =)

  2. Guilherme Silveira 04/01/2011 at 12:35 #

    Oi Bruno!

    Com certeza, em todos os casos (com branches ou sem branches) é importante alguem que entenda as práticas envolvidas. Se a pessoa não entender o que está acontecendo, pode não colocar um toggle ou comitar para master quando não deveria – nos dois casos a equipe precisa estar atenta ao que faz, nenhuma das práticas tira a responsabilidade de um desenvolvedor profissional.

    O branch por tarefa que você citou é o feature branch mesmo, mas no caso um que representa uma correção de bug, ou poderia ser um cherry pick (ou grupo de commits pick). De qualquer maneira, se fizer essa abordagem do branch utilizar ferramentas sim, com o oproprio git já quebra um grande galho.

    Abraço!

  3. Magno Machado Paulo 04/01/2011 at 16:26 #

    Eu já fui um grande defensor de feature branches para funcionalidades que levarão dias/semanas para serem desenvolvidas, mas por experiencia própria hoje sei que isso é algo que deve ser evitado tanto quanto possível.

  4. Dann Luciano 08/01/2011 at 18:14 #

    Muito interessante, ate o presente momento era um defensor de features branches, até por que as minhas experiências com times pequenos (eu e eu) até hoje foram muito satisfatórias, mas analisando o que foi descrito no post posso concluir que em equipes grandes isso pode gerar um grande problema

Deixe uma resposta