Publicar com frequência e voltar atrás quando preciso
Montamos o caminho automático do código até a produção: cada mudança é testada, publicada da mesma forma todas as vezes e pode voltar à versão anterior.
Para quem é
Para empresas em que cada publicação vira um evento tenso, marcado para a noite ou o fim de semana.
O que resolve
- A publicação depende de uma pessoa seguir uma lista de passos à mão.
- Uma versão com erro chega à produção porque os testes não rodaram.
- Voltar à versão anterior leva horas, e ninguém tem certeza de como fazer.
- As mudanças se acumulam por semanas, e cada publicação vira uma grande aposta.
O que fazemos
- Integração contínua
- A cada mudança, o código é compilado, testado e verificado antes de entrar na linha principal.
- Portões de qualidade
- Testes, verificações de segurança e revisão obrigatórios; se algo falha, a versão não segue.
- Um só artefato
- A imagem testada em homologação é a mesma que vai para produção, assinada e rastreável.
- Publicação gradual
- Quando o sistema permite, a versão nova recebe parte do tráfego antes de assumir tudo.
- Volta à versão anterior
- Um comando documentado e ensaiado devolve a produção à última versão estável.
- Migrações de banco
- Mudanças no banco de dados escritas para conviver com a versão anterior durante a troca.
O que você recebe
- Pipeline de integração e entrega rodando no repositório da sua empresa
- Regras de bloqueio para testes, verificações de segurança e revisão
- Roteiro de volta à versão anterior, ensaiado com a sua equipe
- Registro de cada publicação: o que mudou, quem aprovou e quando
- Documentação para a sua equipe manter e ajustar o pipeline
Como fazemos
Diagnóstico
Como o código chega hoje à produção, passo a passo, e onde trava.
Integração contínua
Build e testes automáticos a cada mudança, com o resultado visível para a equipe.
Entrega automatizada
Homologação e produção pelo mesmo caminho, com aprovação onde for preciso.
Ensaio de volta
Uma versão é revertida de propósito, para provar que o caminho de volta funciona.
Repasse
A sua equipe passa a publicar sozinha, com a documentação em mãos.
Exemplos de tecnologia
- GitHub Actions
- GitLab CI
- Argo CD
- Docker
- Trivy
- Cosign
Serviços relacionados
Perguntas frequentes
Com que frequência dá para publicar?
Depende dos testes que existem e de como o sistema e a equipe trabalham. O objetivo é que publicar vire rotina, e não um evento marcado com antecedência.
Quem aprova uma publicação em produção?
Quem a sua empresa definir. O pipeline pode exigir a aprovação de uma pessoa antes da produção, e cada aprovação fica registrada com nome e horário.
E se ainda não temos nenhum teste automático?
Começamos pelos fluxos que mais doem quando quebram e ampliamos aos poucos. Esse trabalho é feito no serviço de testes automatizados.
Publicar mais vezes não aumenta o risco?
Em geral, não. Uma mudança pequena é mais fácil de testar, de entender e de desfazer do que um pacote grande acumulado por semanas.
Escreva para a Balkan
Falar sobre o seu projeto