Este artigo fala sobre um novo método para controlar a versão de um banco de dados usando uma pasta de trabalho para que as alterações históricas feitas no banco de dados possam ser rastreadas.
Visão geral
Como este artigo é baseado na nova abordagem para controlar o código-fonte de um banco de dados superando a limitação da pasta de trabalho, é melhor obter um entendimento básico da pasta de trabalho e coisas relacionadas.
Plano de fundo
A pasta de trabalho, quando usada como controle de origem, tem a limitação de não poder manter o histórico das alterações do banco de dados. Mas neste artigo, vamos nos concentrar no método de usar um controle de origem secundário (nos bastidores) com uma pasta de trabalho que pode superar a limitação.
Pré-requisitos
Este artigo pressupõe que os leitores estejam familiarizados com os fundamentos do controle de versão do banco de dados usando a Pasta de Trabalho e o Git, juntamente com uma compreensão do Visual Studio Team Services (VSTS), que agora é chamado de Azure DevOps.
Recomenda-se usar os seguintes conjuntos de ferramentas para executar todas as etapas mencionadas neste artigo:
- dbForge para SQL Server
- Controle de origem do dbForge
- Git para Windows (ou qualquer cliente Git)
- Azure DevOps (anteriormente VSTS)
Este artigo também pressupõe que você se inscreveu no Azure DevOps e já tem uma conta, ou pode se inscrever e criar uma nova conta agora se desejar seguir todas as etapas deste artigo.
Como alternativa, qualquer controle de origem que ofereça a opção Pasta de trabalho pode ser usado com o SSMS (SQL Server Management Studio), desde que você tenha as habilidades necessárias para adotar a abordagem conceitual deste artigo e colocá-la em ação.
Referência
Para desenvolver uma compreensão básica do uso da pasta de trabalho para o banco de dados de controle de origem, consulte meu artigo anterior clicando no link abaixo:
Usando a pasta de trabalho para o banco de dados de controle de origem em etapas simples
Limitação da pasta de trabalho
Devemos primeiro entender a limitação de usar a Pasta de Trabalho para controlar a origem de um banco de dados. Se você leu meu artigo anterior, já conhece a limitação.
Cenário da pasta de trabalho
Se observarmos atentamente as etapas a seguir, podemos entender facilmente como a opção de controle de origem da pasta de trabalho é limitada quando se trata de controle de versão do banco de dados:
- Dev1 cria um novo banco de dados sobre relógios de pulso e o chama de Relógios conforme o requisito.
- Dev1 cria uma nova tabela e a chama de Assista com WatchId e Nome do relógio colunas conforme o requisito.
- Dev1 não foi solicitado a usar nenhum controle de origem específico e o projeto em si está em fase de teste de desenvolvimento, então ele decide usar o controle de origem da pasta de trabalho.
- Dev2 foi solicitado a criar uma nova tabela DigitalWatch com DigitalWatchId coluna para que ele exclua o Assista mesa pensando que com o DigitalWatch tabela o Assista tabela não é mais necessária.
- Não há como reverter as alterações feitas pelo Dev2 e criar o Assista table usando o controle de origem da pasta de trabalho mais uma vez porque a pasta de trabalho acabou de receber a versão mais recente do código do banco de dados.
Isso é ilustrado a seguir:
Usando a pasta de trabalho para rastrear alterações no banco de dados
Existe uma maneira de impor a Pasta de Trabalho para acompanhar as alterações do banco de dados, o que pode nos ajudar a restaurar os objetos de banco de dados perdidos, embora o uso da Pasta de Trabalho por padrão não mantenha o histórico das alterações do banco de dados.
Uso do controle de origem secundário (Git)
Isso pode ser alcançado usando um controle de origem secundário lado a lado com o uso da opção Pasta de trabalho, que é um pouco complicada de gerenciar, mas funciona bem.
Vamos usar o Git como o controle de origem secundário com a pasta de trabalho neste artigo.
Git é um sistema de controle de versão distribuído e também um dos controles de origem mais usados atualmente.
Por que Git com pasta de trabalho?
Alguém poderia argumentar por que precisamos usar o Git lado a lado com a Pasta de Trabalho quando podemos usar o Git diretamente com o dbForge Studio for SQL Server para controlar a versão do nosso banco de dados.
A resposta é entender a natureza flexível da opção de controle de origem da pasta de trabalho, além de explorar o potencial adicional de continuar com a pasta de trabalho em vez de apenas usá-la como uma solução temporária.
Baixe qualquer cliente de controle de origem Git ou Git para Windows
Antes de prosseguirmos, instale qualquer cliente Git Source Control de sua escolha que nos ajudará a salvar as alterações do banco de dados com o tempo.
Este passo a passo do artigo está usando o cliente Git para Windows.
Instale o Git for Windows com as opções de sua preferência, usamos as opções padrão para instalar o Git for Windows.
Criar projeto Azure DevOps usando Git
Entre na sua conta do Azure DevOps e crie um novo projeto SQLBookShopV3-Using-Working-Folder-with-Git e escolha o Git Opção de controle de origem para criar um repositório privado da seguinte maneira.
Vá para Repositórios na barra de navegação esquerda e copie o link Repo (repositório Git) clicando no ícone da área de transferência ao lado do link.
O plano é criar um repositório local com base no link do Git Repo e, em seguida, capacitar a pasta de trabalho por meio dele.
Criar pasta de trabalho no Git Local Repos
Se você já tiver a pasta Git Local Repos, crie sua pasta de trabalho SQLBookShopV3-Working-Folder-with-Git lá:
C:\Users\
Como alternativa, crie os Repos pasta em qualquer lugar de sua escolha e, em seguida, crie a subpasta SQLBookShopV3-Working-Folder-with-Git.
Criar novo repositório local Git
Agora vamos criar um repositório Git local para que a pasta de trabalho possa caber nele.
Abra a GUI do Git que deve estar presente após o Git for Windows instalação.
Crie o repositório local escolhendo a opção Criar novo repositório opção.
Crie um repositório local do Git (repositório).
O repositório Git local foi criado com sucesso.
Vincular repositório Git remoto com repositório local
Não basta criar o Git Local Repository, nós o vinculamos ao nosso Git Remote Repository criado por meio do Azure DevOps.
Vincule o Remote Git Repo ao Git Local Repo selecionando o Remote opção no menu principal e clicando em Adicionar novo controle remoto e, em seguida, digite o local do projeto Azure DevOps.
Criar banco de dados SQLBookShopV3
Abra o dbForge Studio para SQL Server e crie um novo banco de dados SQLBookShopV3 .
Criar tabela de livros
Crie o Livro tabela com as colunas BookId, Title e Author da seguinte forma.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ,Title VARCHAR(100) ,Author VARCHAR(50) ) GO
Vincular banco de dados com o controle de origem da pasta de trabalho
Na próxima etapa, vamos vincular o banco de dados ao Controle de Origem da Pasta de Trabalho.
Clique com o botão direito do mouse no banco de dados (SQLBookShopV3) e selecione Controle de origem e, em seguida, Vincular banco de dados ao controle de origem .
Em seguida, localize a pasta de trabalho criada anteriormente para vinculá-la ao banco de dados.
Confirmar alterações na pasta de trabalho
Vá para Gerenciador de controle de origem e marque (Confirmar ) o Livro recém-criado table no controle de origem da pasta de trabalho.
Verifique a pasta de trabalho para ver o Livro mesa lá.
Enviar alterações ao controle de origem do Git (tabela de livros)
Abra a GUI do Git novamente e clique em Verificar novamente botão que deve mostrar o objeto da tabela agora, adicione os seguintes commits iniciais:
Commit inicial (a tabela Book criada pela primeira vez)
Então faça os seguintes passos:
- Alterações de estágio
- Enviar alterações
- Pressione (Alterações)
Como alternativa, você pode usar o Git Bash para executar o Git a partir da linha de comando.
Visualizar alterações confirmadas no Git Source Control
Navegue até Azure DevOps página da Web, desde que você já esteja assinado e o projeto SQLBookShopV3-Using-Working-Folder-with-Git está ativo.
Clique em Repositórios na barra de navegação esquerda para visualizar as alterações que acabaram de ser confirmadas no Git Source Control.
Em seguida, verifique o script da tabela.
Adicionar Colunas de Estoque e Preço
Agora adicione mais duas colunas Estoque e Preço para o Livro tabela usando o script a seguir.
CREATE TABLE SQLBookShopV3.dbo.Book ( BookId INT IDENTITY ,Title VARCHAR(100) NULL ,Author VARCHAR(50) NULL ,Price DECIMAL(8, 2) NULL ,Stock SMALLINT NULL ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ) ON [PRIMARY] GO
A tabela deve ficar como abaixo.
Confirmar alterações na pasta de trabalho
Salve a definição mais recente da tabela Book que agora contém duas colunas extras no Working Folder Source Control conforme mostrado abaixo.
Localize a pasta de trabalho usando o Windows Explorer e abra o dbo.table.sql no bloco de notas para ver o código.
A Pasta de Trabalho contém a definição mais recente da tabela e não fornece nenhuma informação sobre a primeira forma da tabela.
Conforme discutido, esta é a limitação da Pasta de Trabalho que só podemos ver a versão mais recente do banco de dados que é substituída por versões mais recentes, não deixando espaço para rastrear o histórico (alteração do banco de dados).
Enviar alterações para o Git Source Control (colunas de estoque e preço)
Na próxima etapa, enviaremos as colunas recém-adicionadas da tabela para o Git Remote Repository, conforme mostrado abaixo.
Rastrear alterações no banco de dados com o Git Source Control
Até agora, fizemos duas alterações principais no banco de dados na seguinte ordem:
- O Livro A tabela foi criada com as colunas BookId, Title e Author
- As colunas Preço e Estoque foram adicionadas ao Livro tabela
Não há como ver a primeira alteração quando uma tabela de livro foi criada originalmente usando a pasta de trabalho.
No entanto, é possível ver todo o histórico de alterações do banco de dados usando o Git, desde que tenhamos enviado essas alterações para o Git Remote Repository.
No Azure DevOps, clique em Pushes na barra de navegação esquerda para ver as alterações históricas do banco de dados.
Navegue até Commits para visualizar a ordem das alterações do banco de dados na forma de commits.
Clique no primeiro commit a99df4b5 para ver a primeira definição do Livro tabela.
Volte e clique no próximo commit 6f863f0a para ver a(s) próxima(s) alteração(ões) do banco de dados.
Parabéns! Rastreamos com sucesso as alterações do banco de dados usando a pasta de trabalho com um controle de origem secundário (Git).
Agora podemos reverter para a primeira versão da tabela, se desejado, ou continuar adicionando mais objetos de banco de dados.
Coisas para fazer
Agora você pode confortavelmente não apenas colocar seus objetos de banco de dados sob o controle de origem da pasta de trabalho, mas também acompanhar todas as alterações do banco de dados, mantendo o histórico do banco de dados.
- Tente criar outro banco de dados vinculando o Livro tabela com o BookType tabela de forma que o BookTypeId chave primária do BookType tabela é passada como o BookTypeId coluna de chave estrangeira no Livro table e use o controle de origem da pasta de trabalho para rastrear as alterações do banco de dados.
- Tente criar os Relógios banco de dados como visto no primeiro diagrama do artigo e siga os passos mantendo o histórico de alterações do banco de dados usando Pasta de Trabalho com Git
- Tente reverter as alterações mencionadas no primeiro diagrama do artigo quando o Dev2 excluir acidentalmente o Assista tabela criada pelo Dev1 usando a pasta de trabalho para rastrear as alterações do banco de dados.
Ferramenta útil:
dbForge Source Control – poderoso suplemento de SSMS para gerenciar alterações no banco de dados do SQL Server no controle de origem.
