Ambiente de desenvolvimento diferente dos ambientes de teste e produção?
-
05-07-2019 - |
Pergunta
O que você diria se um desenvolvedor quisesse implementar um ambiente de desenvolvimento SQL2008, mas ainda fomos forçados a usar um teste de teste SQL2000 e SQL2000?
Haveria algo errado em usar o SQL2008 em um servidor de desenvolvimento? É claro que você precisaria saber qual funcionalidade você não poderia usar, para não ter problemas para migrar seu trabalho dos servidores SQL2008 para o SQL2000.
Solução
Eu evitaria fortemente desenvolver em uma versão local diferente dos ambientes Dev/QA/Prod. Na maioria das vezes, nada acontecerá, mas quando isso acontece, pode levar uma eternidade para rastrear o problema. Além disso, você pode nunca ser capaz de replicá -lo localmente, pois tem um ambiente diferente.
Outras dicas
Usando os recursos básicos do SQL - você fará ok.
Não tenho idéia de por que você usa esse ambiente, mas é melhor usar o ambiente e o Dev, QA e produção possível, para evitar surpresas ao fazer a produção.
Eu acho que o SQL 2000 usa o OLEDB e o SQL 2008, você pode usar o provedor ADO.NET, e pode haver muito mais diferenças nas quais você pode encontrar. então o Melhor aconselhar isso para não fazê -lo.
Não vejo por que você teria um ambiente de desenvolvimento usando uma versão mais recente do SQL Server se seus ambientes de estadiamento e produção não forem.
Não importa qual software agirá diferente com base na versão, e pode haver um bug que possa surgir ao não manter as mesmas versões. Eu recomendo usar as mesmas versões em todo o seu ambiente.
Que tal configurar uma máquina virtual (por exemplo, no Virtual Server 2005 R2 SP1 com atualização) que possui o ambiente SQL Server 2008? Isso garantiria que você não contaminasse seus ambientes SQL 2000 com ele, e ao mesmo tempo, permitindo que você experimente as coisas. Você pode configurá -lo como uma VM em uma máquina separada ou simplesmente adicioná -la como uma VM na sua própria máquina de desenvolvimento.
Eu acho que a prática recomendada seria manter todos os seus ambientes iguais. Eu posso ver que é muito útil experimentar novas funcionalidades no novo ambiente para determinar se seria uma atualização beneficente do seu teste e sistemas ao vivo.
O que há para ganhar usando 2008 em 2000, se você sabe que faz com que funcione em 2000?
Há tantos problemas em fazer isso:
- O desempenho pode ser totalmente diferente, mesmo com exatamente o mesmo SQL
- Os pacotes DTS são tratados totalmente diferentes
- Você pode, sem saber, usar o código incompatível com o SQL2000. Você não saberia até que o moveu para testar ou viver e, a essa altura, poderia ter feito muito desenvolvimento desperdiçado em torno do código incompatível.
- etc etc ...
Não há absolutamente nenhuma razão para usar uma versão diferente para o Dev do seu ambiente ao vivo. Isso acabará causando tristeza e inconsistências.