O que é um ambiente de staging? A cópia que nunca chega a ser uma cópia

Um ambiente de staging é uma cópia em funcionamento da sua aplicação, tão próxima da produção quanto o orçamento permitir, onde uma versão é verificada antes de pessoas reais lhe chegarem. O mesmo código, a mesma forma de configuração, a mesma estrutura de base de dados, outros dados e outro público.

A ideia é antiga e simples: experimente primeiro onde não importa. O que a torna interessante é que o staging nunca é verdadeiramente uma cópia, e todos os problemas que lhe escapam vêm dessa distância.

Entre o que se situa

A maioria das equipas acaba com três ou quatro ambientes, e as diferenças estão em quem tem autorização para os partir.

• Local é a máquina de quem desenvolve. Parte-se constantemente, e ninguém se importa.
• O staging corre o código que está prestes a sair, com dados de que ninguém sentirá falta. Parte-se de vez em quando, e alguém importa-se um pouco.
• A produção é onde estão os clientes.

Algumas equipas acrescentam um quarto entre o staging e a produção para testes de carga ou de integração, e outras colocam um ambiente de pré-visualização por ramo antes do staging. Os nomes variam mais do que as ideias.

Para que serve

Apanhar o que uma suíte de testes não consegue. Migrações contra uma base de dados com volume real. Assets que só são compilados durante uma implantação. Um valor de configuração que existe numa máquina e não noutra. Nada disso é tocado por um teste unitário.

Ensaiar a própria implantação. Uma versão é um procedimento, e o procedimento também tem erros. Se implantar no staging é o mesmo comando que implantar em produção, já ensaiou aquilo que de outro modo seria feito pela primeira vez no pior momento possível.

Dar a quem não programa um sítio onde olhar. Os testes de aceitação, uma demonstração, uma captura de ecrã para o apoio ao cliente - todos precisam de um sítio real que não seja real.

Como o staging se afasta

Esta é a parte que vale a pena escrever, porque um ambiente de staging que ninguém mantém é pior do que nenhum: produz confiança em vez de informação.

O código afasta-se. Tudo o que é integrado vai para o staging automaticamente; a produção é implantada quando alguém decide. Um staging trinta commits à frente da produção fala-lhe de software que os seus clientes não têm, e o erro que não consegue reproduzir no staging pode simplesmente já estar corrigido lá.

Os dados afastam-se. A produção acumula quinze anos de decisões - contas sem endereço de correio eletrónico, uma encomenda de antes de existir uma coluna, um nome com um apóstrofo. O staging tem o que os seeds lá puseram. A maior parte dos defeitos que chegam aos clientes vive em formas de dados que ninguém se lembrou de criar.

A configuração afasta-se. Uma chave definida num anfitrião e não no outro, um feature flag ligado só num sítio, um serviço externo apontado a uma sandbox que se comporta de forma diferente do original. É a classe de problema para a qual o staging existe e a classe que ele mais vezes provoca.

A escala afasta-se. Um processo web contra doze, uma base de dados com mil linhas contra dez milhões. Uma consulta instantânea no staging pode ser a razão pela qual a produção cai.

Manter a distância honesta

Não é possível fechar a distância, por isso o objetivo é saber onde ela está.

• Implante da mesma forma nos dois. Um comando, um script, nenhum passo manual que exista só num sítio. Se a produção tem um passo que o staging não tem, esse passo nunca foi testado.
• Implante-os em conjunto quando uma alteração abrange os dois. Tudo o que tenha um cliente - uma extensão de navegador, uma aplicação móvel, uma integração com um parceiro - que fala com um ambiente e não com o outro não está no ar em nenhum deles, para quem está a testar.
• Use dados com a forma da produção, não dados de produção. Anonimizados ou gerados, com as formas incómodas incluídas de propósito: a conta vazia, a lista enorme, o apóstrofo. Copiar dados reais de clientes para um ambiente menos protegido é um incidente de privacidade à espera de data.
• Mantenha-o parado quando não for preciso, e conte com que seja um alvo: os ambientes de staging são conhecidos por estarem menos atualizados e mais abertos do que os sistemas que espelham.
• Diga qual é qual. Um banner, uma cor, o que for. Mais cedo ou mais tarde alguém fará uma demonstração na produção ou um teste destrutivo no anfitrião errado, e evitá-lo custa uma linha de CSS.

Quando o staging diz uma coisa e a produção diz outra

Isso não é uma falha do staging, é a informação que o staging existe para lhe dar, e é o momento de descobrir qual dos quatro afastamentos acima a explica.

A primeira pergunta é que build cada um está a correr. A segunda é se acontece o mesmo com os mesmos dados. Ambas são coisas que um relatório deveria dizer, e ambas são os detalhes que costumam faltar em “no staging funciona”.

Uma captura de cada ambiente transforma uma discussão numa comparação: os mesmos passos, dois conjuntos de saída da consola e de registos de rede, e habitualmente uma diferença evidente. O guia do relatório de erro tem o resto do que deve ser incluído, e nomear o ambiente é a linha de que as pessoas se esquecem.

A versão curta

O staging é um ensaio, não uma cópia. O seu valor é proporcional à honestidade com que acompanha as formas em que difere da produção - código, dados, configuração e escala - e uma diferença que conhece é uma limitação, ao passo que uma de que se esqueceu é um falso negativo com um visto verde por cima.