Os desenvolvedores devem ter permissão para usar o LocalDB versus uma instância de "desenvolvimento"?

Muito parecido com a veia da pergunta que foi postada aqui anteriormente em torno de "Os desenvolvedores devem poder consultar os bancos de dados de produção? " Eu queria ter sua opinião sobre outro tópico particularmente irritante!

Muitas empresas impedem que os desenvolvedores instalem o SQL Server Express e similares em máquinas de desenvolvimento, promovendo o uso de SQL Servers de desenvolvimento centralizados.

Especificamente, isso é feito para garantir:

• Consistência no nível do patch entre servidores de desenvolvimento e produção
  
• Capacidade de provar e validar quaisquer correções acima
  
• Segurança de dados; somente dados nos servidores de desenvolvimento são usados ​​para desenvolvimento
  
• Recuperabilidade; os dados são recuperáveis ​​e ainda fazem backup
  
• Diferenças de agrupamento que podem causar problemas quando movidas para a produção

Para mim, todos esses argumentos são particularmente inválidos, com talvez a exceção dos que remendam; mas se um banco de dados em uma máquina local for usado puramente para atividades de desenvolvimento e não para teste, a correção será comprovada quando um aplicativo progredir através de Teste / UAT etc. para Produção.

O agrupamento não parece ser um motivo válido, como se isso fosse uma preocupação para o banco de dados, ele deve ser definido quando criado de qualquer maneira. Somente o SharePoint e o SCCM têm problemas em relação a isso, até onde eu sei;)

Agora, supondo que seja APENAS para desenvolvimento, e o banco de dados não será "movido" para produção e os únicos movimentos seriam:

• Scripts que criaram o banco de dados sendo gerado para implantação na produção
• Backups de sistemas de "produção" de terceiros sendo restaurados e truncados quando apropriado para validação e desenvolvimento

Alguém pode ver algum problema? Estou esquecendo de algo?

Eu acho que uma das maiores preocupações seria a capacidade de instâncias de banco de dados locais desatualizadas, mas isso é um problema de gerenciamento de software, não um IMO do DBA.

Sim. Todos os desenvolvedores devem ter uma instância local do SQL Server E uma instância compartilhada do servidor SQL. Eles existem para diferentes propósitos. Ambos são necessários.

Talvez o seu ambiente atual seja assim?

Acima, vários desenvolvedores estão criando alterações e implantando-as em um banco de dados comum do Desenvolvedor SQL. Isto é mau. O MVP da Microsoft, Troy Hunt, documenta alguns dos pontos problemáticos dessa abordagem antiquada, aqui . Os principais são ...

1. Incapacidade de controlar adequadamente a fonte. GRANDE!
2. Incapacidade de ajustar o desempenho sem direitos no nível do servidor.
3. Incapacidade de experimentar sem impactar os outros.

Esse padrão causa conflito de desenvolvedor. Um sintoma do conflito é a expansão do banco de dados. Muitos bancos de dados são criados à medida que os desenvolvedores buscam um espaço isolado e seguro para realizar seu trabalho. Há várias razões pelas quais a organização se apega a esse padrão. A primeira é que eles não investiram em um sistema de controle de fonte adequado . Outra é que eles simplesmente herdaram esse padrão de design e não podem se incomodar em alterá-lo. A Microsoft está constantemente se afastando desse padrão e entrando em algo mais parecido com isso ...

No diagrama acima, cada desenvolvedor usa o Visual Studio para gravar e salvar suas alterações no banco de dados em uma instância local do SQL Server. Essas alterações locais são sincronizadas em um sistema de controle de origem apropriado. Aqui, cada desenvolvedor pode projetar e experimentar em um ambiente em que suas alterações não afetarão ninguém até o check-in. E nesse momento os conflitos serão resolvidos.

O banco de dados local usado acima pode ser as edições LocalDB, Express ou Developer. O Simple-Talk faz um ótimo trabalho avaliando os prós e os contras de cada um aqui . Há uma razão pela qual a Microsoft criou tantas opções para bancos de dados de desenvolvimento local: LocalDB, Express, Developer .. devemos usá-los!

