Temos bancos de dados existentes sob controle de origem em projetos de banco de dados SQL Server com vários desses bancos de dados referenciando uns aos outros.
Colocar isso em projetos e controle de origem foi bastante desafiador, embora eu esteja achando difícil configurar ambientes de desenvolvimento/teste sem usar uma nova instância do servidor SQL.
No momento, temos uma cópia dos bancos de dados em uma instância SQL de teste que está sendo usada como parte da implantação contínua. O que estou procurando fazer é desenvolver em uma ramificação e trabalhar com bancos de dados com um prefixo Dev na mesma instância, embora perceba que eles fariam referência aos bancos de dados usados para implantação contínua.
Isso seria possível usando variáveis de bancos de dados em referências de banco de dados em vez de apenas o nome, em caso afirmativo, como e existe uma maneira de compartilhar variáveis SQLCMD entre projetos? Existem maneiras alternativas de considerar?
Eu tenderia a sugerir o uso de vários arquivos publish.xml conforme descrito aqui Jamie Thompson blog
Os nomes de banco de dados (ou um prefixo) podem ser armazenados como variáveis SQLCMD.
Cada arquivo de publicação seria então compilado e publicado como um artefato de compilação - você precisaria codificar um powershell personalizado ou um trabalho em lote para escolher o arquivo correto com base no nome do servidor. (Você pode usar o nome do servidor como um switch aqui)
Você precisaria configurar o arquivo de publicação para cada ambiente uma vez, mas depois que esse trabalho for concluído, ele não precisará ser feito novamente.
Em uma vida anterior eu gerenciei uma implementação bastante grande com uma tonelada de bancos de dados idênticos, juntamente com alguns bancos de dados de controle, em servidores diferentes em cada ambiente. Tínhamos muitas consultas entre bancos de dados que precisavam funcionar da mesma forma, seja em desenvolvimento, controle de qualidade, teste, pré-produção, produção etc. Minha solução - em vez de ter algum script que atualizasse todas as referências de servidor e banco de dados cruzado - era usar sinônimos.
No Dev, onde tudo estava em um servidor:
No controle de qualidade, onde a tabela de controle estava em outro servidor:
Agora, todo o código em qualquer banco de dados em qualquer ambiente que precisava da tabela de controle simplesmente referenciado
dbo.ControlTable
e mantivemos sinônimos fora de nossas sincronizações/implantações automatizadas (exceto no caso em que um sinônimo realmente mudou).Se movermos essa tabela para um banco de dados diferente, ou tivéssemos um banco de dados com nome diferente, ou movêssemos esse banco de dados para um servidor diferente, não precisávamos tocar em nenhum código - apenas descartamos e recriamos o sinônimo.
No seu caso, os sinônimos em seu projeto dev/banco de dados dev podem ser apenas:
E no seu banco de dados de produção:
Se você quiser fazer com que o nome do sinônimo seja igual ao nome do objeto, você pode colocar os sinônimos em seu próprio esquema:
E novamente no dev db seria apenas:
(Agora apenas mantenha os sinônimos - ou esse esquema - como uma coisa implantável separadamente do projeto para evitar fios cruzados.)
Eu escrevi sobre sinônimos aqui. Eles são um recurso muito útil, mas pouco utilizado: