Gli sviluppatori dovrebbero essere autorizzati a utilizzare LocalDB rispetto a un'istanza di "sviluppo"?

Proprio come la vena della domanda che è stata postata qui in precedenza intorno a "Gli sviluppatori dovrebbero essere in grado di interrogare i database di produzione? " Volevo farti un'idea su un altro argomento particolarmente fastidioso!

Molte aziende impediscono agli sviluppatori di installare SQL Server Express e simili su macchine di sviluppo, promuovendo invece l'uso di server SQL di sviluppo centralizzati.

Nello specifico, ciò viene fatto per garantire:

• Coerenza a livello di patch tra server di sviluppo e produzione
  
• Capacità di provare e validare eventuali patch su quanto sopra
  
• La sicurezza dei dati; solo i dati sui server di sviluppo vengono utilizzati per lo sviluppo
  
• recuperabilità; i dati sono recuperabili e comunque sottoposti a backup
  
• Differenze di confronto che possono causare problemi quando si passa alla produzione

Per me tutti questi argomenti sono particolarmente invalidi, forse con l'eccezione di quelli di correzione; ma se un database su un computer locale viene utilizzato esclusivamente per attività di sviluppo e non per test, il patching verrebbe dimostrato quando un'applicazione passerà da Test / UAT ecc. alla produzione.

Le regole di confronto non sembrano essere un motivo valido, come se questo fosse un problema per il database che dovrebbe essere impostato al momento della creazione. Solo SharePoint e SCCM hanno problemi al riguardo per quanto ne so;)

Ora, supponendo che sia SOLO per lo sviluppo, e il database non verrà "spostato" alla produzione e gli unici movimenti sarebbero:

• Script che hanno creato il database generato per la distribuzione in produzione
• Backup da sistemi di "produzione" di terze parti ripristinati e troncati ove appropriato per la convalida e lo sviluppo

Qualcuno può vedere qualche problema? Mi sto perdendo qualcosa?

Immagino che una delle maggiori preoccupazioni sia la possibilità che le istanze di db locali non siano aggiornate, ma si tratta di un problema di gestione del software, non di un DBA IMO.

Sì. Tutti gli sviluppatori dovrebbero avere un'istanza locale di SQL Server E un'istanza condivisa di SQL Server. Esistono per scopi diversi. Entrambi sono necessari.

Forse il tuo ambiente attuale è simile a questo?

Sopra, diversi sviluppatori stanno creando e modificando le modifiche in un database di sviluppatori SQL comune. Questo non va bene. Microsoft MVP Troy Hunt documenta alcuni dei punti deboli di questo approccio antiquato, qui . I principali sono ...

1. Incapacità di controllare adeguatamente la fonte. GRANDE!
2. Impossibilità di ottimizzare le prestazioni senza diritti a livello di server.
3. Incapacità di sperimentare senza influenzare gli altri.

Questo modello provoca conflitti tra sviluppatori. Un sintomo del conflitto è l'espansione del database. Molti database vengono creati mentre gli sviluppatori cercano uno spazio sicuro e isolato per svolgere il proprio lavoro. Esistono diversi motivi per cui l'organizzazione si aggrappa a questo modello. Il primo è che non hanno investito in un adeguato sistema di controllo del codice sorgente . Un altro è che hanno semplicemente ereditato questo modello di progettazione e non possono essere disturbati a cambiarlo. Microsoft si è costantemente allontanata da questo schema e si è avvicinata a qualcosa di più simile a questo ...

Nel diagramma sopra, ogni sviluppatore utilizza Visual Studio per scrivere e salvare le modifiche del proprio database in un'istanza locale di SQL Server. Tali modifiche locali vengono quindi sincronizzate in un sistema di controllo del codice sorgente appropriato. Qui ogni sviluppatore può progettare e sperimentare in un ambiente in cui le sue modifiche non avranno alcun impatto su nessun altro fino al momento del check-in. E a quel punto i conflitti saranno risolti.

Il database locale usato sopra potrebbe essere edizioni LocalDB, Express o Developer. Simple-Talk fa un ottimo lavoro soppesando i pro ei contro di ciascuno qui . C'è un motivo per cui Microsoft ha creato così tante scelte per i database di sviluppo locale: LocalDB, Express, Developer .. dovremmo usarli!