Se você precisar escolher, é difícil não argumentar que todo desenvolvedor tem uma versão local do SQL Server Developer edition instalada. É totalmente gratuito e possui paridade de recursos com a edição Enterprise. Isso permitirá que toda a sua equipe explore e projete dentro de toda a pilha do Microsoft BI (SQL Server, SSIS, SSRS e SSAS) de maneira segura.

Ainda podemos manter o banco de dados comum, mas não deve ser para desenvolvimento, deve ser para teste. É um servidor em que as configurações no nível do sistema estão sincronizadas com a produção. Hardware, SO, patches, etc.

Para mim, todos esses argumentos são particularmente inválidos

Está bem. Mas eles não são para o resto de nós. Por quê?

Consistência no nível do patch entre servidores de desenvolvimento e produção

a correção seria comprovada quando um aplicativo progredisse no Teste

A correção pode corrigir problemas de estabilidade e corrupção de dados que, de outra forma, afetariam os desenvolvedores. Isso deve ser feito em máquinas de desenvolvimento independentemente.

Segurança de dados; somente dados nos servidores de desenvolvimento são usados ​​para desenvolvimento

É útil separar "o que deveria ser" do "o que é". Os desenvolvedores acabam tendo dados confidenciais (não necessariamente PII, mas também não livres) em seus bancos de dados. Acontece.

Recuperabilidade; os dados são recuperáveis ​​e ainda fazem backup

Super importante.

Diferenças de agrupamento que podem causar problemas quando movidas para a produção

Somente o SharePoint e o SCCM têm problemas com isso

Qualquer coisa que use uma tabela temporária terá esse problema. É extremamente comum. Você nunca percebe isso porque a maioria das pessoas faz um agrupamento padrão em primeiro lugar.

assumindo que é APENAS para desenvolvimento, e o banco de dados não será "movido" para produção

Por que assumiríamos isso? As coisas costumam ir do desenvolvimento à produção. De que outra forma você obtém a produção preenchida pela primeira vez? Scripts puros? Não necessariamente quando o aplicativo está em pré-produção há algum tempo.

Eu acho que uma das maiores preocupações seria a capacidade de instâncias de banco de dados locais desatualizadas, mas isso é um problema de gerenciamento de software, não um IMO do DBA.

Você simplesmente precisa emitir uma declaração sobre o que faz e não apoia e por quê.

O LocalDB é uma parte essencial do SSDT agora e inevitável. No entanto, não é acessível remotamente e não possui um componente de agendamento (o Express tem problemas semelhantes). Portanto, geralmente não é suportado pelos DBAs em relação a backups, manutenção e verificações de integridade.

Mas a consolidação para servidores de desenvolvimento centralizados ainda faz sentido. E agora que a Developer Edition é gratuita, é ainda mais fácil justificar ter mais deles.

Conceitualmente falando, você está no caminho certo. Para uma organização que possui um processo de desenvolvimento maduro / Ciclo de Vida de Desenvolvimento de Software (SDLC) que inclui controle de código-fonte, integração contínua (CI), teste automatizado e um grupo de TI que sabe gerenciar vários ambientes e estações de trabalho para mantê-los sincronizados em relação a níveis de software e patches e desenvolvedores disciplinados que a) seguem o processo, b) trabalham juntos ec) trabalham com TI, depois de ter 50 (ou muitos) DBs de desenvolvimento podem funcionar:

• Sim, níveis consistentes de software e patch podem ser mantidos em qualquer número de estações de trabalho.
• Sim, quaisquer "problemas" podem surgir em ambientes de teste automatizado e / ou QA / UAT.
• Muitos DBs de desenvolvimento não são tão fáceis de fazer backup, mas também não são impossíveis. Se você estiver usando perfis móveis, os arquivos de dados que estão na pasta "Configurações locais" de cada usuário do Windows poderão ser mais fáceis de fazer backup. Ou, no mínimo, pode ser script da TI para pegar arquivos de todas as estações de trabalho de desenvolvimento, semelhante à maneira como eles garantiriam que todos fossem corrigidos corretamente.

