Como chegar à implementação contínua

Neste guia, vamos supor que seu fluxo de trabalho de integração contínua e entrega contínua já esteja em vigor e que seu próximo passo é configurar seu pipeline de entrega contínua.

Sten Pittet Sten Pittet

Ainda, confira o tutorial sobre como começar a usar Implementação contínua no Bitbucket Pipelines.

"Ninguém toque na produção — Estou prestes a lançar!"

Essa frase pode ser familiar para você. A implementação na produção pode ser um exercício arriscado e dispendioso que às vezes requer colocar todo o desenvolvimento em espera. Assim os ciclos de versão ficam lentos e as alterações ficam paradas no ambiente de desenvolvimento. É o início de um círculo estranho (e vicioso) no qual quanto mais commits forem feitos no repositório, mais riscos são introduzidos na próxima implementação para produção, e menor a probabilidade de sua equipe fazer esse lançamento.

A implementação contínua resolve esse problema enviando automaticamente cada alteração enviada por push ao repositório principal para produção. É uma abordagem radical, muito diferente de gastar dias preparando e controlando cada versão, mas há diversos benefícios na implementação contínua:

  • As versões ficam menores e mais fáceis de entender.
  • Ninguém é obrigado a deixar seu trabalho para fazer uma implementação porque tudo é automatizado.
  • O ciclo de feedback com seus clientes é mais rápido: novos recursos e melhorias vão direto para a produção quando estiverem prontos.

Pode ser bastante assustador passar de lançamentos aprovados para implementação contínua, mas este guia está aqui para ajudar a fazer essa transição. A gente trouxe as bases para que você possa começar assim que possível e passar a acelerar seu ciclo de lançamento.

Implementação contínua versus entrega contínua

Se você quiser implementar um pipeline de implementação contínua, o melhor lugar para começar é com a entrega contínua. Essas duas práticas são semelhantes, mas diferem em suas abordagens para implementações de produção. Na entrega contínua, todas as alterações enviadas por push para o repositório principal estão prontas para serem enviadas, mas o processo de lançamento de produção ainda requer aprovação humana. Na implementação contínua, o lançamento para produção é feito automaticamente para cada alteração que passa no conjunto de testes.

Entrega contínua vs. implementação contínua

Antes de começar o lançamento automático de alterações para a produção, você vai precisar ter uma boa cultura de integração contínua (CI), e é altamente recomendável começar com a entrega contínua primeiro. Você pode ler mais sobre as duas práticas nos artigos abaixo:

Passando da entrega contínua para a implementação contínua

Enfatize uma cultura de integração contínua

No centro da implementação contínua está uma grande cultura de CI. A qualidade do seu pacote de teste determinará o nível de risco da sua versão, e sua equipe precisará dar prioridade a testes automatizados durante o desenvolvimento. Isso significa implementar testes para cada novo recurso, bem como adicionar testes para qualquer regressão descoberta após o lançamento.

Corrigir um build quebrado para a ramificação principal também deve estar em primeiro lugar na lista. Caso contrário, você vai se expor aos mesmos riscos que enfrentou antes de adotar a implementação contínua: as alterações são acumuladas no ambiente de desenvolvimento, e os desenvolvedores não conseguem ter certeza de que seu trabalho está concluído, pois não sabem se suas alterações passaram nos testes de aceitação.

Tenha uma boa cobertura de teste (e bons testes também!)

Comece a usar ferramentas de cobertura de teste para garantir que seu aplicativo seja testado de modo adequado. Um bom objetivo é visar 80% de cobertura.

Tenha cuidado para não confundir boa cobertura com bom teste. Você pode ter 100% de cobertura de teste com testes que realmente não desafiam sua base de código. Invista tempo durante as revisões de código para verificar como os testes são escritos e não hesite em apontar lacunas na cobertura ou testes fracos. Seu conjunto de testes atua como o portão para a produção – faça com que ele seja forte.

Adote monitoramento em tempo real

