Sviluppo su un server di produzione

Oggi sono stato urlato per lo sviluppo di un'applicazione su un server di produzione. Citazione, "lo sviluppo su un server di produzione non è accettabile, mai! "

Ecco la situazione

1. Ho impostato un'istanza di sviluppo: http://example.com:3000
2. L'istanza di produzione è: http://example.com
3. Completo tutto il mio lavoro di sviluppo http://example.com:3000e quando il cliente è soddisfatto delle modifiche, le sposto http://example.com.

L'applicazione con cui sto lavorando è una vecchia applicazione Ruby on Rails e devo dire che inizialmente ho provato a impostare un ambiente di sviluppo localmente, ma non sono mai riuscito a farlo funzionare. Dopo aver provato per un po ', ho rinunciato e ho deciso di sviluppare sul server di produzione.

Ancora una volta, sono un idiota? Probabilmente sì, ma ho fatto lo sviluppo web per un paio d'anni e non ho mai incontrato una situazione del genere. Chi ha ragione e perché?

Mi sviluppavo sul server di produzione. Può funzionare bene, ma non è consigliabile per almeno due motivi:

1. Il codice di sviluppo può causare loop infiniti, perdite di memoria o altri problemi che bloccano la CPU, consumano tutta la memoria o influiscono in altro modo sul server in modo tale da influire sul codice di produzione.
2. Se devi apportare modifiche ai componenti dell'ambiente server come parte del tuo lavoro di sviluppo, come la versione di Ruby o MySQL o qualsiasi altra cosa, sarai in difficoltà.

Come altri hanno già 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 commenti sottolineano, se la tua istanza Dev viene compromessa (ad esempio, perché ti dimentichi di cancellarla e qualcuno scopre un enorme exploit di sicurezza in Rails), ora hai una macchina accessibile pubblicamente con la tua app in azione come gateway in. Che sarebbe ... sfortunato.

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

• Si è verificato un errore?
• Quanto tempo ci vorrebbe per ripristinare una modifica (lavoro principalmente in C ++, quindi il rollback di un binario può richiedere molto più tempo rispetto a Ruby, specialmente quando hai "perso" il vecchio binario e devi ricompilare)
• Che l'effetto del cambiamento (guida approssimativa: avvitare i dati memorizzati è così molto peggio che non la memorizzazione o la visualizzazione dei dati, che a sua volta è peggio che non mostra la pagina a tutti)
• Se avessi fatto un casino e uscissi dalla porta, qualcuno avrebbe saputo cosa avresti fatto?
• C'era un'altra opzione di spiegamento che avrebbe impedito / minimizzato / rilevato il malfunzionamento prima dell'impatto?

Questo ti dà il calcolo finale:

• Quanto costerebbe questo inganno completamente prevenibile?

Questo è quanto meno vale la tua intera struttura di gestione per il ragazzo che prende le decisioni di bilancio. Quindi urlando.

Se stai lavorando sulla pagina "Chi siamo" interna dell'azienda e scrivi il tuo nome come L. Thomas "simile a Dio", imbarazzante problema con il soprannome; se stai lavorando sull'app di acquisto business-critical, e finisce per sbaglio accidentalmente testo in chiaro i dettagli della carta di credito sulla homepage ... problema di causa. Tra questi due estremi si trovano tutto dall'abuso, la paralizzante produttività e tutte le altre cose che possono allontanare i clienti.

Il motivo per non consentirlo anche per la pagina "Chi siamo" è perché la codifica direttamente in produzione crea dipendenza . Inizi a farlo solo per i minori, ma con il passare del tempo è molto più veloce non dover ripristinare l'env DEV.

Oltre a ciò, la dimensione del business può avere un grande effetto. In una squadra di due uomini, quando qualcosa si spaventa, ti pieghi sulle spalle e vai "Oi, idiota, rimettilo". In un'azienda di 300 persone, devi iniziare a preoccuparti se si tratta di incompetenza o malizia, i manager possono essere ritenuti responsabili per cose su cui non avevano alcun controllo, ecc.