MAS, como em quase tudo, tudo se resume ao contexto da situação.

Um benefício de ter DBs de desenvolvimento separados é que vários projetos podem ser trabalhados simultaneamente sem impactar um ao outro. (Obviamente, esse pode ser o único benefício.)

No entanto, existem várias questões a considerar:

• Qual é o tamanho da equipe e quantas pessoas estão trabalhando em um projeto em particular? Quanto mais pessoas você estiver trabalhando em um projeto, mais precisará de um servidor de desenvolvimento compartilhado / centralizado para que todos recebam todas as alterações.

• Em termos de agrupamento, o SQL Server Express LocalDB possui uma nuance / restrição / limitação particularmente irritante:

  O agrupamento da instância para o LocalDB está definido como SQL_Latin1_General_CP1_CI_AS e não pode ser alterado. Agrupamentos no nível do banco de dados, no nível da coluna e no nível da expressão são suportados normalmente. Os bancos de dados contidos seguem as regras de agrupamentos de metadados e tempdb definidos por Contains Database Collations .

  O tempdbagrupamento no nível da instância afeta não apenas (isto é, resolução de nome de objeto no escopo db e agrupamento padrão para tabelas temporárias, mas não variáveis ​​de tabela), mas também nomes de variáveis ​​locais nomes de cursor / nomes de parâmetros e gotonomes de rótulos. Portanto, se os servidores de produção tiverem um agrupamento no nível da instância de algo diferente SQL_Latin1_General_CP1_CI_AS, o LocalDB não será uma boa escolha.

• Você está usando os recursos do Enterprise Edition? Se é apenas uma questão de reconstruir o índice ONLINE, provavelmente isso não importa. Mas se você estiver usando algo como o Particionamento de Tabela, o LocalDB não será uma boa escolha.

• Talvez o maior problema seja o escopo geral aumentado de possíveis problemas decorrentes de disparidades ambientais (nível de SO, nível de patch de software, configuração de instância, configuração de banco de dados, etc.) que possam levar a um bug. Embora já tenhamos aceito (em um sentido geral) que o teste automatizado / QA / UAT encontraria esses problemas, isso não é garantido ! Dado que os humanos cometem erros e que os humanos precisam apresentar todos os testes que verificariam todos os caminhos de código e todas as variações de dados (tipos, tamanho, etc.), é altamente provável que qualquer número de cenários não ocorra.ser testado e que um bug possa passar e não ser percebido até que um cliente o encontre na Produção. Isso acontece de qualquer maneira, mas as chances aumentam ao usar o LocalDB para que cada desenvolvedor possa ter seu próprio banco de dados privado.

O que realmente se resume é: qual é o motivo convincente para usá-lo em um ambiente de equipe? Em vários trabalhos, sempre trabalhei em grupos onde havia desenvolvedores de aplicativos e engenheiros de banco de dados e, embora os desenvolvedores de aplicativos às vezes zombassem de um procedimento armazenado apenas para executá-lo mais rapidamente (poucos DBEs), os DBEs faziam a maioria das Programação de banco de dados, incluindo verificação (ou seja, correção) de qualquer código que o App Devs escreveu. Usar o LocalDB tornaria muito mais difícil trabalhar em grupo. E, ao usar o SQL Server Express (ou mesmo a Developer Edition) para ter instâncias pessoais em cada estação de trabalho que estava acessível remotamente - facilitando a colaboração - nunca havia realmente a necessidade de ter esse nível de isolamento, pois era raro alterações no banco de dados de um projeto afetam negativamente o outro.

Obviamente, aqueles de nós que eram Engenheiros de Banco de Dados (DBEs) tinham instalações locais do Express Edition e / ou Developer Edition. Porém, isso era para fazer testes que exigiam mais controle sobre a configuração / segurança no nível da instância, etc., do que o permitido em um servidor compartilhado. E usei a (s) instância (s) local (is) ocasionalmente, mas não muito frequentemente. Mas, para meus projetos pessoais, eu amo o LocalDB e o uso com bastante frequência.