Português
Mínimo viável para a Entrega Contínua
“A entrega contínua não só melhora a qualidade e capacidade de entrega, bem como ajuda na evolução da cultura, reduz o cansaço e as dores do desenvolvimento/release.”
– Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Tradução não oficial)
Nós, os abaixo-assinados, acreditamos que é necessária uma definição mínima de entrega contínua (Continuous Delivery, CD) para a melhoria do fluxo de entrega e cumprimento dos resultados supracitados. Embora os nossos contextos possam ser diferentes, existem práticas universais consideradas comuns. Ao defini-las, é possível:
- Introduzi-las aos novos praticantes, de forma consistente
- Discutir as práticas de engenharia que abrangem a entrega contínua
- Ajudar-nos mutuamente, melhorando as capacidades atuais
Só através da adoção de práticas elementares é que se torna possível testemunhar os benefícios da entrega contínua.
As práticas descritas em seguida são o mínimo, ou seja, um ponto de partida. O resultado esperado é a melhoria da rapidez, qualidade e segurança da pipeline de entrega.
Entrega Contínua
A entrega contínua (CD) é a disciplina de engenharia que consiste na entrega de todas as alterações, de forma padronizada, com segurança. Ela cobre um extenso espetro de atividades, dependendo do que está a ser entregue. Porém, há comportamentos e habilidades que devem ser considerados, em todos os contextos, para que o processo possa ser classificado como “entrega contínua”.
As atividades mínimas exigidas para o CD são:
- Uso de Integração contínua
- A pipeline aplicational é a única forma possível de fazer deploy para qualquer ambiente
- A pipeline decide a possibilidade dessas mudanças serem replicadas para o ambiente produtivo. Esse veredicto é definitivo
- Os artefactos criados pela pipeline respeitam sempre a definição de deployable da organização
- Artefacto imutável. Não existem mudanças manuais após o commit
- Todo o desenvolvimento de funcionalidades é suspenso quando a pipeline se encontra em falha (em vermelho)
- Ambientes de teste semelhantes ao ambiente produtivo
- Rollback conforme necessário
- A configuração da aplicação é deployed com o artefacto
Integração Contínua
A integração contínua (Continuous Integration, CI) é a atividade que consiste em frequentemente integrar o trabalho desenvolvido no trunk do sistema de controlo de versões e verificar que esse trabalho, dentro do que se conhece, é passível de ser released.
As atividades mínimas necessárias ao CI são:
- Trunk-based development
- O trabalho integra em trunk, no mínimo, diariamente
- O trabalho tem testes automatizados antes do merge em trunk
- O trabalho é testado automaticamente com outras mudanças no merge
- Todo o trabalho em funcionalidades é suspenso quando a build falha
- Novo trabalho não quebra o trabalho já entregue
Trunk-Based Development
O Trunk-based development (TBD) é um padrão de branching essencial para cumprimento dos requisitos de CI. Impede a perda de trabalho, o risco de mudanças corrompidas devido à resolução de conflitos do merge e também reduz o desperdício de movimento que aumenta o tamanho do batch de mudanças.
Os atividades mínimas essenciais para o TBD são:
- Todas as mudanças integram em trunk
- No caso de serem usados branches:
- Eles têm sempre origem em trunk
- Eles re-integram sempre em trunk
- Eles são de curta-duração e são removidos depois do merge
Por que construímos este manifesto?
Para obter informações acerca do Mínimo CD e respostas a outras questões comuns, por favor lê as FAQ (versão inglesa).
Queres contribuir?
Lê as nossas diretrizes de contribuição (versão inglesa).
Signatários
Os signatários assinaram a versão original em inglês e a lista atual de nomes é publicada apenas nessa versão.
Tradução
Esta tradução é um esforço de toda a comunidade, que tem como objetivo a disseminação destes conceitos, para lá das barreiras linguísticas. Os signatários abstêm-se de afirmar a exatidão da tradução.
Traduzido da versão: c6c522c, 2021-12-13