Ambiente di sviluppo diverso da Test & amp; Ambienti di produzione?

Question

Cosa diresti se uno sviluppatore volesse implementare un ambiente di sviluppo sql2008, ma eravamo ancora costretti a usare un test sql2000 e un ambiente di produzione sql2000?

Ci sarebbe qualcosa di sbagliato nell'usare sql2008 su un server di sviluppo? Ovviamente dovresti sapere quali funzionalità non potresti utilizzare, quindi non hai avuto problemi a migrare il tuo lavoro dai server sql2008 a sql2000.

Answer 1

Eviterei fortemente di sviluppare una versione locale diversa dagli ambienti dev / qa / prod. Il più delle volte non succederà nulla, ma quando lo fa può richiedere un'eternità per rintracciare il problema. Non solo, potresti non essere mai in grado di replicarlo localmente poiché hai un ambiente diverso.

Answer 2

Uso delle funzionalità SQL di base: andrà tutto bene.

Non ho idea del motivo per cui usi questo ambiente, ma è meglio usare l'ambiente e DEV, QA e Production simili, per evitare sorprese durante la produzione.

Penso che SQL 2000 utilizzi OLEDB e SQL 2008 sia possibile utilizzare il provider ADO.NET, e potrebbero esserci molte più differenze che potresti incontrare. quindi il consiglio di NON FARLO.

Answer 3

Non vedo perché avresti un ambiente di sviluppo che utilizza una versione più recente di SQL Server se i tuoi ambienti di staging e produzione non lo sono.

Indipendentemente dal software che agirà diversamente in base alla versione, potrebbe esserci un bug che potrebbe sorgere non mantenendo le stesse versioni. Consiglio di utilizzare le stesse versioni in tutto il tuo ambiente.

Answer 4

Che ne dici di configurare una macchina virtuale (ad es. in Virtual Server 2005 R2 SP1 con aggiornamento) su cui è presente l'ambiente SQL Server 2008? Ciò garantirebbe di non contaminare gli ambienti SQL 2000 con esso, consentendo allo stesso tempo di provare. Puoi configurarlo come una macchina virtuale su una macchina separata o semplicemente aggiungerlo come una macchina virtuale sulla tua macchina di sviluppo.

Answer 5

Penso che la migliore pratica sarebbe quella di mantenere tutti i tuoi ambienti uguali. Vedo che è utile provare nuove funzionalità sul nuovo ambiente per determinare se sarebbe utile aggiornare i sistemi di test e live.

Answer 6

Cosa c'è da guadagnare usando il 2008 rispetto al 2000 se sai di averlo fatto funzionare nel 2000?

Ci sono così tanti problemi nel fare questo:

1. Le prestazioni potrebbero essere totalmente diverse anche con lo stesso SQL
2. I pacchetti DTS sono gestiti in modo totalmente diverso
3. È possibile utilizzare inconsapevolmente un codice incompatibile con SQL2000. Non lo sapresti fino a quando non lo trasferirai per testare o vivere e a questo punto avresti potuto fare molto spreco di sviluppo attorno al codice incompatibile.
4. etc etc etc ...

Non c'è assolutamente alcun motivo per utilizzare una versione diversa per dev del proprio ambiente LIVE. Finirà per causare dolore e incoerenze.