Buone, semplici ragioni per avere più ambienti

La risposta: Money

Non mi interessa quale sia la vera ragione. Il denaro DEVE essere alla base di tutti i tuoi ragionamenti, specialmente quando si tratta di gestione.

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

Ecco il problema: se i motivi non sono basati sul denaro, allora nessuno di essi è importante .

I programmatori non sono assunti per essere intelligenti. Non sono assunti per essere creativi. Vengono assunti per aumentare le entrate - guadagnando o risparmiando denaro. Se non stai facendo nessuno di questi, è meglio che tu riprenda il tuo curriculum.

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

Having only one environment increases our downtime and results in lost revenue. Multiple environments allows us to protect our profits by giving our users a front-end that is just as reliable and dependable as our company.

Ripeti ogni giorno.

Di seguito ci sono alcuni fantastici commenti che aggiungono un valore reale a questa risposta, quindi li menzionerò:

• Karl Bielefeldt ha avuto un grande onore quando ha menzionato che l'analisi costi / benefici è un fattore importante. Un economista potrebbe riferirsi ad esso come il costo opportunità di perseguire più ambienti. Anche se può sembrare sorprendente, ci sono scenari in cui più ambienti potrebbero non essere la risposta! Se il sito web della tua azienda è un'aggiunta molto secondaria, il tempo di inattività inatteso potrebbe essere il modo più conveniente di fare affari. Questo non suona come la posizione in cui ti trovi, ma vale la pena menzionarlo.

• BlairHippo ha avuto un buon punto in quanto 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 cause legali sono costose. Evitarli risparmia denaro.

Come appendice, ho trovato questo articolo da abbastanza buono. Non risponde direttamente alla tua domanda, ma ti consente di riconoscere in che modo i programmatori sono visti alla gestione, il che a sua volta porta a questa risposta. Buona lettura.

Punto singolo di errore

Non disponendo di un ambiente di sviluppo o di staging hai un Punto singolo di errore per quelle applicazioni legacy. La direzione ti sentirà se descrivi le applicazioni legacy in questi termini.

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

Ho avuto una situazione in cui il mio capo era un marine di fanteria. Continuavo a dirgli che avevo bisogno di strumenti software e addestramento informatico per i miei marines per essere più produttivo. Non l'ha capito. Finalmente sono andato nel suo ufficio un giorno e gli ho detto che le cose erano finite.

Ho detto qualcosa sull'effetto ... "Se dovessi combattere una guerra, userei bastoni, rocce e rami degli alberi, quello di cui ho bisogno sono granate, bazooka e mitragliatrici". Ha ricevuto il messaggio.

In realtà è fondamentale?

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

È davvero importante migrare un sistema legacy ?

Penso che la maggior parte delle persone con una mentalità tecnica tendano a concentrarsi sulla questione accademica su quale sia la strada migliore, cosa che va bene nel mondo accademico. Negli affari, tuttavia, il meglio non sempre vince. Non sto dicendo che questo sia negativo, o inizi una guerra di fuoco. Sto affermando l'ovvio, o cosa dovrebbe essere ovvio per quelli di noi che sono stati nel software business per alcuni anni.

Tutte le decisioni aziendali sono generalmente basate sul costo / beneficio percepito. Quindi la domanda che l'azienda sta probabilmente chiedendo è:

Il costo del sistema aggiuntivo e dell'investimento in sviluppo in un'applicazione legacy vale il vantaggio rispetto al mettere lo stesso investimento in un altro progetto / prodotto?

Ho e continuo a fare regolarmente analisi costi-benefici per fare delle determinazioni non solo nel software di migrazione / riscrittura, ma nelle decisioni quotidiane in cui solitamente interviene un lead. Ho passato a riscrivere / migrare il vecchio software perché aveva vita limitata e quindi valore.

Separazione degli ambienti

I motivi aziendali per separare gli ambienti.

• Minori rischi nelle versioni e correzioni di bug. Dimostralo con i numeri. Quante volte il prodotto è fallito e le entrate del cliente sono costate a causa di un bug / bug non valido.
• Meno rischi nello sviluppo. Spegnere accidentalmente il dev db è diverso dall'accidentalmente spazzare via la produzione db
• La capacità di separare chiaramente i ruoli e l'accesso, ad es. migliore sicurezza. limitare il numero di dita nella torta di produzione è una buona cosa
• La possibilità di separare gli ambienti e le pratiche e le procedure che accompagnano questo stile di sviluppo consentono futuri sviluppi in Cloud Systems.
• La separazione dell'ambiente dovrebbe forzare le efficienze negli ambienti di replica che potrebbero essere utili nel ridimensionamento programmato e dinamico.

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

management really has no time and interest in hearing me out until there is a critical issue

Questo è quello che considero il vero problema. Nella mia esperienza, se un'azienda ha pratiche di sviluppo parziali tanto povere come le descrivi. Non è semplicemente una questione di "non sapevamo niente di meglio". Piuttosto, è una compilazione di debito tecnico causata da un gruppo dirigente che non sa (cura?) Dei problemi che presenta.

In questi casi, una buona conversazione non cambierà improvvisamente la tua direzione. Forse un trauma severo (fallimento del prodotto visibile al cliente e direttamente legato a pratiche inadeguate), ma sono sicuro che i tecnici esperti di buon senso prima di aver provato a parlare.

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

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

Ottenere acquisti dalla gestione è facile, ma anche più difficile è ottenere l'accettazione. Indipendentemente dalle argomentazioni sul denaro ecc., La realtà è che è necessario 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 altri bisogni. In alcuni casi, ciò potrebbe significare ingrassare i palmi degli altri manager al fine di ottenere quella promozione che il tuo capo ha sempre desiderato. Nella maggior parte dei casi, tuttavia, sarà probabilmente trovare modi per ottenere più business o migliorare le relazioni con partner e clienti. Se non riesci a esprimere il tuo caso in questi termini, sarai in grado di andare così lontano prima di trovarti in un vicolo cieco.

Il mio suggerimento è di provare a parlare della produttività e di come questo influisce sul budget, come altri hanno suggerito, ma anche di fare il caso in termini di priorità della tua azienda e di come la tua produttività potrebbe avere un impatto diretto sulle relazioni dell'azienda con gli altri aziende.

Ecco uno: testabilità.

Avere un ambiente di test ti dà la libertà di eseguire test su un database che sarebbe sconsigliabile eseguire in un ambiente di produzione.

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

Quindi, dove sto andando con questo?

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

• Supporto grassroots: trova un altro sviluppatore "legacy" che è disposto a darti una possibilità. Collaborare con lui e cambiare il modo in cui funzionano le cose. Non annunciare il cambiamento. Basta fare il cambiamento. Se qualcuno ti chiede mai, dì semplicemente "Oh sì, è così che lo facciamo adesso."

• assumersi la responsabilità. Volontariato per gestire gli schieramenti per gli anziani. Agisci come lo ami. Potrebbero essere felici di rinunciare a questa responsabilità. Quindi eseguilo come vuoi.

• Dai la colpa alle persone giuste per i loro errori. La prossima volta che un bug di un'app legacy viene introdotto in produzione a causa del tuo meccanismo di implementazione dell'età della pietra, fallo notare. Fallo sottilmente ... Non in una email. La prossima volta che ti trovi in un incontro con un manager, menziona solo casualmente l'esempio di un motivo per cui la distribuzione è stata problematica. "Sì, ricorda come stavamo rimescolando lo scorso venerdì a causa del bug di Foo che Bob ha fatto entrare in produzione? Sì, è stato un grosso sforzo sprecato!"

