Português

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 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