Quanto accesso al database dovrebbero avere gli sviluppatori? [chiuso]

Quindi ho lavorato in molti posti di lavoro diversi come sviluppatore e il mio livello di accesso al database è stato variato. In genere non ho accesso al db di produzione.

Il più delle volte ho accesso al database di test, ma varia. A volte posso fare e modificare database e dati come mi pare, ma di solito ci sono altri accordi. Come se potessi avere solo accesso in lettura ai dati.

Ho lavorato in un posto in cui un team DBA avrebbe gestito i database, non avremmo potuto apportare modifiche a meno che non avessimo inviato un modulo con lo script sql affinché "ispezionassero". In genere non avevano molto a che fare con il progetto stesso, quindi la maggior parte delle volte era solo premere F5.

Sinceramente, posso capire perché Prod deve essere bloccato, ma preferisco avere lo stesso accesso al database negli ambienti di sviluppo e test. Penso che la maggior parte degli sviluppatori siano ragionevolmente in grado di conoscere un database. Ma mi piacerebbe sentire le opinioni però? Quanto accesso al database dovrebbero avere gli sviluppatori? Ci possiamo fidare di non rompere nulla lassù?

Gli sviluppatori hanno bisogno dell'accesso in lettura a tutti i database incluso prod. A volte il problema è che i dati su Prod non sono quelli che si aspettavano di avere e hanno bisogno di vedere i dati che stanno causando il problema perché non possono riprodurli su dev.

Gli sviluppatori non dovrebbero avere diritti di scrittura dei dati di produzione o diritti per creare oggetti. Non dovrebbe succedere nulla che non faccia parte di una versione ufficiale. Troppe volte, le persone fanno una soluzione rapida a prod che non funzionano, facendo sì che prod sia ancora più confuso o funzionante ma dimenticano di inserire il codice nei server dev / QA / Staging e peggio ancora nel sorgente repository di controllo e il codice viene sovrascritto circa un mese dopo nella prossima versione ufficiale.

Preferisco che gli sviluppatori dispongano dei diritti completi di QA del database perché la distribuzione su un altro server li aiuta a vedere se ci sono delle lacune nel loro processo di distribuzione (oops ho dimenticato che ho cambiato quella tabella per fare così e così e oops ho dimenticato che ho fatto quel cambiamento utilizzando la GUI e non in uno script nel controllo del codice sorgente, ovvero come devono avvenire eventuali modifiche strutturali al database).

Quando si dispone di un nuovo client di tipo Enterprise che disporrà di un proprio set di server, le autorizzazioni potrebbero essere semplificate prima di diventare attive. Questo perché devono accadere così tante cose e le poche persone che riescono a farlo accadere sul sito vengono rimpatriate e talvolta hanno anche bisogno di prendersi del tempo libero. In particolare, le persone che stanno importando dati da un altro sistema, potrebbero essere incaricate di metterli in produzione prima del lancio se il dataload impiegherà molto tempo. Queste persone tendono ad essere specialisti dei dati e c'è un livello di comfort più elevato che consente loro di accedere temporaneamente ai prodotti rispetto allo sviluppatore medio dell'applicazione. Questo non è un lusso che hai quando vai su un server di produzione già attivo.

Una delle cose più critiche sulla limitazione dei diritti di produzione al database è che gli sviluppatori devono quindi assicurarsi che il loro lavoro sia in una forma che può essere distribuita da qualcun altro. Questo tende a migliorare la qualità del lavoro perché non stanno cercando di fare correzioni al volo perché hanno dimenticato qualcosa o qualcosa non ha funzionato perché lo hanno fatto in modo diverso su prod che deve quando si basano solo sulla memoria. Si perdono anche quegli "oops che ho eliminato l'intera tabella utente per errore perché ho dimenticato di evidenziare un tipo di incidente" clausola where "quando le distribuzioni di prodotti utilizzano esclusivamente script che vengono eseguiti nel loro insieme e non un comando alla volta, come è tipico quando gli sviluppatori esegui cose su prod. È più probabile che un team con diritti limitati a creare database sia in grado di memorizzare le modifiche al database anche nel controllo del codice sorgente.

Beh, è ​​davvero una questione di "Vampiri (programmatori) contro lupi mannari (amministratori di sistema)", come Jeff Atwood ha messo qui .

