Projetar pipeline de build/test/deploy
Use este guia como lente principal para esta situação.
DevOps e entrega Guia para IA
DevOps na Prática
Automação, integração contínua, infraestrutura como código, pipeline de entrega, monitoramento e segurança.
- Autor
- Danilo Sato
- 262 páginas
- Formato do guia
- Markdown no padrão dos modelos originais + instruções operacionais para IA
Orientação
Como utilizar este .md
Não apenas “anexe e peça para programar”. Dê papel, contexto e critérios.
Anexe o .md junto com o requisitoO guia passa a ser a referência de engenharia para aquela tarefa.
Descreva contexto e restriçõesStack, estrutura atual, legado, prazo, compatibilidade, usuários e comportamento que não pode mudar.
Peça diagnóstico antes de soluçãoA IA deve identificar o problema e escolher somente os princípios relevantes.
Implemente em passos verificáveisEvite reescrita ampla. Peça testes, critérios de aceite e plano de rollback quando necessário.
Faça revisão contra o guiaNo final, peça divergências, riscos, trade-offs e pontos ainda não cobertos.
Casos de uso
Quando este guia é especialmente útil
Definir infraestrutura reproduzível
Use este guia como lente principal para esta situação.
Planejar observabilidade e feedback de produção
Use este guia como lente principal para esta situação.
Reduzir risco com entregas pequenas e automação
Use este guia como lente principal para esta situação.
warning Limite de uso
Não reduza DevOps a uma ferramenta ou pipeline; colaboração, feedback e operação são parte do sistema.
Não reduza DevOps a uma ferramenta ou pipeline; colaboração, feedback e operação são parte do sistema.
Prompt pronto
Modelo para começar
Use o guia “DevOps na Prática” anexado como referência para analisar este projeto. Antes de alterar código: 1. Faça um diagnóstico do problema no contexto do projeto. 2. Identifique quais princípios do guia realmente se aplicam. 3. Compare a solução atual com uma alternativa mais simples. 4. Proponha uma mudança incremental e reversível. 5. Defina testes e critérios de aceite. 6. Ao final, revise a implementação contra o guia e liste trade-offs. Contexto: [DESCREVA o sistema, stack, estado atual e cenário da mudança] Objetivo: [DESCREVA o resultado observável que deve existir ao final] Restrições: [DESCREVA o que não pode mudar, compatibilidade e limites técnicos]
Exemplo preenchido — o que o usuário pode descrever
Use o modelo acima com dados concretos do projeto. O exemplo abaixo mostra o nível de detalhe esperado.
Contexto: Aplicação é publicada manualmente no Cloudflare/servidor e o processo depende de passos executados por uma pessoa. Objetivo: Desenhar pipeline de build, testes e deploy reproduzível, com validação antes da publicação e possibilidade de rollback. Restrições: Não expor segredos; deploy deve ser auditável; falha em teste bloqueia produção; mudanças de infraestrutura devem ser versionadas.
ContextoStack, versões, arquitetura, página/módulo afetado, estado atual e comportamento existente.
ObjetivoResultado observável para o usuário ou para o sistema; diga o que deve funcionar ao final.
RestriçõesO que não pode mudar, compatibilidade, segurança, acessibilidade, performance, prazo e limites de escopo.
1. Diagnosticar
Peça análise do código e do problema antes de aplicar qualquer padrão ou princípio.
2. Decidir
Exija justificativa: por que esta técnica é adequada e quais alternativas foram descartadas.
3. Verificar
Finalize com testes, checklist, riscos e critérios de aceite.