È male sviluppare in base ai dati di produzione?

Ho sempre sentito che è una cattiva pratica sviluppare dati di produzione e attualmente sono in procinto di passare a un modello Dev> Stage> Production , principalmente perché ho un nuovo dipendente con competenze minime e preferirei non averlo lavorare direttamente con i dati di produzione ancora.

Ma per molto tempo ho lavorato direttamente con i dati di produzione con il minimo mal di testa, tranne forse per alcuni errori che si insinuavano qua e là, cose come problemi di ortografia, testo alternativo errato, collegamenti che puntavano verso una posizione sbagliata. Ciò sembra dovuto alla mancanza di una revisione tra pari da parte mia, non a causa del lavoro con i dati in tempo reale.

Quindi perché sviluppare sul sito dal vivo è una cattiva pratica?

Se durante lo sviluppo si eseguono comandi SQL che includono INSERTo UPDATEsu tabelle di database esistenti, si corre un rischio nella misura in cui tali tabelle di database sono mission-critical.

Alcune posizioni sincronizzano i dati di produzione nel database di sviluppo a intervalli regolari, ad esempio una volta alla settimana o su richiesta dello sviluppatore, in modo da disporre di nuovi dati con cui sviluppare.

Ma se i tuoi dati di produzione non sono a rischio per quello che stai facendo, ad esempio, se stavi semplicemente sviluppando una vista di alcuni dati, di solito non è un grosso problema. Ora, se stai eseguendo report che eseguono scansioni di tabelle, allora hai il potenziale per bloccare una tabella, quindi i tuoi utenti esistenti ne saranno interessati.

Rimanderei al mio amministratore del database in casi come questo, se non ci fosse un DBA "ufficiale", sbaglierei per precauzione. È abbastanza semplice creare un database di sviluppo, anche per me stesso. In una squadra è vitale. In caso contrario, se si insistesse per creare un solo database, è possibile aggiungere un prefisso alle tabelle del database di sviluppo DEV_e sentirsi un po 'meglio. Sì, ciò richiede alcune modifiche al codice, ma nello sviluppo l'aggiunta di alcune variabili durante lo sviluppo $debug = true, ecc., Di solito vale la pena.

Molti modi per affrontarlo. Dipende molto dalla tua situazione.

NON si desidera sviluppare in base ai dati di produzione sul proprio server di produzione. Ci sono un paio di ragioni enormi.

1. Lo sviluppo rallenta la tua scatola di produzione e crea vulnerabilità. Cosa succede se lasci il computer sbloccato e vai via?
2. Se commetti un errore, le persone che visitano il tuo sito possono vederlo.
3. Se esegui qualsiasi tipo di aggiornamento dei dati all'interno di una Transazione nel tuo database e non lo commetti immediatamente o la transazione impiega un po 'di tempo per finire, metterai un blocco su tutte le tabelle coinvolte e potresti causare un timeout .
4. Alcuni sistemi di database, in particolare SQL Server, a volte eseguono blocchi di tabelle solo sulle istruzioni SELECT! Ciò significa che puoi dare involontariamente alle persone timeout o pagine di errore sul tuo sito.

Non farei mai lavori di sviluppo su una live box, se possibile. La soluzione migliore è fare un backup del database e delle pagine e lavorare con la copia e quindi inviare gli aggiornamenti. Uno strumento che mi ha aiutato moltissimo è SyncToy di Msft.

Bene, puoi davvero rovinare i dati. Immagina di lasciare una clausola where. Anche se si dispone di backup orari, sarebbe un problema da risolvere.

Se non guidi senza una cintura di sicurezza, non sviluppare i dati di produzione. Solo un problema di sicurezza.

Se sono disponibili dati di produzione, è ragionevole utilizzarli per i test, ma utilizzare un database di test separato con una copia di tali dati. Altrimenti molte cose funzioneranno per i tuoi pochi record di test "blabla" ma non per uno scenario reale.

E per lo sviluppo di dati di produzione dal vivo - ricorda le leggi del Murphy "Tutto ciò che può andare storto andrà storto", ed è così facile fare un piccolo errore con grandi conseguenze negative.