Capítulo 14 — Engenharia de software
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Ferramentas são produtos"]
N1["14.2 Bloqueie a ampliação"]
N2["14.3 Fixtures de CI"]
N3["14.3b Trens de release vs. hotfixes"]
N4["14.1b Modelo de branches"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Ferramentas são produtos"]
N1["14.2 Bloqueie a ampliação"]
N2["14.3 Fixtures de CI"]
N3["14.3b Trens de release vs. hotfixes"]
N4["14.1b Modelo de branches"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]
[14.1 Ferramentas são produtos]
|
v
[14.2 Bloqueie a ampliação]
|
v
[14.3 Fixtures de CI]
|
v
[14.3b Trens de release vs. hotfixes]
|
v
[14.1b Modelo de branches]
|
v
[Nota de prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem
Você vai (1) colocar as ferramentas de avaliação sob controle de versão, com revisão; (2) bloquear mudanças que ampliem o escopo; (3) manter a CI só com fixtures sintéticos.
14.1 Ferramentas são produtos
O TrackScope e o FindingsDesk são software. Precisam de repositórios, revisão de código, releases com tags e changelogs. Uma ROE que cita "TrackScope" sem versão está incompleta; cite TrackScope v0.9.2 ou o SHA do git usado. Sem uma versão, dois engenheiros podem rodar builds diferentes e discordar sobre o que a ferramenta negou. Tags e changelogs tornam essa discordância verificável. A revisão de código pega uma verificação de escopo que falha aberta antes que ela chegue a um engajamento. Sam cola o SHA nas anotações do kickoff e se recusa a começar se o binário em execução for diferente.
14.2 Bloqueie a ampliação
Merges que acrescentam um CIDR, abrem uma porta ou removem uma entrada da lista de exclusão exigem um segundo revisor e um ticket de autorização vinculado. Merges que só restringem o escopo podem ser mais leves. Codifique isso no CODEOWNERS ou numa verificação obrigatória que compare os arquivos de escopo. Ampliar o escopo é um evento de autorização, então precisa da mesma atenção dupla que uma mudança de ROE. A restrição pode andar mais rápido porque não consegue criar novos alvos. Uma verificação obrigatória sobre as diferenças de escopo impede uma adição silenciosa de CIDR num pull request grande. Sam vincula cada merge de ampliação ao ticket de aprovação por escrito do cliente.
14.3 Fixtures de CI
A integração contínua roda os laboratórios e os testes unitários sobre dados sintéticos. Nunca aponte a CI para uma rede de cliente. Os dados de semente ficam no repositório; os segredos de engajamentos reais ficam num cofre e nunca nos logs da CI. Uma CI capaz de alcançar uma rede de cliente transformaria cada teste quebrado numa possível sondagem. Fixtures sintéticos mantêm as falhas locais e reproduzíveis. Segredos em logs viram incidentes; cofres os mantêm fora da saída do build. Os pipelines de Sam não têm rotas para as redes dos engajamentos e falham se alguém acrescentar uma.
Caso sintético — Riverstone Transit. Um PR acrescentou 10.30.0.0/16 ao escopo "para o mês que vem". A verificação de diferenças de escopo da CI bloqueou o merge até que o ticket AUTH-442 fosse vinculado e um segundo dono aprovasse.
14.4 Erros e limites
As tags de versão podem se afastar do que os operadores de fato rodam; registre a versão em execução no log do engajamento logo no início. Os operadores instalam hotfixes à mão e esquecem de atualizar a tag na lista de verificação. Registrar a versão em execução no início torna a divergência visível antes de o tráfego começar. Sam compara essa linha de log com a versão fixada na ROE e interrompe a janela em caso de discordância, até que os operadores instalem o build fixado ou a ROE seja revisada. Um post-it num notebook não é uma fixação de versão.
14.3b Trens de release vs. hotfixes
As melhorias normais seguem num trem de release com os Laboratórios I/II. Hotfixes de segurança podem pular funcionalidades, mas não a verificação: um pacote mínimo de regressão de falha fechada é obrigatório. Marque os hotfixes com clareza, para que um engajamento possa fixar o build do trem ou o SHA do hotfix de olhos abertos. Correções de segurança ainda precisam provar o comportamento de falha fechada, mesmo quando as funcionalidades esperam. Fixar de olhos abertos significa que o cliente sabe qual binário produziu a evidência. Sam mantém o pacote de regressão pequeno, para que os hotfixes continuem rápidos sem pulá-lo.
14.1b Modelo de branches
Use branches de vida curta com CI obrigatória sobre fixtures sintéticos. Branches de funcionalidade de vida longa se afastam das correções de segurança na main e recriam merges que falham abertos. Proteja a main com revisores obrigatórios e verificações de status nomeadas segundo as linhas de segurança do Laboratório I. Branches curtas recebem as correções de segurança da main em vez de reinventá-las semanas depois. Verificações obrigatórias nomeadas segundo as linhas do Laboratório I tornam impossível pular a suíte de segurança com uma aprovação casual. Sam apaga branches abandonadas toda semana, para que a divergência não possa se esconder. Uma branch que fica mais de uma semana atrás da main precisa ser rebaseada e passar de novo nas verificações do Laboratório I antes da revisão.
Nota de prática
As fixações de versão aparecem na lista de verificação do kickoff do engajamento, ao lado do hash da ROE. Os operadores leem a fixação em voz alta antes de a janela abrir, para que ninguém rode silenciosamente um build de notebook. Se a fixação e o binário em execução discordarem, a janela não começa até que alguém registre uma nota AUTH ou faça o rollback. Esse ritual evitou mais incidentes do que qualquer banner na interface, porque obriga uma pessoa a olhar para o SHA enquanto o cliente ainda está na chamada.
Exercícios
- EX040 — Linha de versão. Escreva a frase de método que fixa o TrackScope para um engajamento. Rubrica: 3 = nome, versão/SHA, data de carga; 2 = nome+versão; 1 = só o nome; 0 = nada.
- EX041 — Regra de bloqueio. Escreva uma política de merge de uma frase para os arquivos de escopo. Rubrica: 3 = segundo revisor + ticket de autorização para ampliar; 2 = só o revisor; 1 = vago; 0 = nada.
- EX042 — Fronteira da CI. Por que a CI nunca pode usar credenciais de VPN do cliente? Rubrica: 3 = risco de automação não autorizada, vazamento de segredos nos logs, não determinismo; 2 = um motivo sólido; 1 = vago; 0 = errado.
Síntese
Trate o software de avaliação como software de produção: versões, bloqueios de revisão e CI sintética.
Continue estudando — capítulo 14 de 50
← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →