Português Brasileiro

Mínimo viável para a Entrega Contínua

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 contínua 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 e segura. Ela cobre um amplo espectro de atividades, dependendo do que está sendo 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
• O delivery pipeline é a única forma possível de fazer deploy para qualquer ambiente
• O pipeline decide se as mudanças atendem ou não os requisitos para entrada em produção. Esse veredicto é definitivo
• Os artefatos criados pelo pipeline respeitam sempre a definição de deployable da organização
• Artefato imutável (não existem mudanças manuais após o commit)
• Todo o desenvolvimento de funcionalidades é suspenso quando o pipeline falha
• Ambiente de testes semelhante ao ambiente produtivo
• Rollback sob demanda
• A configuração da aplicação é implantada junto com o artefato

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 controle de versões e verificar que esse trabalho, tanto quanto podemos afirmar, é 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
• Trabalho novo não quebra trabalho entregue

Trunk-Based Development

O Trunk-based development (versão inglesa) (TBD) é um padrão de branching mandatório para cumprimento dos requisitos de CI. Evita 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.

As atividades mínimas necessárias 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 leia o FAQ (versão inglesa).

Começando a jornada

Dúvidas sobre como começar? Confira algumas recomendações (versão inglesa).

Contribuindo

Você quer enviar uma tradução, boas práticas, sugestões ou um relato de experiência?

Leia as nossas diretrizes de contribuição (versão em inglês).

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, superando as barreiras linguísticas. Os signatários abstêm-se de afirmar a exatidão da tradução.

Traduzido da versão: 1ba1d25, 2023-04-18