Se è necessario scegliere, è difficile non sostenere che per ogni sviluppatore sia installata una versione locale di SQL Server Developer Edition. È completamente gratuito e ha una parità di funzionalità con l'edizione Enterprise. Consentirà a tutto il team di esplorare e progettare in tutto lo stack Microsoft BI (SQL Server, SSIS, SSRS e SSAS) in modo sicuro.

Possiamo ancora conservare il database comune, ma non dovrebbe essere per lo sviluppo, dovrebbe essere per i test. È un server in cui le impostazioni a livello di sistema sono sincronizzate con la produzione. Hardware, sistema operativo, patch, ecc.

Per me tutti questi argomenti sono particolarmente non validi

Ok. Ma non sono per il resto di noi. Perché?

Coerenza a livello di patch tra server di sviluppo e produzione

il patching sarebbe dimostrato quando un'applicazione è passata attraverso Test

Il patching può risolvere problemi di stabilità e corruzione dei dati che altrimenti affliggerebbero gli sviluppatori. Dovrebbe essere fatto su macchine di sviluppo a prescindere.

La sicurezza dei dati; solo i dati sui server di sviluppo vengono utilizzati per lo sviluppo

È utile separare "ciò che dovrebbe essere" da "ciò che è". Gli sviluppatori finiscono con dati sensibili (non necessariamente PII, ma neanche liberi) sui loro database. Succede.

recuperabilità; i dati sono recuperabili e comunque sottoposti a backup

Super importante.

Differenze di confronto che possono causare problemi quando si passa alla produzione

Solo SharePoint e SCCM hanno problemi al riguardo

Tutto ciò che utilizza una tabella temporanea avrà questo problema. È estremamente comune Non te ne accorgi mai perché la maggior parte delle persone cerca in primo luogo un confronto standard.

supponendo che sia SOLO per lo sviluppo e che il database non verrà "spostato" in produzione

Perché dovremmo supporre che? Le cose vanno spesso dallo sviluppo alla produzione. In quale altro modo viene popolata la produzione per la prima volta? Script puri? Non necessariamente quando l'applicazione è in pre-produzione da un po 'di tempo.

Immagino che una delle maggiori preoccupazioni sia la possibilità che le istanze di db locali non siano aggiornate, ma si tratta di un problema di gestione del software, non di un DBA IMO.

Devi semplicemente rilasciare una dichiarazione su ciò che fai e non lo supporti e perché.

LocalDB è una parte fondamentale di SSDT ora e inevitabile. Tuttavia, non è accessibile in remoto e non ha un componente di pianificazione (Express presenta problemi simili). Pertanto, in genere non è supportato dai DBA per quanto riguarda backup, manutenzione e controlli di integrità.

Tuttavia, il consolidamento su server di sviluppo centralizzati ha ancora senso. E ora che Developer Edition è gratuita, è ancora più facile giustificare averne di più.

Concettualmente parlando, sei sulla strada giusta. Per un'organizzazione che ha un processo di sviluppo maturo / Software Development Life Cycle (SDLC) che include controllo del codice sorgente, integrazione continua (CI), test automatizzati e un gruppo IT che sa gestire vari ambienti e workstation per mantenerli sincronizzati per quanto riguarda i livelli di software e patch e sviluppatori disciplinati che a) seguono il processo, b) collaborano e c) lavorano con l'IT, quindi avere 50 (o comunque molti) DB di sviluppo in grado di funzionare:

• Sì, è possibile mantenere software e livelli di patch coerenti su qualsiasi numero di workstation.
• Sì, eventuali "problemi" possono emergere in test automatici e / o ambienti QA / UAT.
• Molti DB di sviluppo non sono così facili da eseguire il backup, ma neanche impossibile. Se si utilizzano i profili di roaming, è possibile eseguire il backup dei file di dati nella cartella "Impostazioni locali" di ciascun utente Windows. O almeno può essere programmato dall'IT per catturare i file da tutte le workstation di sviluppo, in modo simile a come garantirebbero che tutti siano opportunamente patchati.

