Procedimentos armazenados sob controle de origem, práticas recomendadas

Atualmente, estou usando o Tortoise SVN para controlar o aplicativo da Web .NET. Qual seria a melhor maneira de trazer nossos procedimentos armazenados do SQL Server para o Controle de Origem? Atualmente, estou usando o VS 2010 como meu ambiente de desenvolvimento e me conectando a um banco de dados externo do SQL Server 2008 R2 usando o SQL Server Data Tools (SSDT).

O que tenho feito no passado é salvar os procs em um arquivo .sql e manter esses arquivos sob controle de origem. Tenho certeza de que deve haver uma maneira mais eficiente do que isso? Existe uma extensão que eu possa instalar no VS2010, SSDT ou mesmo SQL Server na máquina de produção?

Existem ferramentas por aí, como essa da Redgate , mas sempre achei que o melhor é salvar como arquivos SQL, talvez até em um projeto de banco de dados (SSDT?) Em sua solução.

Junto com isso, sugiro as seguintes diretrizes:

• Sempre assuma a versão SVN como a "atual" / "mais recente"
• Certifique-se de que todos os scripts executados tenham um " if exists then drop" apropriado no início
• Lembre-se de escrever suas permissões, se houver

Inicialmente, você pode criar esses arquivos SQL criando scripts diretamente no SSMS e pode definir o SSMS para script todos os seus " drop" e " create", bem como suas permissões.

Salvar os arquivos SQL no controle de origem fornece controle apenas sobre os arquivos SQL. Ele não controla as alterações dos objetos de banco de dados reais, nem impede alterações simultâneas do mesmo objeto de banco de dados por vários usuários (e acho que você gostaria de ter isso sob controle também). O que usamos é uma ferramenta de terceiros ( versão ApexSQL), ele se integra ao SSMS e ao VS. Você pode optar por trabalhar com uma versão do banco de dados do objeto ou com uma versão do Source Control. Se você estiver editando uma versão do banco de dados, o check-out automático é feito somente para você, para que ninguém mais possa editá-la (não mescla alterações de usuários diferentes). Somente quando você faz o check-in novamente, outras pessoas podem modificá-lo. E você pode ter sua versão do SC diferente da versão de um objeto ativo (eu a uso quando saio para o dia e planejo terminar as edições e testá-la na próxima)

Use o RedGate Source Control para conectá-lo ao seu controle de fonte.

http://www.red-gate.com/products/sql-development/sql-source-control/

Ele conectará seu SSMS diretamente ao seu repositório de controle de origem e até permitirá a verificação de dados estáticos.

Funciona como um encanto

Tente Ankhsvn , altamente recomendado e gratuito.

Na página inicial:

AnkhSVN é um Provedor de Controle de Origem do Subversion para Microsoft Visual Studio 2005, 2008, 2010 e 2012 .

O AnkhSVN fornece suporte ao gerenciamento de código-fonte do Apache ™ Subversion® para todos os tipos de projetos suportados pelo Visual Studio e permite executar as operações de controle de versão mais comuns diretamente de dentro do IDE do Microsoft Visual Studio.

O painel Pending Changes fornece uma visão única do seu processo de desenvolvimento e fornece acesso fácil ao código-fonte e aos recursos de gerenciamento de problemas. A integração do controle de código-fonte profundo (SCC) permite que você se concentre no desenvolvimento, enquanto o AnkhSVN monitora todas as suas alterações e fornece as ferramentas para lidar efetivamente com suas necessidades específicas.

Eu tentei o projeto de banco de dados do RedGate e do Visual Studio e prefiro armazenar a definição de banco de dados no projeto de banco de dados. Assim que o banco de dados se tornar parte da solução, você poderá usar seu provedor de controle de origem preferido. A maioria possui excelente integração com o Visual Studio.

Com as ferramentas SSDT, você tem a 'versão mais recente' da definição do banco de dados, permitindo fazer facilmente comparações de esquemas e gerar scripts de atualização de esquema.