Alla fine della giornata, se segui la procedura e fallisci, controllano cosa c'è che non va nella procedura. Se aggiri la procedura e fai un casino, ora è solo una tua responsabilità, anche se la colpa viene sparsa un po '. Se vuoi tirare i dadi su questo dipende da te.

Ho provato a configurare un ambiente di sviluppo localmente, ma non sono mai riuscito a farlo funzionare. Dopo aver provato per un po ', ho rinunciato e ho deciso di sviluppare sul server di produzione.

Supporto le dichiarazioni di EVITARE lo sviluppo su un server di produzione. Potresti essere giustificato a farlo sotto GUN, se si tratta di una correzione di battitura nel file di configurazione e insistito dal tuo manager.

WHY NOT?- Perché è molto rischioso e pron diventare un'abitudine in seguito che ti catturerebbe male. Perché, errori di produzione / guasti fatali potrebbero costare il licenziamento .

Permettetemi di ripeterlo di nuovo, anche se se avete richiesto di fare una correzione per errore di battitura sul productionserver, prima fatelo Staging. o in altre parole testare le modifiche, testarlo e testarlo nuovamente prima di metterlo in produzione.

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

Modifica: lo sviluppo su server di produzione, in quanto un ambiente separato NON è accettabile . Qualsiasi problema causato dal 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 nella sicurezza, quando il mio precedente collega aveva cercato di utilizzare il server di produzione WinServer 2003 per scopi di sviluppo.

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

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

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. Non vuoi mai esporlo all'utente.

Sì, puoi registrarli invece di mostrarli al client, ma ciò rende il debugging molto meno divertente di quanto non lo sia già.

Aggiunto Risolvendo il problema secondario di avere problemi con l'istanza di sviluppo: ho avuto un grande successo con l'implementazione di una VM basata su VirtualBox che duplica il nostro ambiente di produzione (escluso l'hardware, ovviamente) con un server Ubuntu .

Sono abbastanza sorpreso che nessuno abbia ancora menzionato il motivo più importante, perché è assolutamente vietato sviluppare sui server di produzione:

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

Un piccolo errore in un punto porta a enormi problemi in altri calcoli e poi, il giorno successivo, tutti i dati vengono spazzati via e il cliente è incazzato. Questo è molto, molto peggio di un bug nell'interfaccia utente o di un piccolo arresto qua e là.

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

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

1. Costruisci localmente.
2. Spingilo in un tipo di scatola che imita la produzione il più possibile per vedere se suona bene lì.
3. Eventualmente spingerlo in un QA o istanza di certificazione per passare al team cliente / QA per rivedere le modifiche.
4. Spingi alla produzione.

Puoi usare le ricette Capistrano abbinate a GitHub per gestire tutte queste cose per te. Se devi farlo ogni volta a mano, può invecchiare velocemente.

Un altro problema con lo sviluppo di prod è che, a volte, queste cose si perdono nel controllo del codice sorgente e una versione futura potrebbe annullare la modifica della correzione rapida.

Se ti trovi in ​​una società quotata in borsa negli Stati Uniti, non dovresti nemmeno avere accesso ai prodotti per ragioni normative. In generale, in nessuna azienda uno sviluppatore dovrebbe avere accesso ai prod (per le risposte indicate in tutte le risposte e anche per possibili motivi legali), quindi anche il tuo manager ha torto nel concederti i diritti su quel server.

Le regole che usano "sempre" o "mai" sono generalmente mal definite. Ci saranno casi limite in cui sarà giustificata infrangere una buona pratica. Un consiglio molto migliore sarà "Non toccare i server di produzione a meno che tu non abbia ottime ragioni"

Nella mia carriera ho trovato solo due motivi per modificare 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 si possono permettere di attendere per passare attraverso il normale processo di distribuzione se impiega più di qualche minuto. Dopo che questo è stato eliminato con la direzione. Se sei fortunato dovresti averne solo pochi per tutta la tua carriera.

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