Come implementare un ambiente di test congelato?

Ecco una citazione parziale da una risposta alla domanda su " Come evitare instabilità causate dall'integrazione continua negli ambienti di test? ":

Questo ambiente di solito si blocca durante i test.

La mia domanda: quali sono le implementazioni di esempio di un ambiente ghiacciato? Cioè cosa puoi fare per imporre tecnicamente che nessuno (tranne se consentito da un utente autorizzato come un gestore delle versioni) sarà in grado di cambiare qualsiasi cosa in un ambiente così ghiacciato.

Chiarimenti :

• Non sto parlando di ciò che (credo) si chiama "periodi congelati" durante (ad esempio) l'elaborazione di fine anno nelle banche. Ciò significa non poter applicare (ripetere) eventuali modifiche agli ambienti di produzione, per ridurre il rischio che vengano introdotte nuove modifiche / correzioni che potrebbero influire sull'elaborazione di fine anno.

• Supponiamo che gli utenti autorizzati ad approvare / applicare le modifiche (come ad esempio il gestore delle versioni nel mio esempio) lo faranno solo in casi eccezionali. Ad esempio dove durante il test si riscontra un problema di gravità elevata, per cui il rinvio di una correzione a una versione successiva non è un'opzione (poiché sarebbe a rischio produzione se la versione fosse attivata senza tale correzione).

• Potrebbe trattarsi solo di sospendere qualsiasi aggiornamento automatico durante il tempo del test. Il punto è: evitare che qualcun altro aggiorni un'applicazione A alla versione Y mentre un altro team sta ancora testando l'applicazione B nella versione X che fa affidamento sull'applicazione A. Ciò potrebbe significare avere una guardia per evitare che un team di test richieda un aggiornamento su una dipendenza in test.

La mia risposta nel contesto della domanda è un ambiente di test molto costoso (come mainframe o apparecchiature di telecomunicazione molto grandi, per esempio) che dovrebbero essere condivise da più utenti per più test, anche simultaneamente.

In molti casi, tali apparecchiature dispongono di un sistema di gestione del software responsabile, tra l'altro, del controllo (dis) installazione / upgrade / downgrade / ecc. Del software. Che dovrebbe avere un meccanismo per bloccare tali operazioni (che sarebbe, se avessi capito correttamente la domanda, equivalente a congelare l'ambiente) basato su alcune politiche più o meno programmabili.

In tal caso, una politica specifica potrebbe essere sviluppata esattamente per supportare il programma di congelamento desiderato necessario per l'ambiente di test. Idealmente automatizzato, accettando i trigger di congelamento / scongelamento da fonti esterne che potrebbero essere i wrapper di esecuzione del test o i sistemi CI. E forse con sostituzioni innescate dall'uomo, se ritenuto necessario.

Naturalmente, tale caratteristica del sistema di gestione del software sarebbe utile durante il test di altri componenti dell'apparecchiatura, ma forse non per i test del sistema di gestione del software stesso.

TeamCity ha una funzione di compilazione delle risorse condivise che consente di definire una risorsa da cui dipendono più definizioni di compilazione. Le definizioni di build possono richiedere un blocco di lettura o un blocco di scrittura, è inoltre possibile definire se questi blocchi sono esclusivi o consentono un certo grado di parallelismo.

Se facciamo le seguenti ipotesi su un ambiente condiviso chiamato PreProd :

• Esiste una risorsa condivisa denominata "PreProd".
• Tutte le definizioni di build, come le distribuzioni, che apportano modifiche a quell'ambiente, dispongono di un blocco scrittura esclusivo su "PreProd".
• Tutte le definizioni di compilazione, come i test non restrittivi, che eseguono operazioni di sola lettura sull'ambiente ottengono un blocco di lettura non esclusivo su "PreProd".
• TeamCity è l'unico processo che può fare qualsiasi cosa su PreProd, anche se forse tramite un altro strumento.

Pertanto vale quanto segue:

• Quando si verifica una distribuzione, nient'altro può utilizzare PreProd, verranno messi in coda.
• Quando un test è in esecuzione, qualsiasi distribuzione verrebbe messa in coda fino al completamento dei test.

Puoi usare un meccanismo simile con Jenkins usando il plug-in di esclusione . In effetti, è possibile integrare questa funzionalità in qualsiasi processo utilizzando il blocco o il semaforo, ad esempio Apache ZooKeeper o HashiCorp Console .

Questo suona come un modello anti per me. Credo che tutti o nessuno dovrebbero avere accesso a tutti gli ambienti.

Se gli utenti sovvertono il processo, prenderei in seria considerazione il processo per cercare di assicurarmi che non si frapponga alle persone.

L'implementazione di un meccanismo automatizzato che impone uno stato specifico è utile anche per incoraggiare le persone a fare le cose nel modo giusto. Questo può avvenire tramite Config Management o distruggere qualsiasi istanza immutabile se qualcuno lo utilizza