Di solito (questo significa che c'è il lusso di configurare un ambiente completo), lo sviluppatore ha accesso a:

• Server di produzione
  • Nessuna (SA / PM si applicherà per la configurazione dello schema, l'utente finale fornirà i dati di init)
• Server UAT
  • Nessuno (SA / PM si applicherà per l'impostazione dello schema e il seeding dei dati di esempio)
• Server di test / QA
  • Di solito lo sviluppatore invierà lo script di configurazione dello schema al team QA e il QA crea le tabelle
  • Gli sviluppatori hanno pieno accesso ai database ma raramente lo modificano
  • Gli sviluppatori possono aiutare i colleghi del QA a seed / patch / eliminare alcuni dati
• Server di sviluppo / localhost
  • Accesso completo

Il motivo principale dietro cui gli sviluppatori non dovrebbero toccare i server di produzione è: quando qualcosa va storto, il team operativo è responsabile, ma non gli sviluppatori.

Il minimo indispensabile per completare il lavoro.

Se a tutti gli sviluppatori viene concesso l'accesso completo al DB, la possibilità che uno si arrabbi (o si ubriachi, o sia estremamente stanco o ...) e faccia un danno grave è molto più alto se solo può leggere da un database.

Se il tuo lavoro può essere svolto principalmente senza accesso in scrittura al DB (e per lo più intendo al massimo poche richieste di modifica a settimana), non hai davvero bisogno dell'accesso in scrittura.

Ci sono 2 desideri in competizione in tutto l'ambiente di lavoro.

• Il desiderio di dare accesso alle persone in modo che possano risolvere i problemi da soli. Ciò consente loro di essere veloci e self service.
• Il desiderio di limitare e controllare l'accesso per prevenire danni, tempi di inattività o perdita di dati (intenzionali o meno).

Parte di ciò che modella l'equilibrio che viene raggiunto (o dovrebbe comunque) è l'aspettativa fissata per gli sviluppatori. In ogni lavoro che ho avuto in cui gli sviluppatori hanno avuto accesso a tutto ciò che le aspettative erano limitate. Accedi al sistema solo se sai cosa stai facendo. Ciò significava che sapevi cosa stavi facendo sia dal punto di vista dello sviluppatore che del sistema. Se non eri sicuro in nessuna delle due aree, non avresti avuto accesso ai sistemi senza qualcuno che ti avesse accompagnato.

Per riassumere, se non lo sai, non dovresti avere accesso a nessun sistema diverso dai sistemi di sviluppo facilmente ricostruibili . Se lo sai, di quanto sai non dovresti accedere a nessun sistema tranne i tuoi sistemi di sviluppo facilmente ricostruibili .

Gli sviluppatori dovrebbero avere pieno accesso ai database degli sviluppatori (idealmente dovrebbero eseguire un server locale, ma ciò non è sempre possibile). Dovrebbero avere accesso al database build / QA, ma solo ai dati (dovrebbero avere il permesso / inviare un ticket per cambiare la struttura). Gli sviluppatori non dovrebbero mai avere un accesso casuale al database di produzione (a meno che non si tratti di una piccola azienda / progetto e anche gli sviluppatori supportino la produzione).

Penso che la chiave qui sia quale livello di responsabilità hanno gli sviluppatori. In una grande organizzazione con molti sviluppatori, avranno probabilmente accesso allo sviluppo solo con accesso in sola lettura a QA / Test.

Tuttavia, ci dovrebbero essere persone nel team di sviluppo con pieno accesso a tutti gli ambienti. Di solito è la persona responsabile di apportare correzioni, ecc. Sebbene sia un po 'rischioso, è un compromesso tra quanto ti fidi dello sviluppatore, quanto velocemente vuoi che le cose vengano riparate e i rischi associati a incasinare il sistema o la divulgazione di informazioni nel sistema .

Ho lavorato in un grande negozio IT e abbiamo avuto accesso in lettura alla produzione per la maggior parte delle persone. Come sviluppatore principale avevo anche le autorizzazioni per il database di produzione. Dovevo ancora seguire le stesse linee guida degli amministratori di sistema e dei DBA in termini di processo e scartoffie, ma se necessario potevo anche fare una soluzione urgente.

C'è un problema correlato che molti di noi dimenticano: potremmo non essere le uniche persone che usano il database! Tendiamo a dare questo per scontato, ma non dovremmo. Anche i siti di piccole dimensioni potrebbero avere uomini d'affari che eseguono strumenti di terze parti contro il database per i loro report. I siti aziendali avranno quasi sempre più utenti delle tabelle del database e la tua "piccola" modifica potrebbe interrompere le loro applicazioni e viceversa.

Quindi questa deve essere la prima domanda. Il secondo deve essere lo staff disponibile - ho lavorato in siti con amministratori di sistema che erano protettivi nei confronti del loro territorio, ma in realtà non erano così buoni. (Probabilmente è per questo che erano così territoriali: sapevano che avrebbero preso molto calore se qualcuno si fosse guardato intorno.) A volte devi avere più accesso di quanto desideri.

Ma in un mondo ideale concordo con i punti sollevati da altre persone. Non voglio accedere ai dati in tempo reale poiché, francamente, non voglio la responsabilità. Pensaci: se ho accesso operativo e c'è una violazione, dovrò impiegare molto tempo a dimostrare che non avevo nulla a che fare con esso. Potrei dover dimostrare di non aver nascosto i dati per motivi personali, ecc. Molti siti prendono molto sul serio la privacy, esp. siti governativi.

Non desidero nemmeno l'accesso in scrittura / amministratore al sistema del gruppo di test. Se non riesco a fare qualcosa sul sistema di produzione, non voglio essere in grado di farlo sui sistemi di test. L'accesso in lettura è l'eccezione poiché è necessario per aiutare a capire cosa sta succedendo.

I sistemi di sviluppo, sia individuali che dipartimentali, sono una storia diversa. Ma anche qui, in pratica, di solito è meglio eseguire tutte le modifiche al database attraverso una persona puntuale anziché far fare a tutti le proprie cose.

Concordo pienamente con tutta la risposta, dicendo "il minor numero di privilegi possibile per gli sviluppatori su database di prodotti". Ma ad essere onesti, chi può negare agli sviluppatori l'accesso al database se vogliono ottenerlo. Con sufficiente volontà (sia essa criminale o per sempre) otterranno l'accesso necessario.

Chi può trattenerli dal mettere un semplice editor SQL nell'applicazione? In questo modo possono utilizzare il database con i privilegi dell'applicazione. Nella maggior parte dei casi questo è tutto ciò che serve. Quando il database è configurato in modo sicuro, potrebbero non avere il privilegio di creare o eliminare oggetti, ma hanno almeno accesso in lettura e scrittura ai dati.

Ho già qui le persone che piangono. Ma sii onesto con te stesso, non hai il controllo completo dell'applicazione distribuita in produzione, a meno che tu non lo scriva da solo (e nemmeno allora, pensi alle librerie). E per tutti gli sviluppatori, come già detto da Erin, sei anche responsabile dell'ambiente di produzione, non solo delle persone operanti. Quindi usa i tuoi privilegi con saggezza.