Escrito tarde da noite, depois de mais um deploy que deu certo por sorte.
Este texto não é um padrão nem uma política. É o que muitos de nós pensamos nos corredores, nas retrospectivas que terminam sem mudança e nos incidentes de madrugada, e que raramente colocamos por escrito.
Ele existe porque crescemos. Cada time encontrou o seu jeito de entregar, e cada jeito funcionou bem o suficiente para não ser questionado. Somados, eles formam um sistema que ninguém desenhou e que todos pagam para manter.
O que pensamos e não dizemos
- Copiamos pipelines de um repositório para outro e chamamos isso de padrão.
- Quando aparece uma vulnerabilidade crítica, a primeira pergunta é "onde estamos usando isso?", e ninguém sabe responder em menos de um dia.
- Aprovação manual nos dá sensação de controle, mas quem aprova raramente sabe o que está aprovando.
- Há segredos em variáveis de pipeline que ninguém lembra quem criou.
- O que testamos em homologação nem sempre é o mesmo binário que vai para produção.
- Escrevemos documentos de padrões que ninguém lê, e depois culpamos os times por não segui-los.
- Medimos esforço (horas, tickets, story points) em vez de resultado (entregar com segurança, recuperar rápido).
- Tratamos governança como algo que se impõe aos times, quando ela deveria ser algo que a plataforma faz pelos times.
Nada disso é culpa de uma pessoa. É o resultado natural de crescer sem uma plataforma. Por isso a solução também não é cobrar mais das pessoas: é mudar o sistema.
No que acreditamos
- O caminho certo deve ser o caminho mais fácil. Se seguir o padrão dá mais trabalho do que ignorá-lo, o problema é o padrão.
- O template é a política. Uma regra que não está no código é só uma sugestão.
- Construímos uma vez e promovemos o mesmo artefato. O que foi testado é o que vai para produção, sem exceção.
- Confiança se prova, não se declara. Todo artefato carrega sua origem, seus componentes e sua assinatura.
- Ninguém deve guardar um segredo. Nem pessoas, nem pipelines.
- Recuperar rápido vale mais do que nunca errar. Rollback em minutos é mais seguro do que três aprovações.
- Medimos resultados, não esforço. Frequência, lead time, falhas e recuperação dizem a verdade.
- Exceção tem dono e prazo. Desvio sem data de validade é só dívida com outro nome.
- A plataforma é um produto, e os desenvolvedores são os clientes. Se eles não querem usar, o produto ainda não está bom.
O que vamos fazer
Cada compromisso tem uma prática detalhada em docs/praticas e um domínio de auditoria que o mede em docs/maturidade.
| Compromisso | Prática | Domínio |
|---|---|---|
| Uma organização, poucos projetos, tudo como código | 02 · Estrutura organizacional | D1 |
| Toda mudança entra por PR revisado, rastreável e validado | 03 · Repositórios e fluxo | D2 |
| Nenhum time escreve pipeline do zero: o golden path vem pronto | 04 · Pipelines como produto | D3 |
| Saberemos o que roda em produção, de onde veio e quem assinou | 05 · Supply chain | D4 |
| Produção só aceita o que passou pelos checks, rodando em agentes que não guardam nada | 06 · Ambientes e agentes | D5 |
| Acesso por grupo, identidades sem segredo, admins contados nos dedos | 07 · Identidade e acesso | D6 |
| Separar implantar de liberar; voltar atrás em minutos | 08 · Deploy e release | D7 |
| Os números DORA ficam à vista de todos, sempre | 09 · Observabilidade | D8 |
| Padrões vivem no template, exceções vencem, nada roda em EOL sem dono | 10 · Governança de arquitetura | D9 |
Como vamos provar
Promessa sem medição é só intenção. Cada compromisso tem indicadores objetivos, coletados das próprias ferramentas, que classificam a organização de N1 (Inicial) a N5 (Otimizado). O modelo completo está em docs/maturidade, e sua fonte única é modelo/indicadores.yaml.
- A régua é pública. Qualquer pessoa pode rodar a mesma coleta e chegar ao mesmo número.
- O elo mais fraco limita a nota. Não adianta ser excelente em pipeline e frágil em identidade.
- O salto que importa é de N3 para N4, quando a prática deixa de depender de disciplina e passa a ser garantida pela plataforma.
- Medimos para melhorar o sistema, não para ranquear pessoas. Um indicador ruim é um problema da plataforma a resolver, não um time a culpar.
O que pedimos a cada um
| Quem | O que pedimos | O que oferecemos em troca |
|---|---|---|
| Desenvolvedores | Usar o golden path e reportar onde ele atrapalha | Pipeline pronto, feedback rápido no PR, menos burocracia para mudanças padrão |
| Líderes técnicos | Registrar decisões em ADR e assumir as exceções do seu domínio | Autonomia dentro de limites claros, e não aprovações caso a caso |
| Time de plataforma | Tratar templates, agentes e a própria org como produto, com roadmap e SLO | Um único lugar para corrigir problemas que hoje se repetem em cada repo |
| Segurança | Transformar requisitos em gates automatizados em vez de checklists | Visibilidade contínua e evidência pronta para auditoria |
| Gestão | Patrocinar a migração e aceitar que, no começo, padronizar custa velocidade | Previsibilidade, risco mensurável e um número honesto sobre onde estamos |
O preço
Seria desonesto prometer que isto sai de graça.
- Vamos perder atalhos. O push direto "só desta vez", o pipeline com um step a menos, o segredo colado para resolver rápido.
- Vamos ficar mais lentos antes de ficar mais rápidos. Migrar centenas de repos para um template comum leva meses, e no começo os gates vão bloquear coisas que hoje passam.
- Vamos expor números desconfortáveis. A primeira auditoria provavelmente vai mostrar um nível mais baixo do que imaginamos.
- Vamos fazer menos coisas. Menos ferramentas, menos variações, menos exceções, e cada uma melhor feita.
Aceitamos esse preço porque a alternativa é continuar pagando o custo invisível: incidentes repetidos, respostas lentas a vulnerabilidades e o mesmo trabalho refeito em cada time.
O chamado
Não precisamos de todo mundo convencido no primeiro dia. Precisamos de um time disposto a ser o primeiro no golden path, de um pipeline que prove que dá para ser seguro e rápido ao mesmo tempo, e de uma auditoria que diga honestamente de onde estamos partindo.
O resto vem pelo exemplo. Boas plataformas não convencem por decreto: elas convencem porque, depois de usá-las, ninguém quer voltar atrás.
Menos, melhor. Entregar com segurança é responsabilidade de todos, e a plataforma existe para tornar isso fácil.
Se você leu até aqui e concorda com pelo menos uma linha, abra uma issue ou um pull request. É assim que um manifesto deixa de ser de uma pessoa e passa a ser de todos.