Como implementar um ambiente de teste congelado?

Aqui está uma citação parcial de uma resposta à pergunta sobre " Como evitar instabilidades causadas por integração contínua em ambientes de teste? ":

Esse ambiente geralmente congela durante os testes.

Minha pergunta: o que são implementações de exemplo de um ambiente congelado? Ou seja, o que você pode fazer para impor tecnicamente que ninguém (exceto se permitido por um usuário autorizado como um gerente de release) será capaz de alterar qualquer coisa nesse ambiente congelado.

Esclarecimentos :

• Não estou falando sobre o que (acho) é chamado de "períodos congelados" durante (por exemplo) o processamento no final do ano nos bancos. Trata-se de não poder aplicar (repetir) alterações nos ambientes de produção, para reduzir o risco de novas alterações / correções serem introduzidas que possam impactar o processamento no final do ano.

• Suponha que os usuários que têm permissão para aprovar / aplicar alterações de qualquer maneira (como o gerente de versão no meu exemplo), o façam apenas em casos excepcionais. Por exemplo, onde durante o teste é encontrado um problema de alta gravidade, para o qual adiar uma correção para uma próxima versão não é uma opção (pois a produção seria arriscada se a liberação fosse ativada sem essa correção).

• Isso poderia ser apenas sobre a suspensão de qualquer atualização automatizada durante o tempo do teste. O ponto é: evitar que alguém atualize um Aplicativo A para a versão Y enquanto outra equipe ainda está testando o aplicativo B na versão X, que depende do aplicativo A. Isso pode significar ter uma proteção para evitar que uma equipe de teste exija uma atualização de uma dependência em teste.

Minha resposta no contexto da pergunta é um ambiente de teste muito caro (como mainframes ou equipamentos de telecomunicação muito grandes, por exemplo) que deve ser compartilhado por vários usuários para vários testes, mesmo simultaneamente.

Em muitos casos, esse equipamento possui um sistema de gerenciamento de software responsável por, entre outras coisas, controlar a (des) instalação / atualização / redução de software / etc. O que deveria ter algum mecanismo para bloquear essas operações (que seria, se eu entendi a pergunta corretamente, equivalente a congelar o ambiente) com base em algumas políticas mais ou menos programáveis.

Nesse caso, uma política específica pode ser desenvolvida exatamente para oferecer suporte ao cronograma de congelamento desejado e necessário para o ambiente de teste. Idealmente automatizado, aceitando gatilhos de congelamento / descongelamento de fontes externas, que podem ser os wrappers de execução de teste ou sistemas de CI. E talvez com substituições acionadas por humanos, se necessário.

Obviamente, esse recurso do sistema de gerenciamento de software seria útil ao testar outros componentes do equipamento, mas talvez não para testes do próprio sistema de gerenciamento de software.

O TeamCity possui um recurso de compilação de Recursos Compartilhados, que permite definir um recurso do qual várias Definições de Compilação dependem. As Definições de compilação podem exigir um bloqueio de leitura ou um bloqueio de gravação, você também pode definir se esses bloqueios são exclusivos ou permitem um grau de paralelismo.

Se fizermos as seguintes suposições sobre um ambiente compartilhado chamado PreProd :

• Existe um Recurso Compartilhado chamado "PreProd".
• Todas as definições de construção, como implantações, que fazem qualquer alteração nesse ambiente, recebem um bloqueio de gravação exclusivo no "PreProd".
• Todas as definições de construção, como testes não restritivos, que executam operações somente leitura no ambiente, utilizam um bloqueio de leitura não exclusivo no "PreProd".
• O TeamCity é o único processo que pode fazer qualquer coisa no PreProd, embora talvez por meio de outra ferramenta.

Portanto, o seguinte é verdadeiro:

• Quando uma implantação está acontecendo, nada mais pode usar o PreProd, eles serão colocados na fila.
• Quando um teste está em execução, qualquer implantação fica na fila até que os testes sejam concluídos.

Você pode usar um mecanismo semelhante com o Jenkins usando o plug-in Exclusão . De fato, você pode criar essa funcionalidade em qualquer processo usando bloqueio ou semáforo - por exemplo, Apache ZooKeeper ou HashiCorp Consul .

Isso soa como um anti-padrão para mim. Acredito que todos ou ninguém devem ter acesso a todos os ambientes.

Se os usuários estiverem subvertendo o processo, eu examinaria seriamente o processo para tentar garantir que ele não esteja atrapalhando as pessoas.

A implementação de um mecanismo automatizado que impõe um estado específico também é útil para incentivar as pessoas a fazer as coisas da maneira certa. Isso pode ser via Gerenciamento de Configuração ou destruir qualquer instância imutável se alguém fizer o SSH nele