Buone, semplici ragioni per avere più ambienti

Durante la mia carriera ho lavorato in aziende che avevano una collezione di ambienti diversi per scopi diversi. Abbiamo sempre avuto più o meno il nostro ambiente desktop, un ambiente di test, un ambiente di controllo qualità, un ambiente di gestione temporanea e un ambiente di produzione. Questo valeva sia per i server / le applicazioni sia per tutte le fonti di dati che stavamo utilizzando.

Quando ho iniziato presso la mia attuale azienda, ho scoperto che il 90% delle app erano sviluppate su un ambiente desktop rispetto a origini dati di produzione o sviluppate direttamente sul server di produzione in base alla piattaforma. Ciò non è stato particolarmente sorprendente, in quanto sono stato assunto in parte per apportare modifiche per migliorare il funzionamento del team di sviluppo, il che era chiaro dal mio processo di intervista. Abbiamo iniziato lentamente a cambiare la filosofia e molto presto, la maggior parte delle app poteva essere eseguita in un ambiente desktop, di test o di produzione. Non molto tempo dopo anche quella messa in scena.

Ora la maggior parte dei nostri sviluppatori vede i vantaggi di questa metodologia e la difende con attenzione. Tuttavia, abbiamo un numero di app legacy che non sono mai state migrate. Abbiamo anche un numero di programmatori legacy che pensano a questo come una perdita di tempo. Sfortunatamente, abbiamo ottenuto un servizio labiale ma non abbiamo mai acquisito completamente la gestione. Abbiamo ottenuto quello che pensavamo fosse un impegno a investire sostanzialmente in questo circa un anno fa, ma nulla si è materializzato nonostante la notevole pianificazione che ci abbiamo messo. Ora stiamo scoprendo che abbiamo bisogno di sempre più ambienti. Abbiamo bisogno dell'aiuto dei team di amministrazione del server / della rete per l'installazione e abbiamo bisogno della partecipazione degli stakeholder aziendali per supportare il ciclo di rilascio. Ora siamo in un luogo in cui un progetto può funzionare ciò che gli sviluppatori ragionevoli considererebbero "normalmente"

Mi piacerebbe presentare una discussione completa, ma il management non ha davvero tempo e interesse a ascoltarmi fino a quando non ci sarà un problema critico. Non posso davvero articolare i benefici semplicemente perché mi è sempre sembrato una seconda natura. Mi chiedevo se ci fossero ragioni buone, semplici, inconfutabili per la separazione degli ambienti che farebbero perdere ai manager la mancanza di esperienza di sviluppo a supporto di questa idea? . Ci sono buone risorse / letteratura sull'argomento?

La risposta: denaro

Non mi interessa quale sia la vera ragione. Il denaro DEVE essere alla radice di tutti i tuoi ragionamenti, specialmente quando hai a che fare con la gestione.

Se entrambi fossimo seduti in una stanza per 2 ore, potremmo trovare dozzine di ragioni per cui è meglio avere più ambienti.

Ecco il problema: se i motivi non sono basati sul denaro, nessuno di questi conta .

I programmatori non sono assunti per essere intelligenti. Non sono assunti per essere creativi. Sono assunti per aumentare le entrate - guadagnando o risparmiando. Se non stai facendo uno di questi, faresti meglio a riprendere il tuo curriculum.

Osservandola da quel punto di vista, la risposta è semplice:

Avere un solo ambiente aumenta i nostri tempi di inattività e comporta una perdita di entrate. Ambienti multipli ci consentono di proteggere i nostri profitti offrendo ai nostri utenti un front-end altrettanto affidabile e affidabile della nostra azienda.

Ripeti ogni giorno.

Di seguito sono riportati alcuni ottimi commenti che aggiungono un valore reale a questa risposta, quindi li citerò:

• Karl Bielefeldt ha avuto un grande punto quando ha affermato che l'analisi costi / benefici è un fattore importante. Un economista potrebbe riferirsi ad esso come il costo opportunità di perseguire ambienti multipli. Mentre può essere sorprendente sentire, ci sono scenari in cui più ambienti potrebbero non essere la risposta! Se il sito Web della tua azienda è un'aggiunta molto minore, i tempi di inattività imprevisti potrebbero effettivamente essere il modo più economico di fare affari. Non sembra la posizione in cui ti trovi, ma vale la pena menzionarlo.

• BlairHippo ha sottolineato che dovresti sentirti libero di farlo sembrare una catastrofe (e se perdi i tuoi dati, lo è!). La responsabilità è un ottimo strumento per persuadere i manager, ma sempre per lo stesso motivo: le azioni legali sono costose. Evitarli consente di risparmiare denaro.

Come addendum, ho trovato questo articolo abbastanza buono. Non risponde direttamente alla tua domanda, ma ti consente di riconoscere come i programmatori sono visti dalla direzione, il che a sua volta porta a questa risposta. Buona lettura.

Singolo punto di errore

Non avendo un ambiente di sviluppo o di gestione temporanea, si dispone di un unico punto di errore per quelle applicazioni legacy. La direzione ti ascolterà se descrivi le applicazioni legacy in quei termini.

Devi essere in grado di inserire il tuo messaggio in byte sonori che abbiano senso per loro. Prendi il " Programmer Speak " dalla discussione e sostituiscilo con " Manager Speak ". Fai anche finta di avere un giro in ascensore di 30 secondi per ottenere il tuo punto.

Ho avuto una situazione in cui il mio capo era un fante di marina. Continuavo a dirgli che avevo bisogno di strumenti software e formazione informatica per i miei marines per essere più produttivo. Non l'ha capito. Alla fine entrai nel suo ufficio un giorno e gli dissi che le cose erano state scoperte.

Ho detto qualcosa all'effetto ... "Se stessi combattendo una guerra, userei bastoni, rocce e rami di alberi. Ciò di cui ho bisogno sono granate, bazooka e mitragliatrici." Ha ricevuto il messaggio.

È davvero critico?

Posso capire il desiderio di usare ambienti separati. La domanda non ovvia è:

È davvero fondamentale migrare un sistema legacy ?

Penso che la maggior parte delle persone tecnicamente inclini tendano a concentrarsi sulla questione accademica di quale sia il modo migliore che va bene nel mondo accademico. Negli affari, anche se i migliori non sempre vincono. Non sto dicendo che questo sia negativo o che non inizi una guerra alla fiamma. Io sto affermando l'ovvio, o quello che dovrebbe essere ovvio per quelli di noi che sono stati nel software di business per alcuni anni.

Tutte le decisioni aziendali vengono generalmente prese in base al costo / beneficio percepito. Quindi la domanda che l'azienda si sta probabilmente ponendo è:

Il costo del sistema aggiuntivo e gli investimenti nello sviluppo in un'applicazione legacy valgono il vantaggio rispetto allo stesso investimento in un altro progetto / prodotto?

Ho e continuo a fare regolarmente analisi costi-benefici per prendere decisioni non solo sulla migrazione / riscrittura del software, ma nelle decisioni quotidiane in genere un vantaggio si impegna. Ho passato a riscrivere / migrare il vecchio software perché aveva una vita limitata e quindi valore.

Ambienti di separazione

Le ragioni di business per separare gli ambienti.

• Meno rischi nelle versioni e correzioni di bug. Provalo con i numeri. Quante volte il prodotto ha avuto esito negativo e ha comportato un costo per le entrate dei clienti a causa di un rilascio / bug errato.
• Meno rischi nello sviluppo. L'eliminazione accidentale del dev db è diversa dall'eliminazione accidentale del db di produzione
• La capacità di separare chiaramente ruoli e accesso, ad es. migliore sicurezza. limitare il numero di dita nella torta di produzione è una buona cosa
• La capacità di separare gli ambienti e le pratiche e le procedure che accompagnano questo stile di sviluppo consentono un futuro sviluppo nei sistemi cloud.
• La separazione dell'ambiente dovrebbe forzare l'efficienza nella replica di ambienti che possono essere utili nel ridimensionamento programmato e dinamico.

Sembra che tu abbia già messo in atto tutti gli argomenti "giusti". Invece, stai vivendo una "aringa rossa", se vuoi. Oppure "inseguendo la carota"

la direzione non ha davvero tempo e interesse a ascoltarmi fino a quando non ci sarà un problema critico

Questo è quello che considero il vero problema. In base alla mia esperienza, se un'azienda ha pratiche di sviluppo al di sotto delle pari, come le descrivi. Non è semplicemente una questione di "non sapevamo niente di meglio". Piuttosto, è una raccolta di debiti tecnici causati da un team di gestione superiore che non sa (cura?) Dei problemi che presenta.

