¿Cómo implementar un entorno de prueba congelado?

Aquí hay una cita parcial de una respuesta a la pregunta sobre " ¿Cómo evitar inestabilidades causadas por la integración continua en entornos de prueba? ":

Este entorno generalmente se congela durante las pruebas.

Mi pregunta: ¿cuáles son las implementaciones de muestra de un entorno congelado? Es decir, qué puede hacer para hacer cumplir técnicamente que nadie (excepto si lo permite un usuario autorizado como un administrador de versiones) podrá cambiar cualquier cosa en un entorno tan congelado.

Aclaraciones :

• No estoy hablando de lo que (creo) se llama "períodos congelados" durante (por ejemplo) el procesamiento de fin de año en los bancos. Se trata de no poder aplicar ningún cambio (repetir) a los entornos de producción, para reducir el riesgo de que se introduzcan nuevos cambios / arreglos que puedan afectar el procesamiento de fin de año.

• Suponga que los usuarios que tienen permiso para aprobar / aplicar cambios de todos modos (como el administrador de versiones en mi ejemplo), solo lo harán en casos excepcionales. Por ejemplo, dónde durante la prueba se encuentra un problema de alta gravedad, para el cual diferir una solución para una próxima versión no es una opción (ya que la producción estaría en riesgo si la versión se activara sin dicha solución).

• Esto podría ser solo sobre la suspensión de cualquier actualización automática durante el tiempo de la prueba. El punto es: evite que alguien más actualice una Aplicación A a la versión Y mientras otro equipo todavía está probando la aplicación B en la versión X que depende de la aplicación A. Esto podría significar tener un guardia para evitar que un equipo de prueba requiera una actualización de una dependencia bajo prueba.

Mi respuesta en el contexto de la pregunta es un entorno de prueba muy costoso (como mainframes o equipos de telecomunicaciones muy grandes, por ejemplo) que se espera que sean compartidos por múltiples usuarios para múltiples pruebas, incluso simultáneamente.

En muchos casos, dicho equipo tiene un sistema de gestión de software responsable, entre otras cosas, de controlar la (des) instalación / actualización / degradación / etc del software. Que debería tener algún mecanismo para bloquear tales operaciones (que sería, si entendiera la pregunta correctamente, equivalente a congelar el entorno) en función de algunas políticas más o menos programables.

En tal caso, se podría desarrollar una política específica exactamente para soportar el programa de congelación deseado necesario para el entorno de prueba. Idealmente automatizado, aceptando disparadores de congelación / descongelación de fuentes externas que podrían ser envoltorios de ejecución de prueba o sistemas de CI. Y tal vez con anulaciones provocadas por humanos, si se considera necesario.

Por supuesto, tal característica del sistema de administración de software sería útil al probar otros componentes del equipo, pero tal vez no para las pruebas del sistema de administración de software en sí.

TeamCity tiene una función de compilación de recursos compartidos que le permite definir un recurso del que dependen varias definiciones de compilación. Las definiciones de compilación pueden requerir un bloqueo de lectura o un bloqueo de escritura, también puede definir si estos bloqueos son exclusivos o permiten cierto grado de paralelismo.

Si hacemos las siguientes suposiciones sobre un entorno compartido llamado PreProd :

• Existe un recurso compartido llamado "PreProd".
• Todas las definiciones de compilación, como las implementaciones, que realizan cualquier cambio en ese entorno toman un bloqueo de escritura exclusivo en "PreProd".
• Todas las definiciones de compilación, como las pruebas no restrictivas, que realizan operaciones de solo lectura en el entorno tienen un bloqueo de lectura no exclusivo en "PreProd".
• TeamCity es el único proceso que puede hacer algo en PreProd, aunque tal vez a través de otra herramienta.

Por lo tanto, lo siguiente es cierto:

• Cuando se realiza una implementación, nada más puede usar PreProd, se colocarán en la cola.
• Cuando se ejecuta una prueba, cualquier implementación se colocará en cola hasta que se completen las pruebas.

Puede usar un mecanismo similar con Jenkins usando el complemento Exclusion . De hecho, podría incorporar esta funcionalidad en cualquier proceso utilizando bloqueo o semáforo, por ejemplo Apache ZooKeeper o HashiCorp Consul .

Esto suena como un anti patrón para mí. Creo que todos o nadie debería tener acceso a todos los entornos.

Si los usuarios están subvirtiendo el proceso, analizaría seriamente el proceso para tratar de asegurarme de que no se interponga en el camino de las personas.

Implementar un mecanismo automatizado que haga cumplir un estado específico también es útil para alentar a las personas a hacer las cosas de la manera correcta. Esto puede ser a través de Config Management o destruyendo cualquier instancia inmutable si alguien lo hace