• Semplifica l'operazione nel modo migliore. Guarda l'iphone, per esempio. C'è un pulsante su di esso. (Bene, due). È MOLTO facile da accendere. Rendere la distribuzione su più ambienti pazzo stupido facile. Rendilo così semplice che tutti i manager possono farlo!

È più un problema quando si inizia a gestire sistemi interconnessi o legacy, i sistemi aziendali dipendono dal lavoro e dalla precisione. È importante perché deve esserci una segregazione tra le fasi, è la ragione per cui non DEV su PROD perché ha il potenziale di causare danni per milioni di dollari nel tempo perduto .

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

DEV: è inteso come la sandbox di sviluppo, dove le cose vengono provate, iterate e battute su qualsiasi dato in questo ambiente non dovrebbe mai essere considerato affidabile e viene regolarmente cestinato dagli sviluppatori semplicemente trovando i modi per risolvere un problema.

QA: una volta che i tuoi sviluppatori sono soddisfatti dei test delle unità, è tempo che il gruppo di prova li veda. Eseguono test case, test delle prestazioni e trovano bug. Quei bug / incantamenti vengono ridati al DEV e il ciclo continua finché tutti sono felici.

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

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

Se la società non è disposta a investire il tempo necessario per farlo correttamente, ripagherà il costo della manutenzione di emergenza e degli errori 10 volte.

Un piccolo esempio: abbiamo avuto una società che ha deciso di apportare una modifica a un report in produzione da solo. Nessuno sapeva che è cambiato fino a quando siamo entrati per affrontare una serie di problemi un anno o due lungo la linea.

Quando abbiamo sottolineato l'irregolarità nel rapporto, il volto del CFO è diventato bianco, risulta che stavano perdendo ~ $ 250.000 al trimestre a causa di qualcuno che cambiava rapidamente.

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

La gestione ha una parte importante del successo delle società di software e dei prodotti software che hanno richiesto la generazione di questi ambienti. Prendi un esempio del tuo progetto. Se il tuo software è sviluppato su larga scala, se non gestisci i requisiti del tuo progetto, il controllo del processo, le build di test ecc., Allora ci sono possibilità di fallimento. in modo che esista Gestione progetti.

I am somewhat agree with @Stargazer712 that your statement point to the Money matters, But Check the following statement that i have gotten from Marc Hamilton's book on Software Development: Building Reliable Systems (Prentice Hall PTR, 1999, ISBN 0-13-081246-3). After looking all of these factors; my Opinion about your question is that Single Environment is not give you savings, it will make a long term process to complete the project/software. Distributed Environments will save Time and revenue as i learned and seen in my experience that what happened with the start-up software companies from which i have start my carrier.

Ci sono molti articoli che dimostrano che ciò che conta per il successo, controlla questo Organizzazione per lo sviluppo del software di successo

Each individual in an organization has certain skills, and these skills are typically measured against formal or informal performance metrics leading to rewards (compensation) as incentives for future performance. The people in an organization establish its culture—those behavior patterns and values that are generally recognized as being adopted.

Un gran numero di sviluppatori di software si troveranno a lottare e alla fine non riusciranno a raggiungere i loro obiettivi se dovranno passare tutto il loro 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 nella struttura aziendale non è richiesta molta struttura organizzativa, 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à ebbe una struttura organizzativa minima. Meno di una dozzina di impiegati ha lavorato nel primo ufficio Microsoft ad Albuquerque, nel New Mexico, e tutti sapevano chi era al comando. Non erano necessari grafici organizzativi complicati per capire la struttura di reporting di tutti. Allo stesso tempo, tutti i dipendenti conoscevano il loro ruolo nella società e ciò che stavano cercando di realizzare. Questo perché ogni struttura organizzativa che era necessaria poteva essere comunicata in modo informale tra ciascuno dei dipendenti.

Dimentica tempo, denaro, testabilità, qualità ... che dire di reputazione .

good, simple, irrefutable reasons for the separation of environments that would get managers lacking development experience to support this idea.