In questi casi, una buona chiacchierata non farà oscillare improvvisamente le cose nella tua direzione. Forse un grave trauma (guasto del prodotto visibile al cliente e direttamente legato a pratiche inadeguate), ma sono sicuro che esperti di tecnologia sapiente prima di aver provato a parlare.

Il mio suggerimento è di succhiarlo e prendere le cose per quello che sono o cercare una nuova posizione.

Quanti gruppi di persone pianificano di lavorare sull'app alla volta? Solitamente ho visto un ambiente per ogni gruppo di persone. Questi sono gli sviluppatori (ottengono un ambiente DEV e un ambiente di integrazione DEV - alcuni direbbero che non è necessario al 100%, direi che varia in base al progetto), due ambienti di test (un gruppo di tester che esegue test molto dettagliati, l'altro per tester di QA di alto livello - di solito sono utenti aziendali reali, non tester di formazione). Di solito esiste anche un ambiente di test delle prestazioni isolato (in modo da poter testare enormi volumi di dati, simulare enormi volumi di utenti, ecc ... g).

Perché tutti questi ambienti? Quindi gruppi diversi possono testare funzionalità diverse senza calpestare le dita degli altri. Se sviluppatori e tester lavorano nello stesso ambiente, è un incubo: un tester può aprire un difetto su una funzione che viene attivamente cambiata ogni minuto da uno sviluppatore. Se ci sono due livelli di test, possono concentrarsi su attività diverse e non preoccuparsi di scambiarsi i dati a vicenda. Avere un ambiente di prestazioni isolato consente di eseguire test che potrebbero sospendere la macchina, ma se è isolato, nessun altro tester sarà interessato.

Quando troppe persone provano a fare troppe cose diverse nello stesso ambiente, si finisce con un sacco di tempo sprecato mentre un gruppo attende che il test di un altro gruppo finisca in modo da poter eseguire il proprio. E questo fa perdere tempo, e sprecare tempo può portare a sprecare denaro, che Stargazer712 ha sottolineato potrebbe rendere la più grande accusa.

Un altro motivo (non altrettanto comune) sono i dati: se l'applicazione ha dati personali sensibili o dati della carta di credito, di solito non è possibile inserirli negli ambienti di test e di solito ci sono requisiti di mascheramento per tutto tranne gli ambienti di controllo qualità e produzione.

Sembra che tu abbia investito moltissimi sforzi per realizzare un cambiamento culturale nel tuo posto di lavoro. Questo è un grande risultato poiché il cambiamento è difficile nel migliore dei casi, ma il cambiamento culturale non riguarda semplicemente il cambiamento delle menti delle persone, ma il cambiamento delle abitudini, la rottura dei pregiudizi e, in definitiva, l'apertura di menti potenzialmente chiuse a maggiori possibilità. Quindi la domanda da porsi a questo punto è "Cosa mi sono perso?". La risposta semplice è che potresti non essere completamente coinvolto nella gestione.

Ottenere acquisti dalla direzione è facile, ma ancora più difficile è ottenere l'accettazione. Indipendentemente dalle argomentazioni sul denaro, ecc., La realtà è che devi essere in grado di influenzare la visione di priorità della direzione. Il tuo manager avrà un budget e vorrà dimostrare che il budget è stato applicato in modo ragionevole e in linea con i valori e le priorità dell'azienda. Alcune di queste priorità saranno fiscali, ma altre riguarderanno il servire altre esigenze. In alcuni casi, questo può significare ingrassare i palmi degli altri manager per ottenere quella promozione che il tuo capo ha sempre desiderato. Nella maggior parte dei casi, tuttavia, si tratterà probabilmente di trovare modi per guadagnare più affari o migliorare le relazioni con partner e clienti. Se non puoi presentare il tuo caso in questi termini, sarai in grado di andare così lontano solo prima di ritrovarti in un vicolo cieco.

Il mio suggerimento è quello di provare a fare un caso sulla produttività e su come questo influisce sul budget, come altri hanno suggerito, ma anche a fare il caso in termini di priorità della tua azienda e in che modo la tua produttività potrebbe avere un impatto diretto sui rapporti dell'azienda con altre aziende.

Eccone uno: testabilità.

Avere un ambiente di test offre la libertà di eseguire test su un database che sarebbe sconsigliato eseguire in un ambiente di produzione.

Vuoi cambiare il modo in cui la tua organizzazione sviluppa il suo software? Dimentica la preoccupazione delle "ragioni" per "fare le cose in modo diverso". Gli umani non cambiano comportamento a causa di argomentazioni razionali. Cambiano a causa delle influenze psicologiche sulle loro abitudini.

Allora, dove sto andando con questo?

Mentre a volte puoi cambiare con successo il comportamento di un'organizzazione attraverso l'argomentazione, ci sono altre tattiche che funzionano meglio. Questi includono:

• Supporto di base: trova UN ALTRO sviluppatore "legacy" che è disposto a darti una possibilità. Collabora con lui e cambia il modo in cui funzionano le cose. Non annunciare il cambiamento. Basta apportare il cambiamento. Se qualcuno ti chiede mai, dì "Oh sì, è così che facciamo adesso".

• Assumi la responsabilità. Volontariato per gestire le distribuzioni per le persone legacy. Comportati come lo ami. Potrebbero essere felici di rinunciare a tale responsabilità. Quindi eseguilo come vuoi.

• Dai la colpa alle persone giuste per i loro errori. La prossima volta che un bug dell'app legacy viene introdotto in produzione a causa del meccanismo di distribuzione dell'età della pietra, segnalalo. Fallo sottilmente ... Non in un'email. La prossima volta che incontrerai un manager, menzionerai casualmente l'esempio di un motivo per cui la distribuzione era problematica. "Sì, ricordi come ci siamo arrampicati venerdì scorso a causa del bug Foo che Bob ha messo in produzione? Sì, è stato uno sforzo sprecato!"

• Rendi facile farlo nel modo migliore. Guarda l'iphone, per esempio. C'è un pulsante su di esso. (Bene, due). È MOLTO facile da accendere. Rendi stupido lo schieramento su più ambienti multipli. Rendilo così facile che tutti i gestori possono farlo!

È più un problema quando si inizia a trattare con sistemi interconnessi o legacy, sistemi su cui l'azienda dipende per funzionare e essere precisi. È importante perché deve esserci una segregazione tra le fasi, è il motivo per cui non DEV su PROD perché ha il potenziale di causare danni per milioni di dollari nel tempo perso .

Facciamo sempre DEV -> QA -> PROD (a volte quei passaggi sono suddivisi in pezzi più piccoli) con hardware identico dietro di loro. I dati di produzione attuali vengono sempre trasferiti da PROD a QA a DEV.

DEV: è destinato a essere la sandbox di sviluppo, in cui le cose vengono provate, ripetute e battute su qualsiasi dato in questo ambiente non dovrebbero mai essere attendibili e vengono regolarmente spazzate via dagli sviluppatori semplicemente trovando il modo di risolvere un problema.

QA: Una volta che i tuoi sviluppatori sono soddisfatti dei test unitari, è tempo che il gruppo di test lo guardi. Eseguono casi di test, test delle prestazioni e trovano bug. Questi bug / incantesimi vengono restituiti a DEV e il ciclo continua fino a quando tutti sono felici.

PROD: Una volta arrivato a questo punto, dovresti essere sicuro che il codice funzioni insieme ai dati attuali e che il tuo gruppo QA / gli utenti aziendali sono soddisfatti dell'implementazione. Se hai fatto tutto correttamente, dovresti semplicemente essere in grado di aggiornare il codice e finirlo.

Allo stesso modo non rilasceresti mai un prodotto non testato ai clienti e non dovresti mai rilasciare il codice non testato in un ambiente di produzione.

Se la società non è disposta a investire il tempo necessario per farlo correttamente, rimborserà i costi per la manutenzione di emergenza e gli errori 10 volte.

A titolo di esempio: avevamo una società che ha deciso di apportare da sola una modifica a un report in produzione. Nessuno sapeva che è cambiato fino a quando non siamo entrati per affrontare una serie di problemi un anno o due lungo la linea.

Quando abbiamo sottolineato l'irregolarità nel rapporto, la faccia del CFO è diventata bianca, si è scoperto che stavano perdendo ~ $ 250.000 al quarto a causa di qualcuno che ha fatto un rapido cambiamento.

Succede più spesso di quanto pensi, se non puoi permetterti di farlo correttamente, allora non farlo.