Se você for implementar cada commit automaticamente em produção, precisará garantir que tenha uma boa maneira de ser alertado se algo der errado. Às vezes uma nova alteração não causará uma falha na produção de imediato, mas fará sua CPU ou consumo de memória subir a níveis perigosos. Por isso, é útil implementar monitoramento em tempo real em seus servidores de produção para conseguir rastrear irregularidades em suas métricas.

Ferramentas como o Nagios ou serviços como o New Relic podem ajudar a rastrear métricas básicas de desempenho e enviar alertas sempre que houver um distúrbio em seus sistemas.

Revise seus testes pós-implementação

Depois de cada implementação na produção, você deve executar alguns testes de sanidade simples para garantir que o aplicativo esteja ativo e em execução.

Garanta que esses testes façam mais do que apenas acertar uma página estática, aguardando uma resposta bem-sucedida. É uma prática recomendada fazer um teste que exija que todos seus serviços de produção (banco de dados, microsserviços, terceiros...) estejam funcionando corretamente.

Faça com que sua equipe de controle de qualidade trabalhe a montante

Como cada commit vai direto para a produção, não há buffer tradicional para seu QA revisar e aprovar novos recursos. Em vez disso, eles devem estar trabalhando em estreita colaboração com o gerente de produto e a equipe de desenvolvimento para definir os riscos associados a novas melhorias.

Esta é uma ótima oportunidade para a equipe de QA, pois vai resultar, ao longo do tempo, em melhor qualidade para as versões. Com a implementação contínua, a tendência natural da equipe vai ser a de ter uma boa cobertura de teste da base de código. Sem ela, vai haver interrupções frequentes devido a bugs passando para a produção onde eles são descobertos por seus usuários.

Libere as notas de versão tradicionais

A implementação contínua dificulta acompanhar as versões — o que é bom! Seu objetivo deve ser ter implementações diárias para produção, até mesmo várias implementações por dia. Podem ser atualizações de segurança, pequenas melhorias, novos recursos... tanto faz. Assim que um desenvolvedor terminar seu trabalho, esse trabalho deve ser executado na produção em questão de minutos.

Neste novo mundo não é mais possível escrever notas de versão que sejam enviadas para seus clientes com cada nova versão. Em vez disso, adote esse novo fluxo e limite seus anúncios aos principais recursos que são importantes para seus clientes. Relatórios de bugs e pequenas solicitações de melhoria podem simplesmente ser manipulados em seu sistema de tickets — o JIRA, por exemplo, pode atualizar todos os observadores de um ticket assim que você o fechar ou atualizar.

Uma abordagem diferente para novos projetos: implementar na produção antes da codificação

Há algo interessante que você pode fazer se está começando em uma nova base de código. É possível começar criando seu pipeline de implementação contínua antes de ter qualquer cliente e qualquer recurso pronto (não diferente do desenvolvimento orientado por testes). No início, você vai enviar uma plataforma vazia. Então, à medida que o desenvolvimento avança, novas capacidades vão começar a aparecer automaticamente. Você só precisa manter seu ambiente de produção fechado até estar pronto para a abertura para seus clientes.

Esta abordagem pode parecer contraintuitiva no início. Mas é uma maneira fácil de eliminar o estresse de passar de uma aprovação manual de versão para a implementação contínua para a produção. Também é uma excelente maneira de garantir que você tenha uma boa cobertura de teste e cultura de integração contínua no lançamento, pois elas são condições necessárias para a implementação contínua.

Amplie seu conhecimento e compartilhe sua experiência!

É compreensivelmente difícil dar o salto e mudar para a implementação contínua. De repente, os portões são levantados e o código vai direto para os clientes em questão de minutos ou horas. (Nossa!) Então é importante investir nos testes e automações que para que você tenha confiança nos builds. Vai ser fácil se sua base de código for nova, mas pode exigir a adoção de uma estratégia diferente para uma base de código legada complexa.

Comece aos poucos e crie seu conhecimento e experiência de implementação contínua. Depois de conseguir em um projeto, vai ser fácil replicar o sucesso em outras partes da organização.