Ambienti Monksoftware¶
In questo documento vengono definiti, genericamente, gli ambienti che l’infrastruttura MonkSoftware mette a disposizione degli sviluppatori e dei Solution. Si richiede la massima attenzione nell’utilizzo degli ambienti stessi, per garantire a tutti un lavoro senza intoppi, svolgendo nelle attività nell’ambiente corretto.
Produzione¶
L’ambiente di produzione non dovrebbe essere nemmeno preso in considerazione dagli sviluppatori. Una volta che un’applicazione è in produzione, passa in carico al gruppo sysadmin/operation; inoltre, i dati degli utenti diventano reali e quindi gli sviluppatori non possono più accedere. I dati utente sono offuscati (per GDPR) e quindi è anche impossibile risalire puntualmente ad un utente, a meno che l’identificativo non venga fornito dall’utente stesso ai fini di customer caring. Per qualsiasi problema e segnalazione le persone da contattare sono prima il gruppo Operation, e poi eventualmente vengono coinvolti i sysadmin.
Preproduzione¶
Questo ambiente è completamente speculare alla produzione: solitamente, nel caso di ambienti in cluster, ha praticamente lo stesso numero di nodi, scalati verticalmente verso il basso, ma con una configurazione identica. Qualsiasi test svolto in questo ambiente deve garantire al 100% che lo stesso codice, installato in produzione, funzionerà allo stesso identico modo. Questo stesso ambiente viene utilizzato come demo, e cioè per le POC ai clienti, o per le business simulation.
Il logging è presente ma non verboso, per cui è più difficile risalire ai problemi, gli sviluppatori non hanno accesso in deploy, ma il gruppo operation può dare supporto passando dei log, dando feedback sui test, e interfacciandosi con i clienti e i referenti durante le integrazioni. I test di integrazione si fanno in questo ambiente quando il codice è stabile, funzionante, e testato adeguatamente, quindi in uno stato “beta” (leggere il capitolo “Guidelines”). Non fate mai i test funzionali in questo ambiente: per intenderci, il versioning di sviluppo sarà sempre attivo, mentre in preproduzione dovrebbero aver luogo un numero limitato di cambi di versione beta, il minor numero possibile.
Sviluppo¶
Qui, lo sviluppatore ha il controllo completo! Tutti hanno accesso ai server, ai log (che sono in DEBUG), le macchine sono SINGOLE e facili da controllare e debuggare. Non avete bisogno di nessuno per fare dei controlli! Massima velocità! Inoltre avete a disposizione uno swarm docker per fare i deploy in completa autonomia usando le pipeline gitlab. Infine vi ricordo che a breve gli accessi ai database di produzione e preproduzione verranno cambiati e chiusi, e gli ambienti isolati tra di loro. Non comunicate MAI ai clienti esterni gli indirizzi degli ambienti di sviluppo se non strettamente necessario - soprattutto, dato che può accadere che questo ambiente, per qualche deploy effettuato da un altro sviluppatore del team, smetta di funzionare, evitate di consegnare ai clienti app o endpoint che lo usino, garantendone l’uptime - l’unico ambiente deputato ai test con i clienti dovrebbe essere la preproduzione/demo.
Per riassumere, comunque, NON si fanno test funzionali in preproduzione - La vostra applicazione dovrebbe essere testata in preproduzione solo una volta raggiunto un certo livello di stabilità, quindi soltanto in fase beta. Eventuali test si possono fare su ambienti docker privati, sull’ambiente di sviluppo condiviso, o su docker swarm di sviluppo.