Il management ha una grande parte dietro il successo delle società di software e dei prodotti software che hanno richiesto di generare questi ambienti. Lascia un esempio del tuo progetto. Se il tuo software è sviluppato su larga scala, quindi se non gestisci i requisiti del tuo progetto, il controllo del processo, i test build ecc. in modo che esista la gestione dei progetti.

Sono in qualche modo d'accordo con @ Stargazer712 sul fatto che la tua affermazione rimanda alla questione del denaro, ma controlla la seguente dichiarazione che ho ottenuto dal libro di Marc Hamilton sullo sviluppo del software: Creazione di sistemi affidabili (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Dopo aver osservato tutti questi fattori; la mia opinione sulla tua domanda è che Single Environment non ti dia risparmi, ma farà un processo a lungo termine per completare il progetto / software. Gli ambienti distribuiti risparmieranno tempo e entrate, come ho appreso e visto nella mia esperienza che ciò che è accaduto con le società di software di avvio da cui ho avviato il mio operatore telefonico.

Ci sono molti articoli che dimostrano che ciò che conta per il successo, controlla questo Organizing for Successful Software Development

Ogni individuo in un'organizzazione ha determinate abilità e queste abilità sono in genere misurate rispetto a metriche di prestazione formali o informali che portano a premi (compensazione) come incentivi per le prestazioni future. Le persone in un'organizzazione stabiliscono la sua cultura, quei modelli e valori comportamentali che sono generalmente riconosciuti come adottati.

Una grande serie di sviluppatori di software farà fatica e alla fine non riuscirà a raggiungere i propri obiettivi se deve passare tutto il tempo a combattere contro una struttura organizzativa inappropriata.

Molte startup di software iniziano la loro vita con non più di un paio di sviluppatori che lavorano in un garage. A questo punto non è richiesta molta struttura organizzativa nella storia di un'azienda, ma esiste ancora una struttura organizzativa. Ad esempio, nel 1977, quando Bill Gates e Paul Allen formarono la loro partnership e la nominarono ufficialmente Microsoft, la società aveva una struttura organizzativa minima. Meno di una dozzina di dipendenti lavoravano nel primo ufficio di Microsoft ad Albuquerque, nel New Mexico, e tutti sapevano chi era il responsabile. Non sono stati necessari organigrammi complicati per capire la struttura dei rapporti di tutti. Allo stesso tempo, tutti i dipendenti conoscevano il loro ruolo nell'azienda e ciò che stavano cercando di realizzare. Questo perché qualsiasi struttura organizzativa necessaria poteva essere comunicata in modo informale tra ciascuno dei dipendenti.

Dimentica tempo, denaro, testabilità, qualità ... che ne dici di reputazione .

buone, semplici, inconfutabili ragioni per la separazione degli ambienti che farebbero perdere ai manager la mancanza di esperienza di sviluppo a supporto di questa idea.

Di recente Uber ha inviato a Github il codice che conteneva password per il proprio ambiente live , consentendo agli "hacker" di scaricare tutti i dettagli dei propri clienti. Uber dice che è stata una violazione, tutti gli altri dicono "non mettere le chiavi dei tuoi lucchetti in vista del pubblico. Se i loro sviluppatori hanno lavorato interamente su un ambiente di sviluppo, avrebbero potuto rilasciare le chiavi del loro ambiente di sviluppo su Github, ma questo è del tutto Il fatto che quelli di produzione siano stati rilasciati dimostra quanto sia scarsa questa idea di eseguire sviluppatori nell'ambiente di produzione.

Ricorda solo al tuo manager che si verificano errori, quindi il modo per evitare che venga trascinato davanti al CEO che sta per farsi grigliare davanti ai giornalisti e deriso dal pubblico della tecnologia è di prendere semplici e ovvi passi per evitare che questi errori siano catastrofici quelli.

Sembra che tu abbia molti ambienti diversi ed è molto costoso per le persone impostare un "ambiente".

