Muito parecido com a pergunta que foi postada aqui anteriormente sobre " Os desenvolvedores devem ser capazes de consultar bancos de dados de produção? " Eu queria saber 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, em vez disso, promovem o uso de SQL Servers de desenvolvimento centralizado.
Especificamente, isso é feito para garantir:
- Consistência de nível de patch entre servidores de desenvolvimento e produção
- Capacidade de provar e validar quaisquer patches acima
- Segurança de dados; apenas os dados nos servidores de desenvolvimento são usados para desenvolvimento
- Recuperabilidade; os dados são recuperáveis e ainda têm backup
- Diferenças de agrupamento que podem causar problemas quando movidas para produção
Para mim, todos esses argumentos são particularmente inválidos, talvez com exceção dos remendos; mas se um banco de dados em uma máquina local for usado exclusivamente para atividades de desenvolvimento, e não para teste, o patch será comprovado quando um aplicativo progredir de Teste / UAT, etc., para Produção.
O agrupamento não parece ser um motivo válido, pois se isso fosse uma preocupação para o banco de dados, ele deveria ser definido ao ser criado de qualquer maneira. Até onde eu sei, apenas o SharePoint e o SCCM têm problemas com isso;)
Agora, assumindo que é APENAS para desenvolvimento, e o banco de dados não será "movido" para produção e as únicas movimentações 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?
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 DBA um IMO.
OK. Mas eles não são para o resto de nós. Por quê?
O patching pode corrigir problemas de estabilidade e corrupção de dados que, de outra forma, afetariam os desenvolvedores. Deve ser feito em máquinas de desenvolvimento independentemente.
É útil separar "o que deveria ser" de "o que é". Os desenvolvedores acabam com dados confidenciais (não necessariamente PII, mas também não gratuitos) em seus bancos de dados. Acontece.
Super importante.
Qualquer coisa que use uma tabela temporária terá esse problema. É extremamente comum. Você nunca percebe isso porque a maioria das pessoas prefere um agrupamento padrão em primeiro lugar.
Por que assumiríamos isso? As coisas geralmente vão do desenvolvimento à produção. De que outra forma você obtém a produção preenchida pela primeira vez? roteiros puros? Não necessariamente quando o aplicativo está em pré-produção há algum tempo.
Você simplesmente precisa emitir uma declaração sobre o que você faz e não apóia e por quê.
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 por DBAs em relação a backups, manutenção e verificações de integridade.
Mas a consolidação em 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 / ciclo de vida de desenvolvimento de software (SDLC) maduro que inclui controle de código-fonte, integração contínua (CI), testes automatizados e um grupo de TI que sabe como gerenciar vários ambientes e estações de trabalho para mantê-los sincronizados em relação aos níveis de software e patch, e desenvolvedores disciplinados que a) seguem o processo, b) trabalham juntos e c) trabalham com TI, então ter 50 (ou quantos) bancos de dados de desenvolvimento pode funcionar:
MAS, como quase tudo, tudo se resume ao contexto da situação.
Um benefício de ter bancos de dados de desenvolvimento separados é que vários projetos podem ser trabalhados simultaneamente sem afetar uns aos outros. (Claro, esse pode ser o único benefício.)
NO ENTANTO, há várias questões a considerar:
Qual é o tamanho da equipe e quantas pessoas estão trabalhando em um determinado projeto? Quanto mais pessoas você tiver trabalhando em um projeto, mais você 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 tem uma nuance/restrição/limitação particularmente irritante:
O agrupamento em nível de instância afeta não apenas
tempdb(ou seja, resolução de nome de objeto com escopo definido no banco de dados 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 cursores/nomes de parâmetros egotonomes de rótulos. Portanto, se seus servidores de produção tiverem um Collation em nível de instância diferente deSQL_Latin1_General_CP1_CI_AS, o LocalDB não será uma boa escolha.Você está usando os recursos da Enterprise Edition? Se for apenas uma questão de fazer reconstruções de índice ONLINE, isso provavelmente não importa. Mas se você estiver usando algo como Table Partitioning, o LocalDB não é uma boa escolha.
Talvez o maior problema seja o aumento geral do escopo de possíveis problemas decorrentes de quaisquer disparidades ambientais (nível de sistema operacional, nível de patch de software, configuração de instância, configuração de banco de dados etc.) que podem levar a um bug. Embora já tenhamos aceitado (em um sentido geral) que testes automatizados/QA/UAT encontrariam esses problemas, isso não é garantido ! Dado que os humanos cometem erros e que precisam criar todos os testes que verifiquem 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ãoser testado e que um bug pode passar e não ser notado 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 importa é: 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 simulassem um procedimento armazenado apenas para fazê-lo mais rapidamente (não havia o suficiente de nós, DBEs), os DBEs faziam a maior parte do Programação de banco de dados, incluindo verificação (ou seja, correção) de qualquer código que os desenvolvedores de aplicativos tenham escrito. O uso do LocalDB tornaria muito mais difícil trabalhar em grupo. E ao usar o SQL Server Express (ou mesmo o Developer Edition) para ter instâncias pessoais em cada estação de trabalho de desenvolvimento acessível remotamente - facilitando a colaboração - nunca houve necessidade de ter esse nível de isolamento, pois era raro as alterações no banco de dados de um projeto impactam negativamente outro.
Claro, aqueles de nós que eram engenheiros de banco de dados (DBEs) tinham instalações locais da Express Edition e/ou Developer Edition. Mas isso era para fazer testes que exigiam mais controle sobre a configuração/segurança no nível da instância, etc., do que poderia ser permitido em um servidor compartilhado. E usei as instâncias locais ocasionalmente, mas não com muita frequência. Mas para meus projetos pessoais, adoro o LocalDB e o uso com bastante frequência.
Sim. Todos os desenvolvedores devem ter uma instância local do SQL Server E uma instância compartilhada do SQL Server. Eles existem para propósitos diferentes. Ambos são necessários.
Talvez seu ambiente atual seja assim?
Acima, vários desenvolvedores estão criando alterações e implantando-as em um banco de dados SQL Developer comum. Isto é mau. Microsoft MVP Troy Hunt documenta alguns dos pontos problemáticos dessa abordagem antiquada, aqui . Os primários são...
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 seguro e isolado para fazer seu trabalho. Existem 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 origem adequado . Outra é que eles simplesmente herdaram esse padrão de design e não podem se incomodar em alterá-lo. A Microsoft tem se distanciado constantemente desse padrão e em direção a 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 então sincronizadas em um sistema de controle de origem apropriado. Aqui, cada desenvolvedor pode projetar e experimentar em um ambiente onde suas alterações não afetarão ninguém até o check-in. E nessa hora os conflitos serão resolvidos.
O banco de dados local usado acima pode ser as edições LocalDB, Express ou Developer. Simple-Talk faz um ótimo trabalho pesando os prós e 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... deveríamos 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 tem paridade de recursos com a edição Enterprise. Ele permitirá que toda a sua equipe explore e projete toda a pilha de BI da Microsoft (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 onde as configurações de nível de sistema estão sincronizadas com a produção. Hardware, SO, patches, etc.