Uber ha recentemente inviato il codice a Github che conteneva le password per il proprio ambiente live , consentendo agli 'hacker' di scaricare tutti i dettagli dei propri clienti. Uber dice che è stata una breccia, tutti gli altri dicono "non mettere le chiavi dei lucchetti in vista pubblica, se i loro sviluppatori hanno lavorato interamente su un ambiente di sviluppo, potrebbero aver rilasciato le chiavi al proprio ambiente di sviluppo su github, ma è tutto innocuo. Il fatto che i film di produzione siano stati pubblicati mostra quanto sia scarsa questa idea di sviluppo delle prestazioni nell'ambiente di produzione.

Ricorda al tuo manager che gli errori accadono, quindi il modo per evitare che venga trascinato davanti al CEO che sta per beccarsi di fronte ai giornalisti e deriso dal pubblico della tecnologia è di adottare semplici e ovvi passi per impedire che gli errori sono catastrofici.

Sembra che tu abbia molti ambienti diversi e che le persone impieghino molto tempo per impostare un "ambiente".

Dovresti avere il numero minimo di "ambienti" diversi che puoi farla franca, ma essere in grado di clonare molte copie per tutte le ragioni che hai e il desiderio dell'azienda (utilizzando "ambiente per indicare la configurazione del sistema)!

Le uniche differenze dovrebbero essere:

1. Dimensione (minima, consigliata, più grande supportata / testata contro);
2. La gestione temporanea e la produzione non hanno strumenti di sviluppo
3. La produzione è protetta contro la sovrascrittura accidentale dei dati
4. Puoi caricare facilmente i dati dei demo, test o [anoymized] dei clienti sui server di sviluppo o di staging

ALLORA la questione di quanto e quale tipo di test dovrebbe essere fatto è una valutazione del rischio / costo aziendale e decisa a livello aziendale, perché è l'azienda nel suo complesso che subirà se si verificano errori significativi in un 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 la suddivisione dei test tra qa (minimo singolo livello per la sola funzionalità di test) e staging (stessa architettura della produzione, per il test carico / prestazioni / volume).

L'unica vera differenza nel provisioning è produzione / staging installa un DB in un sistema separato, che controllo con quali gruppi sono i diversi server. qa / dev ha sia il server web che i ruoli db. Il bilanciamento del carico viene effettuato da cloudflare.

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

Quindi, per configurare un secondo ambiente qa che includa il mio ultimo backup da live, 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 terreno. Viene fornito come un sistema qa ma con backup e aggiornamenti dell'ultima notte disabilitati (il software viene aggiornato anche la scorsa notte).

Utilizza un approccio "Tutte le uova in un diverso paniere": viene fornito con una posizione diversa / registrar DNS, host DNS, provider di servizi host di sistema. Questa è l'ultima / ultima rete di sicurezza, quindi se tutto è andato in fiamme, puoi arrivare almeno 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 servizio di bilanciamento del carico di Cloudflare reindirizzerà il traffico al sito di sola lettura se tutti i server live hanno fallito.

Quando si tratta di fare un cambiamento, 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'azienda produrrà. Ad esempio, l'introduzione di ReSharper nella pipeline di sviluppo è stata piuttosto semplice, dato che sono stato in grado di dire qualcosa sulla linea:

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

Se dovessi metterlo in prospettiva per il business, puoi dire che puoi assumere qualcun altro e ottenere un ulteriore 20% di produttività per £ 6k, oppure puoi ottenere lo stesso risultato spendendo 50 sterline su una licenza ReSharper. Una volta che le cifre sono di fronte al business, la decisione sarà facile da fare.

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

Puoi chiedere ai tuoi colleghi sviluppatori di tenere traccia delle ore trascorse ogni settimana sulla configurazione delle applicazioni per lo sviluppo, l'implementazione, ecc. Ad esempio, dieci ore di tempo per gli sviluppatori senior potrebbero costare £ 500. 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 fornisci un costo annuale.

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