Onze produtos, um sistema de produção, e a ordem em que lemos as provas

Um estúdio deste tamanho não pode sustentar onze produtos fazendo onze lançamentos. Sustenta-os porque as partes de um lançamento que são idênticas de cada vez — materiais de loja, listas de verificação de publicação, a canalização das subscrições, capturas de ecrã, documentos de privacidade, o próprio canal de publicação — são feitas uma vez, num sistema, em vez de uma vez por produto à mão.

Até aqui a metade óbvia, e não é a interessante. Partilhar infraestrutura é uma troca bem compreendida. A parte que continua a correr mal é saber o que é verdade sobre um produto que publicou há três semanas.

Duas regras que tornam a automação reiniciável

O trabalho no sistema é identificado por uma impressão determinista das suas próprias entradas. Um disparo duplicado, uma nova tentativa ou um bloqueio com reinício resolvem-se todos para a mesma identidade, pelo que o sistema não pode produzir duas vezes nem publicar duas vezes. Essa única propriedade é o que torna seguro tentar de novo, e poder tentar de novo em segurança é a diferença entre uma automação que se pode deixar a correr e uma que alguém tem de vigiar.

A segunda regra é que a publicação fica atrás de uma pessoa. Não porque a automação esteja inacabada — porque o custo de uma publicação errada é assimétrico, e um portão que nunca é usado é barato enquanto um portão que falta uma vez não é. Nada saiu deste estúdio sem alguém o dizer.

A falha que não é um erro

A 30 de setembro dois produtos entraram em linha na App Store. Este sítio dizia que um deles estava em beta e não constava publicamente em nenhuma das duas lojas. Nada neste repositório estava errado, e nenhuma revisão o poderia ter apanhado, porque um lançamento é um acontecimento que ocorre fora do repositório: nenhum ficheiro muda, por isso não há diferença para ler nem teste que possa falhar.

É esse o argumento todo a favor de um portão antes da implantação em vez de um hábito. Um programa pergunta à Apple cada identificador de pacote, lista todas as aplicações da conta de desenvolvedor e pede ao Google Play cada página de pacote. Corre antes de uma implantação, não quando algo parece estranho — porque quando algo parece estranho, já pareceu correto durante três dias.

Em que documento acreditar

O mesmo erro já foi cometido sete vezes neste estúdio, e só um foi por descuido. Os outros seis tinham todos a mesma forma: uma afirmação retirada do documento narrativo de um projeto enquanto provas legíveis por máquina estavam na mesma pasta, mais recentes, a dizer outra coisa.

O Veyra é o exemplo trabalhado. A sua página neste sítio dizia que a geração nunca tinha corrido e que nunca tinham sido carregados pesos de modelo. Isso vinha de um documento de estado e de um readme, ambos datados de 11 de setembro, e foi repetido aqui durante duas semanas. Entretanto, no mesmo repositório, havia um ficheiro retirado de um telemóvel físico que registava duas execuções reais de geração — quatro candidatos cada, cada imagem de um tamanho diferente, marcadas com o modelo real, com tempos lidos da própria base de dados do aparelho. A página subestimou o seu próprio produto durante quinze dias, o que é uma falha mais gentil do que exagerá-lo e continua a ser uma página falsa.

Por isso a ordem está escrita, e um nível inferior nunca prevalece sobre um superior, por recente que seja e por seguro que soe:

• Estado autenticado do fornecedor — o que a própria loja diz, lido com sessão iniciada.
• Artefactos publicados e provas legíveis por máquina — os metadados de uma compilação de publicação, uma base de dados retirada de um aparelho, uma resposta capturada, uma etiqueta.
• Código e configuração atuais — os ficheiros que a compilação carrega de facto.
• Documentos de aceitação datados — prosa, mas escrita contra uma execução que aconteceu.
• Narrativa de estado e de passagem — um readme, um ficheiro de estado, uma passagem.
• Documentos de planeamento e briefings — incluindo o briefing que apresentou um produto neste sítio.

A hierarquia não diz nada sobre quem escreve com cuidado. Diz algo sobre o que se deteriora. Uma ficha de loja muda quando o produto muda; um readme muda quando alguém se lembra.

Para que serve de facto um sistema partilhado

Todas as regras acima começaram por algo concreto correr mal num produto, e todas vivem hoje no sistema partilhado e não na cópia desse produto. É esse o juro composto a sério: não que o quinto lançamento seja mais barato do que o primeiro, embora seja, mas que o quinto lançamento não possa repetir os erros dos quatro anteriores — porque o erro é um teste que falha num sítio que não pertence a nenhum dos dois produtos.