Usando implementações baseadas em branch no seu pipeline de entrega contínua

Uma das perguntas que a gente precisa entender a resposta é: entrega contínua para onde? E de onde, nesse sentido.

Sarah Goff-Dupont Sarah Goff-Dupont

Muitas vezes a gente usa termos como "pipeline" para descrever o fluxo contínuo de código do repositório para os usuários. No entanto, ao fazer o mapeamento no papel, esse pipeline vai ficar mais parecido com uma rede — em especial se estiver usando algum fluxo de trabalho de ramificação e merge (o que é muito recomendável).

Se estiver desenvolvendo em ramificação, faz sentido que essa ramificação tenha o próprio caminho de implementação, para que as alterações possam ser testadas em detalhe antes de passarem pelo merge com o mestre ou até mesmo lançada direto para os clientes. As ferramentas de desenvolvimento da Atlassian oferecem ótimo suporte a implementações em ramificação, como você vai ver a seguir.

Vou começar revendo os três casos de uso primários e, em seguida, explicar as integrações entre o Jira Software, o Bitbucket e o Bamboo que ajudam a colocar tudo isso em prática.

O argumento de defesa das implementações baseadas em ramificações

Em seu núcleo, o argumento de defesa para integrar a rede de ramificações ao pipeline de entrega contínua é a conveniência. Se você compartilha um ambiente de teste com outros colegas de equipe, é mais fácil coordenar o ritmo de implementações representando fluxos de trabalho discretos do que fazer o merge de todos os fluxos antes de implementar para teste e precisar desfazer o merge quando novas mudanças forem necessárias, o que é inevitável.

Se tiver a sorte de ter vários ambientes de teste disponíveis, é ainda mais fácil. Da mesma forma com o lançamento para os clientes: algumas equipes gostam de lançar direto de ramificações para, depois, fazer o merge das atualizações da ramificação para o mestre.

Acionamento automático de implementações a partir da ramificação do recurso

Usar ramificações de recursos para histórias de usuários e atualizações de segurança é excelente para enviar mudanças ao seu repositório no Bitbucket (permitindo que a CI seja executada em comparação com elas) sem sujeitar o resto da equipe a broken builds e testar as falhas enquanto o trabalho está em andamento.

Se a equipe preferir lançar a partir do mestre, é provável que seja melhor implementar esse código em ambientes internos para testes exploratórios e de aceitação. Isso funciona melhor quando há vários ambientes de teste em que a equipe possa implementar para que ninguém precise esperar a vez de usar um único ambiente compartilhado.

Com implementações em ramificação no Bamboo, é possível configurar o acionador de implementação para qualquer ambiente, para fazer a implementação automática dos artefatos criados em alguma ramificação específica — seja em intervalos agendados ou para cada build de CI bem-sucedida dessa ramificação. É possível até usar os dois tipos de acionador combinados.

Captura de tela do ambiente de teste

Talvez exista apenas um ambiente de teste de desempenho que todos compartilham. Nesse caso, ao longo do dia, implemente o mestre nesse ambiente sempre que ele for criado com sucesso — para a maioria das equipes que gostam de ramificações, os builds do mestre costumam ser o resultado de novos trabalhos que passam por merge, então é recomendado fazer a verificação imediata do desempenho.

Em seguida, durante a noite, quando o repositório estiver ocioso, agende as implementações de cada ramificação de desenvolvedor em intervalos apropriados para que todos tenham feedback de desempenho sobre o trabalho feito pelo menos uma vez por dia. (Os trabalhos de implementação no Bamboo podem concluir com uma tarefa de script, Ant ou Maven que inicia os testes de desempenho.) Durante todo o tempo, os desenvolvedores podem usar acionadores de implementação automática para enviar builds para os ambientes de teste individuais sempre que a ramificação de recursos for criada com sucesso.

Para configurar tudo isso, é possível criar um projeto de implementação discreta no Bamboo para a ramificação de desenvolvimento ou associar a ramificação a algum ambiente dentro de um projeto de implementação, personalizando assim como as implementações no ambiente são acionadas.

Captura de tela do projeto de criação de implementação

Confira os documentos do Bamboo para obter instruções passo a passo sobre como associar o projeto de implementação a alguma ramificação e personalizar acionadores de implementação.

Lançamento a partir de ramificações de versão

Para equipes que preferem colocar o trabalho em andamento direto na linha de código principal, fazer o lançamento a partir de uma ramificação é mais atraente. Enquanto o mestre ou o tronco são implementados no ambiente de teste, as ramificações de versão são aquelas implementadas para o staging e, em última análise, para a produção. As ramificações de versão também podem ser usadas como parte da abordagem do Gitflow.

Captura de tela do Gitflow

As ramificações de versão são editadas com frequência e as mudanças são lançadas a partir delas. E a maioria das equipes prefere tomar decisões humanas sobre quando e onde implementar a ramificação de versão, em vez de ter um acionador automatizado. Sem problemas.

O Bamboo tem esse conceito de "lançamentos" que são entidades dentro do Bamboo que encapsulam os artefatos mais recentes criados a partir de alguma ramificação específica, além de todos os commits, resultados de teste e itens do Jira associados com todos os builds nessa ramificação desde a última vez que alguma versão foi criada. Então, por dentro, em suma a versão são os artefatos empacotados, além de muitos metadados.

A gente quer que todos os dados avançados sigam pelo pipeline de entrega contínua junto com os artefatos para que seja possível rastrear eles de volta ao primeiro commit e história do usuário que deu início a tudo. (acredito que foi Geoffrey Chaucer quem disse primeiro "Todas as estradas levam ao Jira Software"). Então, é a versão que está sendo promovida pelos ambientes, não apenas um build. E vai ser possível ver isso refletido na interface do usuário do Bamboo.

Captura de tela das versões de staging do Bamboo

De qualquer forma, vamos voltar aos acionadores. Quando as implementações têm acionamento automático, como no caso acima, o Bamboo faz a criação automática da versão.

No entanto, as implementações com o clicar de um botão são diferentes. Nesse caso, versão é criada (o que pode ser feito a partir da tela de resultados do build ou de dentro do projeto de implementação), algum nome é dado a ela e basta selecionar o build de onde os artefatos vão ser extraídos. Com a versão em mãos, agora é possível fazer a implementação em qualquer ambiente — mesmo direto para a produção, se é isso que precisa ser feito. As equipes que usam essa abordagem costumam criar várias versões (candidatos de versão, na verdade) antes de dar a aprovação final e enviar a versão para o pipeline.

Quando chegar a hora de promover a versão para o próximo ambiente, vá para a tela Todos os projetos de implementação, onde é possível ver todos os projetos de implementação e todos os ambientes associados a cada projeto. Clique no ícone de implementação ao lado do ambiente de destino e navegue pelo assistente de visualização de implementação, selecionando a opção implementar versão existente (conforme descrito em maiores detalhes no link).

Lançamento de atualizações para versões suportadas

Caso não esteja no mundo do SaaS, é provável que vai precisar suportar várias versões do software em paralelo e, em algum momento, lançar correções críticas, atualizações de segurança de back-port, etc. Isso significa manter ramificações de versão estáveis por muito tempo — anos, na maioria dos casos. Os builds dessas ramificações costumam ser implementados em algum local comum, como um site ou repositório externo, onde os clientes podem baixar as atualizações para as versões que estão usando.

Captura de tela de fluxo de trabalho de múltiplas versões

Para essas ramificações, a maneira mais fácil de transformar builds em versões é com o botão criar versão encontrado na tela de resultados do build para o build que vai ser enviado. Claro, é possível começar na tela todos os projetos de implementação, conforme descrito acima. No entanto, como toda a concentração está no build específico que quer lançar — que nem sempre é o build mais recente nessa ramificação — eu acho que começar na tela de resultados do build oferece maior garantia de este é sim o build que precisa ser enviado.

Juntando tudo (um pipeline de entrega contínua de cada vez)

As implementações baseadas em ramificações são a extensão natural das ramificações de plano do Bamboo, que, por sua vez, são a extensão natural de qualquer esquema de ramificação configurado para a equipe no Bitbucket. Como mostrei aqui e debato a fundo

em outros artigos, existem vários modelos de CD fáceis de usar para escolher.

O esquema de ramificação deve refletir como a equipe lida com o trabalho e o entrega.

Então, é hora de analisar as várias peças em jogo aqui:

  • Itens do Jira – Tenha em mente que as chaves do item são mágicas. Faça a inclusão delas no nome das ramificações e nas mensagens de commit para que todos os commits, builds e implementações (até mesmo solicitações pull!) sejam vinculados ao item.
  • Ramificações – Você sabia que quando você conecta o Bitbucket ao Jira Software, cada item tem um link Criar ramificação apropriado? E que quando você usar esse link, a chave do item vai ser adicionada ao nome da ramificação? Assim você pode ver o quanto a gente acredita na criação de uma ramificação para cada item em que você trabalha. Experimente fazer no próximo sprint, só por diversão.
  • Ramificações de plano – O Bamboo faz a detecção automática de ramificações novas nos repositórios Git, Mercurial e Subversion se você habilitar o gerenciamento automático de ramificação. No momento em que você fizer o primeiro commit, o Bamboo já coloca essa ramificação em teste.
  • Projetos de implementação – A fase de "entrega" do pipeline de entrega contínua. Você vai associar um repositório e um ou mais ambientes a cada projeto de implementação.
  • Ambientes – Representação do Bamboo dos ambientes na rede. Cada ambiente pode ser associado a ramificações diferentes, usar acionadores de implementação diferentes e usar etapas diferentes (chamadas de tarefas) para executar uma implementação bem-sucedida.
  • Versão – Artefatos preparados + metadados. Ao observar uma determinada versão no Bamboo, você vai poder ver todos os itens do Jira (porque as chaves de item são mágicas!), commits, resultados de teste e artefatos associados a eles. Você pode até ver em quais ambientes o item foi implementado e fazer uma marcação nele como aprovado para promoção por meio do pipeline ou rejeitado.

Cada caso de uso coberto aqui é utilizado por pelo menos uma equipe de desenvolvimento dentro da Atlassian. Algumas equipes inclusive usam-nos de modo combinado. E não vou mentir: a transição de um único pipeline de entrega contínua (ou nenhum) para uma rede de pipelines baseados em branch levará mais tempo do que você espera, e destaca alguns aspectos dos seus processos atuais que você precisará resolver.

Mas tudo bem. Apenas comece. E conte para gente como está indo! Mande um tweet para @Atlassian ou siga o Blog da Atlassian para saber mais sobre agilidade, Git e ferramentas de desenvolvimento.