Atualmente, estou usando o Tortoise SVN para controlar a origem de um 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 SQL Server 2008 R2 externo 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 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 esta do 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 orientações:
if exists then drop" apropriado no inícioVocê pode inicialmente criar esses arquivos SQL por scripts diretamente do SSMS e pode definir o SSMS para criar scripts de todos os seus "
drop" e "create", bem como suas permissões.Salvar os arquivos SQL no controle do código-fonte 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 tanto com SSMS quanto com VS, você pode optar por trabalhar com uma versão de banco de dados do objeto ou com uma versão de Source Control. Se você estiver editando uma versão de banco de dados, o check-out será feito automaticamente apenas para você, para que ninguém mais possa editá-la (não mescla as alterações de usuários diferentes). Somente quando você fizer o check-in novamente, outras pessoas poderão modificá-lo. E você pode ter sua versão SC diferente da versão de um objeto vivo (eu uso isso quando saio de dia e planejo terminar as edições e testar no próximo)
Use o RedGate Source Control para conectá-lo ao seu controle de origem.
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
Experimente o Ankhsvn , altamente recomendado e gratuito.
Da página inicial:
Eu tentei o projeto de banco de dados do RedGate e do Visual Studio e prefiro armazenar a definição do 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 tem excelente integração com o Visual Studio.
Com as ferramentas SSDT, você tem a 'última versão' da definição do banco de dados, permitindo que você faça facilmente comparações de esquema e gere scripts de atualização de esquema.
Dito isso, o esquema geralmente é apenas uma parte da equação. Na vida real, os bancos de dados já têm muitos dados. E meus usuários tendem a ficar bastante desapontados quando o perdem.
Assim que eu lancei a v1.0 surgiu a necessidade de manter os scripts de atualização. Às vezes, eles 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 semeie os dados etc. Normalmente, simplesmente atualizar o esquema não é suficiente. Minha preferência é ter esses scripts de atualização em uma pasta separada no projeto de banco de dados também. Eles geralmente se parecem com 'atualização de v1.0 para v1.1'.
Meus bancos de dados sempre têm uma tabela de referência que me informa o número da versão atual, para que eu possa bloquear atualizações incompatíveis. A primeira instrução em meus scripts de atualização verifica a versão atual e sai se for diferente do esperado.
Outro benefício dos projetos de banco de dados é poder implantar diferentes conjuntos de dados com base no mesmo esquema. Eu tenho conjuntos de dados diferentes para desenvolvimento, equipe de controle de qualidade, teste de aceitação do usuário e para 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 pós-implantação desse projeto.
Estes foram meus 2 centavos, Qualquer que seja o processo que você venha, acima de tudo, ele deve se adequar a você e sua equipe e, com sorte, apoiá-lo na maioria das tarefas comuns.
Acabei escrevendo uma ferramenta eu mesmo.
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 a origem do SQL Server. http://gitsql.net/documentation-04_SQL_Server_and_GIT
Tentei deixar o mais fácil possível. (3 telas)
Eu também - acidentalmente - adicionei o recurso de poder escolher seletivamente objetos individuais para importar - ou exportar. O que torna muito fácil durante o desenvolvimento.
Eu normalmente faria uma alteração em um procedimento armazenado e uma tabela e, em seguida, exportaria esses dois objetos para um diretório GIT.
Então eu uso a Árvore de Origem para ver visualmente as alterações e, em seguida, confirmá-las no bitbucket, se estiver satisfeito.
Minha empresa acabou de desenvolver esta nova ferramenta ( gratuita ) que ajuda você a extrair facilmente scripts para bancos de dados SQL, pode fazer comparações , pode iniciar o WinMerge para comparar rapidamente scripts com banco de dados ao vivo e também pode sincronizar diferenças tanto atualizando os scripts quanto aplicando as alterações ao banco de dados (exceto tabelas, que envolveriam mais complexidade e mais riscos).
Servantt é o WinMerge para comparar bancos de dados SQL Server com scripts controlados por versão.
Apoia e incentiva as melhores práticas no desenvolvimento de software:
(*) 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 (que ainda está em desenvolvimento) será uma fera completamente diferente - é voltada para automação de implantação (gerenciamento de lançamentos), para automatizar tarefas como atualização do IIS, atualização de serviços do Windows etc.