Entrega contínua com Spinnaker
Aqui na RD, estamos trabalhando na evolução da arquitetura e quebrando nossa aplicação monolítica em microservices. Essa mudança de arquitetura traz muitos benefícios, mas também algumas complexidades. Por exemplo, como ter continuous delivery em todas essas aplicações? No monolito, o processo de entrega já está automatizado, é seguro e rápido. Mas e as novas aplicações? Como garantir um processo similar para todos os serviços que estão nascendo?
Estamos resolvendo esse problema utilizando o Spinnaker junto com o Jenkins, automatizando o processo de entrega de software para produção.
Com objetivo de todos aprenderem como colocar continuous delivery nos nossos serviços o Robert Vilvert fez uma palestra para o time de produto. Achamos que essa palestra vai ajudar mais pessoas fora da RD, e por isso decidimos compartilhar esse conhecimento por aqui, e liberar o vídeo dessa apresentação (no final do post =P).
O que é Spinnaker?
Spinnaker é uma ferramenta opensource para continuous delivery em multi cloud. Com ela, é possível entregar mudanças de software com alta velocidade e confiança. A ferramenta serve para criar um pipeline de entrega, automatizando a execução das diversas tarefas necessárias em um deploy.
Jenkins?
O Jenkins é uma ferramenta opensource para automatização de servidores. É ele quem vai executar as tarefas que precisamos do nosso Pipeline. Por exemplo, conferir se as condições de deploy estão corretas.
Pipeline
Um dos nossos pipelines do Spinnaker ficou assim, mas você pode adaptar para a sua aplicação. Nós temos alguns outros pipelines mais simples que funcionam muito bem também.
Configuração
Nessa etapa nós configuramos um parâmetro branch, que vai ser a branch no github com as mudanças do software que precisamos colocar no ar.
Verificando condições da versão
Depois de escolher a versão que deve ser colocado em produção temos uma etapa onde verificamos se as condições da versão estão ok, aqui avaliamos se a branch está com os testes passando, analisamos a qualidade do código e podemos adicionar outras validações.
Atualizando com a Master
As validações passando, atualizamos branch com a master, para garantir que nenhuma regressão vai acontecer.
Construindo o container
Construímos o container com a branch, usamos docker e um cluster de kubernetes. Essa etapa de build é realizada por um serviço da Google Cloud.
Configurando as variáveis de ambiente
Configuramos as variáveis de ambiente que a aplicação precisa para rodar, por exemplo configuração de banco de dados.
Serviço
Essa parte é um load balancer dentro do kubernetes que vai tratar as requests e direcionar para a nossas aplicações configuradas com as labels escolhida.
Canary e Baseline
Nesse estágio do pipeline nós configuramos para subir dois pods, um com a versão estável da aplicação que vamos chamar de baseline, e outro com a nova versão e nós vamos chamar de canary. Configuramos para uma parte das requests serem direcionadas para o canary, e com isso podemos monitorar e ver se tudo está certo, se não estamos recebendo erros críticos.
Pronto para produção
Depois de analisar os dados do canary precisamos manualmente informar se queremos continuar com o deploy da nova versão. Nós configuramos para ser manual essa parte, mas é possível fazer essa parte automatizada, por exemplo com base no status das requests do canary, ou mesmo rodando algum comando e verificando o status de saída.
Adiciona a tag stable da branch
Caso verificamos que a versão canary está ok, e confirmamos no passo anterior o deploy o pipeline continua adicionando uma tag de stable na branch.
Deploy to production
Então é feito um deploy da tag stable em produção.
Rollback?
Verificamos nessa etapa se é necessário um rollback, se a resposta for sim o deploy da master é feito. E o pipeline termina aqui.
Merge na master
Se não for preciso o rollback a branch nova é mergeada na master.
Conclusão
Definimos um pipeline com diversos passos para fazer deploy, alguns passos manuais nesse pipeline para controlar riscos. Mas cada aplicação tem uma necessidade e deve ser desenhado para atender aos requisitos dela.
Automatizar o processo de deploy é necessário para garantir a evolução rápida do software, manter a qualidade e evitar problemas em produção. Assim diminuímos erros acidentais e garantimos entregas mais confiáveis.
Se quiser se aprofundar e ver como fizemos isso você pode baixar o vídeo da palestra do Robert no Botão abaixo, ou se tiver dúvidas ou sugestões pode compartilhar nos comentários aqui.
