Quanto os ambientes de preview realmente custam

Os ambientes de preview são uma das iniciativas de maior impacto que uma equipe pode ativar. Um reviewer clica em um link e usa a mudança em vez de ler um diff e tentar imaginá-la. O design identifica problemas antes do merge. QA deixa de ser uma fase.

Eles também são o item com maior probabilidade de triplicar silenciosamente sua fatura, e o motivo é uma conta que ninguém faz no momento em que ativa o recurso.

A conta

O custo do ambiente de preview cresce de acordo com o número de pull requests abertas, não com o número de pessoas na equipe nem com o número de merges.

Uma equipe de quatro pessoas, com uma cultura saudável de code review, pode ter de cinco a oito PRs abertas a qualquer momento. Se cada uma provisiona uma cópia completa da sua stack, você está executando de cinco a oito cópias de produção além da própria produção. Uma stack que custa US$ 30 por mês para executar agora custa US$ 180–270, e nada disso apareceu na estimativa de ninguém, porque a estimativa considerava um único ambiente.

Pior: PRs abertas coincidem com os momentos em que você menos pode se dar ao luxo de ter surpresas: antes de um release, durante um refactor, quando alguém está de férias e sua branch permanece aberta por três semanas.

Para onde o dinheiro realmente vai

Nem todas as partes de um preview custam o mesmo, e saber a diferença é o que torna o custo controlável.

Application containers — custo moderado e que vale a pena. Esta é a parte que você realmente quer. Também é a parte que escala bem para baixo, porque um preview não precisa da memória de produção.

Bancos de dados — a parte cara. Um banco de dados dedicado por preview é o maior contribuidor individual para o custo e, geralmente, o menos necessário. A maioria dos reviews não precisa de um banco de dados isolado; precisa de um banco com dados plausíveis.

Minutos de build — invisíveis e cumulativos. Cada push em uma PR aberta dispara um novo build. Uma branch com quarenta commits ao longo de duas semanas gera quarenta builds. Esse é um custo real que nunca aparece como um recurso em execução, então escapa completamente da auditoria mental.

Egress — pequeno por preview, grande no total. URLs de preview são descobertas e rastreadas. Um crawler que baixa seus assets de oito ambientes de preview está fazendo oito vezes o trabalho que faz em produção, e você paga por tudo isso.

Quatro medidas que reduzem o custo sem perder o valor

Compartilhe o banco de dados

Para a maioria das mudanças, os previews podem compartilhar um único banco de dados populado com dados representativos. Reserve bancos isolados para as PRs que realmente precisam deles — migrations, mudanças de schema e qualquer operação destrutiva.

A regra que funciona na prática: banco de dados isolado somente quando a PR altera o schema. Todo o resto é compartilhado.

Reduza o tamanho do preview

Um preview que atende a um único reviewer não precisa dos recursos de produção. Metade da memória e uma fração da CPU geralmente são imperceptíveis para quem está fazendo o review e reduzem consideravelmente o custo.

dockup resources my-project/my-api --memory 512 --cpu 0.5

Faça-os expirar

Esta é a mudança de maior impacto. Um preview não deve sobreviver à sua pull request.

A remoção automática após o merge ou o fechamento é o mínimo esperado. O que costuma pegar as equipes de surpresa é a PR abandonada — a branch que alguém abriu, deixou de acompanhar e nunca fechou. Esses ambientes continuam executando por meses.

Uma idade máxima é a proteção adicional que vale a pena ter: qualquer preview com mais de, digamos, quatorze dias é removido independentemente do estado da PR. Se alguém precisar dele novamente, basta executar um comando.

Mantenha-os fora das buscas

URLs de preview são indexadas. Isso é ruim por dois motivos — conteúdo duplicado competindo com seu site de produção e tráfego de crawlers pelo qual você paga em ambientes que ninguém está usando.

dockup noindex my-project/my-api --on

No Dockup, os previews de PR são configurados por serviço e podem ser ativados ou desativados explicitamente, em vez de serem uma configuração global herdada:

dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api

Listá-los é a parte que as equipes deixam de fazer e depois lamentam. Ambientes que você não consegue enumerar são ambientes pelos quais está pagando sem saber.

A auditoria que vale a pena fazer uma vez por mês

Três perguntas, cinco minutos:

1. Quantos previews estão em execução? Compare esse número com a quantidade de PRs que estão realmente abertas.
2. Qual é a idade do preview mais antigo? Qualquer um com mais de duas semanas quase certamente foi abandonado.
3. Quais têm seu próprio banco de dados? Qualquer preview que não corresponda a uma mudança de schema provavelmente não precisa de um banco próprio.

A maioria das equipes encontra pelo menos um ambiente de uma PR que foi mergeada meses atrás, continua em execução e continua gerando custos.

Como obter o valor sem surpresas

Nada disso é um argumento contra os ambientes de preview. É um argumento para tratá-los como infraestrutura com um ciclo de vida, e não como uma checkbox.

As equipes que fazem isso corretamente adotam três práticas: reduzem o tamanho dos previews, fazem os previews expirarem e compartilham o que pode ser compartilhado com segurança. Isso normalmente mantém toda a infraestrutura de previews abaixo do custo de um único serviço de produção — um preço em que o investimento claramente vale a pena.

As equipes que se surpreendem são as que ativaram o recurso uma vez, fizeram tudo certo e nunca mais olharam a lista.

Perguntas frequentes

Os ambientes de preview custam tanto quanto a produção? Por ambiente, podem custar, se forem provisionados de forma idêntica. Com recursos reduzidos e um banco de dados compartilhado, um preview normalmente custa uma fração do custo de produção.

Cada preview deve ter seu próprio banco de dados? Somente quando a mudança altera o schema. Compartilhar um único banco populado cobre a maioria dos reviews e elimina o maior custo.

O que acontece com um preview quando a PR é fechada? Ele deve ser destruído automaticamente. Caso contrário, você acumulará ambientes de PRs das quais ninguém mais se lembra.

Os ambientes de preview prejudicam o SEO? Podem prejudicar, se forem indexados — conteúdo duplicado competindo com suas páginas de produção. Marque-os como noindex, o que também impede que crawlers gerem tráfego pelo qual você paga.