MA, come con quasi tutto il resto, si riduce davvero al contesto della situazione.

Uno dei vantaggi di avere DB di sviluppo separati è che è possibile lavorare contemporaneamente su diversi progetti senza influire reciprocamente. (Naturalmente, questo potrebbe essere l'unico vantaggio.)

TUTTAVIA, ci sono varie questioni da considerare:

• Qual è la dimensione del team e quante persone stanno lavorando a un particolare progetto? Più persone lavori su un progetto, più avrai bisogno di un server di sviluppo condiviso / centralizzato in modo che tutti possano ricevere tutte le modifiche.

• Per quanto riguarda le regole di confronto, SQL Server Express LocalDB ha una sfumatura / limitazione / limitazione particolarmente fastidiosa:

  Le regole di confronto dell'istanza per LocalDB sono impostate su SQL_Latin1_General_CP1_CI_AS e non possono essere modificate. Le regole di confronto a livello di database, a livello di colonna e a livello di espressione sono normalmente supportate. I database contenuti seguono le regole di confronto metadati e tempdb definite dalle regole di confronto dei database contenuti .

  Le regole di confronto a livello di istanza influiscono non solo tempdb(ovvero la risoluzione del nome oggetto con ambito db e le regole di confronto predefinite per le tabelle temporanee ma non le variabili di tabella), ma anche i nomi delle variabili locali nomi dei cursori / nomi dei parametri e gotonomi delle etichette. Quindi, se i tuoi server di produzione hanno un confronto a livello di istanza di qualcosa di diverso da SQL_Latin1_General_CP1_CI_AS, LocalDB non è una buona scelta.

• Stai utilizzando le funzionalità Enterprise Edition? Se si tratta solo di fare ricostruzioni dell'indice ONLINE, probabilmente non importa. Ma se stai usando qualcosa come il partizionamento delle tabelle, LocalDB non è una buona scelta.

• Forse il problema più grande è l'ampliamento generale della portata di potenziali problemi derivanti da eventuali disparità ambientali (a livello di sistema operativo, a livello di patch software, configurazione di istanza, configurazione di DB, ecc.) Che potrebbero portare a un bug. Sebbene abbiamo già accettato (in senso generale) che i test automatici / QA / UAT troverebbero questi problemi, ciò non è garantito ! Dato che gli umani commettono errori e che gli umani devono elaborare tutti i test che verifichino tutti i percorsi di codice e tutte le variazioni di dati (tipi, dimensioni, ecc.), È altamente probabile che un numero qualsiasi di scenari non lo faràessere testato e che un bug potrebbe superarlo e non essere notato fino a quando un cliente non lo trova in produzione. Questo accade comunque, ma le possibilità aumentano quando si utilizza LocalDB in modo che ogni sviluppatore possa avere il proprio DB privato.

Ciò che si riduce davvero è: qual è la ragione convincente per usarlo in un ambiente di squadra? In vari lavori, ho sempre lavorato in gruppi in cui c'erano sviluppatori di app e ingegneri di database e mentre gli sviluppatori di app a volte prendevano in giro una procedura memorizzata solo per farlo più velocemente (non abbastanza da noi DBE), i DBE hanno fatto la maggior parte dei Programmazione DB, incluso il controllo (ovvero la correzione) di qualsiasi codice scritto dagli sviluppatori di app. L'uso di LocalDB avrebbe reso molto più difficile lavorare in gruppo. E mentre si utilizza SQL Server Express (o anche Developer Edition) per disporre di istanze personali su ogni workstation di sviluppo accessibile in remoto, facilitando la collaborazione, non è mai stato necessario un livello di isolamento poiché era raro le modifiche al DB per un progetto hanno un impatto negativo su un altro.

Naturalmente, quelli di noi che erano ingegneri di database (DBE) avevano installazioni locali di Express Edition e / o Developer Edition. Ciò significava eseguire test che richiedevano un maggiore controllo sulla configurazione / sicurezza a livello di istanza, ecc. Rispetto a quanto consentito su un server condiviso. E ho usato le istanze locali di tanto in tanto, ma non molto spesso. Ma per i miei progetti personali, adoro LocalDB e lo uso abbastanza frequentemente.