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 (versão inglesa) (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).

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?

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: 52efc0bd, 2023-02-06