Dito isto, o esquema é geralmente apenas uma parte da equasão. Na vida real, verifica-se que os bancos de dados já possuem muitos dados. E meus usuários tendem a ficar bastante decepcionados quando perdem.

Então, assim que eu disponibilizei a v1.0, surge a necessidade de manter os scripts de atualização. Às vezes, elas contêm apenas alterações de esquema, mas muitas vezes eu preciso criar padrões com base no conteúdo de alguma outra tabela, preciso liberar uma restrição específica até que eu propague os dados, etc. Geralmente, a atualização do esquema simplesmente não é suficiente. Minha preferência é ter esses scripts de atualização em uma pasta separada também no projeto do banco de dados. Eles geralmente se pareceriam com 'atualização da v1.0 para v1.1'.

Meus bancos de dados sempre têm uma tabela de referência que informa o número da versão atual, para que eu possa bloquear atualizações incompatíveis. A primeira declaração nos meus scripts de atualização verifica a versão atual e sai se é diferente do esperado.

Outro benefício dos projetos de banco de dados é poder implantar diferentes conjuntos de dados com base no mesmo esquema. Tenho conjuntos de dados diferentes para desenvolvimento, equipe de controle de qualidade, teste de aceitação do usuário e testes de integração automatizados. Como um projeto de banco de dados pode ter apenas 1 script pós-implantação, o truque aqui é criar um novo projeto de banco de dados que faça referência ao projeto 'mestre' e tornar o conjunto de dados personalizado parte dos processos de pós-implantação desse projeto.

Esses foram meus 2 centavos. Qualquer que seja o processo que você venha, acima de tudo, deve caber a você e à sua equipe e, com sorte, apoiar você na maioria das tarefas comuns.

Acabei escrevendo uma ferramenta.

Está disponível para download gratuito - http://www.gitsql.net

Espero que ajude outras pessoas que desejam alcançar o mesmo objetivo final.

Aqui está um artigo que descreve como controlar o SQL Server de origem. http://gitsql.net/documentation-04_SQL_Server_and_GIT

Eu tentei facilitar o máximo possível. (3 telas)

• Conecte-se ao SQL Server
• Selecionar objetos
• Escolheu a pasta para exportar para / importar de

Eu também - acidentalmente - adicionei o recurso de poder escolher seletivamente objetos individuais para importar - ou exportar. O que facilita muito o desenvolvimento.

Eu normalmente faria uma alteração em um procedimento armazenado e em uma tabela e depois exportaria esses dois objetos para um diretório GIT.

Então eu uso o Source Tree para ver visualmente as alterações e depois as comprometo no bitbucket, se estiver feliz.

Minha empresa acabou de desenvolver essa nova ferramenta ( gratuita ) que ajuda a extrair facilmente scripts para bancos de dados SQL, pode fazer comparação , pode iniciar o WinMerge para comparar rapidamente scripts com banco de dados ativo e também pode sincronizar diferenças, tanto atualizando os scripts quanto aplicando as alterações ao banco de dados (exceto tabelas, o que envolveria mais complexidade e mais riscos).

Servantt é o WinMerge para comparar bancos de dados do SQL Server com scripts controlados por versão.

Ele suporta e incentiva as melhores práticas no desenvolvimento de software:

• Mantendo objetos de banco de dados sob controle de versão (*)
• Removendo direitos de acesso de desenvolvedores em ambientes de produção
• Revisão pelo DBA de alterações nos procedimentos / visualizações para gargalos de desempenho e padrões de nomenclatura
• Nomeando objetos usando identificadores totalmente qualificados e delimitadores entre colchetes (ele corrige os scripts CREATE PROCEDURE / VIEW / FUNCTION / etc)

(*) Os scripts são salvos em uma pasta local que pode ser uma cópia de trabalho do Git, Subversion, TFS, Source Safe ou qualquer outro VCS.

Download grátis: http://servantt.com

A versão profissional (ainda em desenvolvimento) será uma fera completamente diferente - é direcionada à automação de implantação (gerenciamento de versões), para automatizar tarefas como atualizar o IIS, atualizar os Serviços do Windows etc.