Sviluppo su un server di produzione

Ero solito sviluppare sul server di produzione. Può funzionare bene, ma è sconsigliabile per almeno due ragioni:

1. Il codice di sviluppo può causare loop infiniti, perdite di memoria o altri problemi che bloccano la CPU, consumano tutta la memoria o influenzano in altro modo il server in un modo che avrà un impatto sul codice di produzione.
2. Se è necessario apportare modifiche ai componenti dell'ambiente server come parte del lavoro di sviluppo, come la versione di Ruby o MySQL o qualsiasi altra cosa, sarai in un vicolo cieco.

Come altri hanno affermato, la codifica nell'ambiente PROD espone i tuoi utenti ai tuoi bug. Anche se hai avviato un'istanza diversa, hai ancora risorse hardware condivise e puoi comunque accedere a file e database di produzione. E come alcuni dei commenti sottolineano, se la tua istanza Dev viene violata (ad esempio, perché ti dimentichi di cancellarla e qualcuno scopre un enorme exploit di sicurezza in Rails), hai ora un computer accessibile pubblicamente con la tua app che funge da gateway in Quale sarebbe ... sfortunato.

Diverse aziende hanno risposte diverse a questo, ma possono essere generalmente suddivise in questo modo:

• Si è verificato un errore?
• Quanto tempo ci vorrà per annullare una modifica (lavoro principalmente in C ++, quindi il rollback di un binario può richiedere significativamente più a lungo che in Ruby, specialmente quando hai "perso" il vecchio binario e devi ricompilare)
• Qual è l'effetto del cambiamento (guida approssimativa: l'avvitamento dei dati memorizzati è così molto peggio che non memorizzare o visualizzare dati, che a sua volta è peggio che non mostrare affatto la pagina)
• Se hai sbagliato, allora sei uscito dalla porta, qualcuno saprebbe cosa hai fatto?
• C'era un'altra opzione di implementazione che avrebbe prevenuto / minimizzato / rilevato la svalutazione prima dell'impatto?

Questo ti dà il calcolo finale:

• Quanto costerebbe tutto questo avvitamento completamente prevenibile?

Questo è quanto meno la tua intera struttura di gestione vale per il ragazzo che prende decisioni sul budget. Quindi urlo.

Se stai lavorando sulla pagina interna "Chi siamo" della tua azienda e scrivi il tuo nome per essere L. "God-like" Thomas, imbarazzante problema con il soprannome; se stai lavorando sull'app di acquisto business-critical, e finisce per accidentalmente delimitare i dettagli della carta di credito nella home page ... problema della causa. Tra questi due estremi c'è tutto, da errori di produzione, a una produttività paralizzante ea tutte le altre cose che possono allontanare i clienti.

La ragione per non consentirlo anche per la pagina "Chi siamo" è perché la codifica direttamente nella produzione è avvincente . Inizi a farlo solo per i minori, ma con il passare del tempo, è molto più rapido non dover recuperare l'env del dispositivo.

Oltre a ciò, la dimensione dell'azienda può avere un grande effetto. In una squadra di due uomini, quando qualcosa va per il culo, ti chini su una spalla e vai "Oi, jackass, rimettilo". In un'azienda di 300 persone, devi iniziare a preoccuparti se si tratti di incompetenza o malizia, i dirigenti possono essere ritenuti responsabili per cose di cui non avevano alcun controllo ecc.

Alla fine della giornata, se segui la procedura e fallisci, controllano cosa non va nella procedura. Se si abbassa la procedura e si fa la cacca, ora è la sola responsabilità, anche se la colpa si diffonde un po '. Se vuoi tirare i dadi, dipende da te.

I did try to set up an development environment locally, but I could never get it running. After trying for a while, I gave up and decided to develop on the production server.

SOSTO le dichiarazioni per EVITARE lo sviluppo su un server di produzione. Si può essere giustificati solo a fare sotto la PISTOLA, se si tratta di una correzione di errore di battitura nel file di configurazione e insistito dal proprio manager.

WHY NOT? - Perché, è molto rischioso e pron a diventare un'abitudine in seguito ti farebbe impazzire. Perché errori / errori di produzione fatali potrebbero costarti essere licenziato dal tuo lavoro.

Permettimi di reiterarlo di nuovo, anche se, se hai richiesto di correggere errori di ortografia su production server, prima fallo su Staging . o in altre parole prova le tue modifiche, testalo e di nuovo testalo prima di metterlo in produzione.

Questo è qualcosa che accade spesso in luoghi in cui la cultura di "Fallo veloce e sporco " sembra essere una norma.

Modifica: lo sviluppo sul server di produzione, in quanto un ambiente separato è anche NON accettabile . Qualsiasi problema causato nel tuo lavoro può semplicemente far cadere il server di produzione e influire sulle prestazioni dell'applicazione di produzione . Ad esempio, ricordo un caso in cui c'era un buco di sicurezza, quando il mio collega precedente ha provato a utilizzare il server di produzione WinServer 2003 per scopi di sviluppo.

Questo è davvero un problema di protocollo. Generalmente, questo non è qualcosa che vorresti fare. Vuoi lasciare le macchine di produzione da solo. Possono contenere dati sensibili e non si vuole compromettere le prestazioni o la stabilità dei siti di produzione con un codice non di produzione pronto.

Detto questo, ci sono momenti in cui questo è comunemente fatto. Se sei in una posizione in cui stai pompando un brouchureware a basso traffico o semplici siti CMS, questo sarà probabilmente meno di un problema. Ma se stai lavorando su qualcosa con dati sensibili o processi "business critical", non dovresti rischiare di avere il codice di sviluppo sullo stesso computer.

Un altro motivo importante per non svilupparsi direttamente nella produzione è che un'istanza di sviluppo di solito produce e mostra errori dettagliati e tracce di stack. mai vuoi esporlo all'utente.

Sì, puoi loggarli invece di mostrarli al client, ma questo rende il molto meno divertente di quanto sia già.

Aggiunto Affrontare il tuo problema collaterale di avere problemi con l'istanza di sviluppo: ho avuto un grande successo implementando un VirtualBox basato su VM che duplica il nostro ambiente di produzione (escluso hardware, ovviamente) con un Server Ubuntu .

Sono abbastanza stupito che nessuno abbia menzionato la ragione più importante ancora, perché è assolutamente vietato svilupparsi sui server di produzione:

Non scherzare con i dati di produzione, cosa che può accadere oh così facilmente!

Un piccolo errore in un punto porta a problemi giganteschi in altri calcoli e poi, il giorno dopo, tutti i dati sono spazzatura e il cliente è incazzato. Questo è molto, molto peggio di un bug nell'interfaccia utente o un piccolo incidente qua e là.

Per la maggior parte delle applicazioni, il valore si trova nei dati e non nelle routine.

Cerco sempre di chiedere agli altri sviluppatori quali sono le procedure per la particolare azienda. In generale si, dovresti sempre:

1. Crea in locale.
2. Spingilo su un tipo di scatola che riproduca il più possibile la produzione per vedere se suona bene lì.
3. Se possibile, trasferiscilo a un QA o a un'istanza di certificazione per passare al team cliente / QA per rivedere le modifiche.
4. Invia alla produzione.

Puoi utilizzare Capistrano ricette abbinate a GitHub per gestire tutte queste cose per te. Se devi farlo ogni volta a mano, può diventare vecchio velocemente.

Un altro problema con lo sviluppo su prod è che, a volte, queste cose vengono perse nel controllo del codice sorgente e una versione futura potrebbe annullare la modifica rapida.

Se ti trovi in una società quotata negli Stati Uniti, non dovresti nemmeno avere accesso ai prod per motivi normativi. In generale, in nessuna azienda lo sviluppatore deve avere accesso ai prodotti (per i resons dichiarati in tutte le risposte e per eventuali motivi legali), quindi anche il tuo manager ha torto a permetterti i diritti su quel server.

Normalmente le regole che usano "sempre" o "mai" sono mal definite. Ci saranno casi limite in cui la rottura di una buona pratica sarà giustificata. Un consiglio molto migliore sarà "Non toccare i server di produzione a meno che non ci siano ottimi motivi"

Nella mia carriera ho trovato solo due motivi per cambiare il codice sui server di produzione:

1. Bug o comportamenti che si verificano solo lì e non sono riproducibili nell'ambiente di sviluppo. Questi sono rari ma possono essere molto fastidiosi e difficili da trovare.

2. Correzione diretta di bug critici che non puoi permetterti di aspettare per passare attraverso il normale processo di distribuzione se impiega più di qualche minuto. Dopo questo è stato autorizzato con la gestione. Se sei fortunato, dovresti averne solo pochi per tutta la tua carriera.

Entrambi sono meglio lasciati agli sviluppatori senior che conoscono i sistemi intimamente.