Dovresti avere il minor numero di "ambienti" diversi con cui puoi cavartela, ma essere in grado di clonare molte copie per tutti i motivi che tu e la tua azienda desideriate (usando "ambiente per indicare la configurazione del sistema)!

In modo ottimale le uniche differenze dovrebbero essere:

1. Dimensioni (minimo, consigliato, maggiore supportato / testato);
2. La stadiazione e la produzione non hanno strumenti di sviluppo
3. La produzione è protetta dalla sovrascrittura accidentale dei dati
4. È possibile caricare facilmente i dati dei client demo, test o [anoymized] su server di sviluppo o di gestione temporanea

POI la questione di quanto e che tipo di test dovrebbe essere fatto è una valutazione del rischio / costo aziendale e decisa a livello aziendale, perché è il business nel suo complesso che soffrirà se i guasti significativi arrivano a una gamma di clienti .

Modifica successiva: questo mi ha spinto a razionalizzare le convenzioni di denominazione con i miei prodotti Web (grazie per la domanda). Ho deciso su quattro "ambienti", con i test suddivisi tra qa (livello singolo minimo solo per funzionalità di test) e stadiazione (stessa architettura della produzione, per test di carico / prestazioni / volume).

L'unica vera differenza nel provisioning è la produzione / gestione temporanea dell'installazione di un DB su un sistema separato, che controllo tramite i gruppi in cui si trovano i diversi server. Qa / dev hanno sia il server web che i ruoli db. Il bilanciamento del carico viene eseguito da cloudflare.

Ho anche una variabile ENV_NO, che viene passata ai sistemi in modo da poter scegliere di avere tutti gli esempi "qa" o "staging" che scelgo.

Quindi, per configurare un secondo ambiente qa incluso il mio ultimo backup da vivo, i comandi sarebbero:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Infine, ho un server aggiuntivo (opzionale) chiamato "readonly" come ultima rete di sicurezza prima di colpire il suolo. Viene fornito come un sistema qa ma con backup e aggiornamento della scorsa notte disabilitati (il software viene aggiornato anche alla scorsa notte).

Utilizza un approccio "Tutte le uova in un cestino diverso": viene fornito con una posizione / registrar DNS, host DNS, provider di servizi host di sistema diversi. Questa è la massima / ultima rete di sicurezza, quindi se tutto è andato in fiamme puoi almeno arrivare ai dati fino a ieri sera. Gli script di provisioning isolano la differenza tra i diversi provider, quindi il 99% è lo stesso, solo il flag di sola lettura. Il bilanciamento del carico di Cloudflare reindirizzerà il traffico al sito di sola lettura se tutti i server attivi non sono riusciti.

Quando si tratta di apportare una modifica, sarai fortunato ad avere qualcuno che ascolterà la tua opinione professionale e implementerà le modifiche suggerite.

In base alla mia esperienza, ogni volta che dovevo apportare un cambiamento importante, dovevo giustificarlo in termini di risparmi che l'impresa farà. Ad esempio, introdurre ReSharper nella pipeline di sviluppo è stato abbastanza semplice, dato che sono stato in grado di dire qualcosa in sospeso:

ReSharper costa circa £ 50 per sviluppatore. Il costo medio per gli sviluppatori all'anno è £ 40k. ReSharper dovrebbe aumentare la produttività degli sviluppatori di almeno il 20% dato il suo pieno utilizzo. Supponiamo che lo sviluppatore passi il 75% del proprio tempo a scrivere codice in IDE. Il 75% di 40k è £ 30k. £ 30k sono ora il costo della produttività degli sviluppatori. Un ulteriore percentuale di produttività (1%) all'anno costa £ 300. Per ottenere una produttività aggiuntiva del 20%, l'azienda dovrebbe spendere £ 6k.

Se dovessi mettere questo in prospettiva per il business, puoi dire che puoi assumere qualcun altro e ottenere una produttività aggiuntiva del 20% per £ 6k, oppure puoi ottenere lo stesso risultato spendendo £ 50 con una licenza ReSharper. Una volta che le cifre sono davanti al business, la decisione sarà facile da prendere.

Ora, per quanto riguarda le tue domande sull'avere più ambienti, tutto ciò che devi fare è trovare un modo per calcolare quanto costa ogni anno all'azienda avere questi ambienti.

Puoi chiedere ai tuoi colleghi sviluppatori di tenere traccia delle ore trascorse ogni settimana nella configurazione di applicazioni per lo sviluppo, l'implementazione, ecc. Ad esempio, dieci ore di tempo per gli sviluppatori senior potrebbero costare £ 500 al business. Sono 10 ore che possono essere spese per lo sviluppo o qualcosa di molto più importante. Raccogli le cifre per un certo periodo di tempo e offri alle aziende un costo annuale.

Personalmente odio questo tipo di politica, ma è comune e dobbiamo conviverci.