Este artigo é um passo a passo de como usar a opção de pasta de trabalho do controle de origem para gerenciar bancos de dados do SQL Server.
Neste artigo, também estou destacando alguns dos benefícios e limitações de usar uma pasta de trabalho em comparação com outras opções disponíveis para uso com controle de origem.
Vamos discutir alguns conceitos-chave antes de nos aprofundarmos nos detalhes técnicos deste artigo.
Conceitos-chave
O que é controle de origem
O controle de origem é um sistema ou (parte das melhores práticas de software) que acompanha todas as alterações no código feitas pelos desenvolvedores.
Por que o controle de origem é necessário
O código do aplicativo escrito pelos desenvolvedores precisa ser salvo de tempos em tempos de forma que todas as alterações feitas por qualquer desenvolvedor possam ser não apenas rastreadas, mas também revertidas, se necessário.
Por esse motivo, o código do aplicativo é colocado sob controle do código-fonte para garantir que o histórico de todas as alterações junto com os comentários seja bem mantido, além de muitos outros benefícios de usar o controle do código-fonte, que estão além do escopo deste artigo.
Controle de origem versus controle de versão
Não há diferença entre Controle de Origem e Controle de Versão e, principalmente, esses dois termos são usados livremente de forma intercambiável.
Colocamos os bancos de dados sob controle de origem
Assim como o código do aplicativo, os objetos do banco de dados, como tabelas, exibições, procedimentos armazenados, etc., também precisam ser controlados por versão. No entanto, o método de colocar objetos de banco de dados sob controle de origem é ligeiramente e, em alguns casos, totalmente diferente de quando o código do aplicativo é colocado sob controle de origem.
Exemplo de banco de dados de controle de versão
Suponha que você crie um banco de dados de amostra chamado "Carros" conforme o requisito de negócios.
Em seguida, você cria uma tabela chamada "Carro" com o CarId e CarName colunas para atender a outro requisito.
Na sua ausência, outro desenvolvedor recebe uma tarefa para adicionar o CarType coluna para a tabela "Carro".
Ele decide remover o CarName coluna pensando que não é necessário e substitua-o pelo CarType coluna.
Você volta depois de muito tempo e fica surpreso ao ver que seu CarName coluna não está apenas ausente, mas também é substituída pelo CarType coluna.
Agora, você não se lembra do tipo e do comprimento dos dados originais que escolheu para CarName a menos que você passe por todo o conjunto de requisitos de negócios.
Espere um minuto! Esse problema pode ser facilmente resolvido se você tiver considerado o uso do controle de origem para seu banco de dados em primeiro lugar. Então você pode ver facilmente a primeira alteração feita, que contém a definição da coluna e a segunda alteração feita por outro desenvolvedor.
Assim, você e o outro desenvolvedor se sentam juntos e percorrem as alterações históricas feitas no banco de dados (objeto) usando o controle de origem, que acompanha cada alteração feita por qualquer desenvolvedor no banco de dados.
Isso é ilustrado a seguir:
Uso mais importante do controle de origem
Um dos principais motivos para usar o controle do código-fonte é poder manter várias versões do código ao mesmo tempo, criando as seguintes ramificações do código:
- Dev (ramificação de desenvolvimento)
- Teste (ramificação de teste)
- QA (ramo de controle de qualidade)
- Prod (ramo de produção)
Os detalhes técnicos da criação de ramificações de desenvolvimento, teste, controle de qualidade e produção do controle do código-fonte estão além do escopo deste artigo.
Pré-requisitos
Este artigo é mais adequado para os leitores que atendem aos seguintes requisitos:
Conhecimento básico de T-SQL
Você deve ter algum conhecimento básico de T-SQL para criar, consultar e modificar objetos de banco de dados, como tabelas, exibições e procedimentos armazenados.
Ferramentas de desenvolvimento de banco de dados
Você deve ter o SSMS (SQL Server Management Studio) ou dbForge Studio for SQL Server instalado em sua máquina para criar e gerenciar bancos de dados e seus objetos.
Disponibilidade da fonte de dados da pasta de trabalho
Embora qualquer controle de origem que ofereça a opção de pasta de trabalho seja bom, é recomendável usar o dbForge Source Control para seguir todas as etapas do passo a passo neste artigo.
Controle de origem da pasta de trabalho
Pasta de trabalho com funcionalidade limitada para objetos de banco de dados de controle de versão pode ser usada como outros sistemas de controle de origem, como TFS, Git etc.
Uma pasta de trabalho simplesmente contém arquivos de script SQL usados para criar e gerenciar objetos de banco de dados.
Quando usar a pasta de trabalho
Suponha que você queira criar um banco de dados e seus objetos relacionados a partir do zero, mas ainda não tem certeza de qual controle de origem sua equipe usará. Então é melhor começar com a opção de controle de origem da pasta de trabalho.
Outro motivo pode ser quando você simplesmente deseja armazenar o estado atual do banco de dados e não está interessado em acompanhar as alterações históricas, então a pasta de trabalho é uma boa candidata a ser usada como controle de origem.
Limitação da pasta de trabalho
A pasta de trabalho para objetos de banco de dados de controle de versão é limitada em termos de manter a versão mais recente do banco de dados e seus objetos e não há como rastrear as alterações ou revertê-las.
Portanto, você deve ter cuidado ao usar a Pasta de Trabalho como sua opção de controle de origem, pois ela não pode mostrar todas as alterações feitas no banco de dados e seus objetos de tempos em tempos.
Passo a passo:Vinculando o banco de dados à pasta de trabalho
Vamos seguir as etapas para vincular seu banco de dados a uma pasta de trabalho usando o controle de origem.
Requisitos para adicionar livro e tipo de livro
Você recebeu os requisitos internos para criar um banco de dados de teste chamado “SQLBookShopV2” que contém as duas tabelas a seguir:
- Livro
- Tipo de livro
O banco de dados não exige necessariamente um controle de origem neste momento e não é importante acompanhar todas as alterações feitas.
Verifique os requisitos
Muitas vezes, é uma boa prática verificar os requisitos antes de usar uma pasta de trabalho. Uma pasta de trabalho é mais adequada se você for solicitado a criar um banco de dados com os seguintes requisitos:
- Banco de dados de teste ou protótipo de banco de dados é necessário
- O histórico de alterações do banco de dados não é obrigatório
- A decisão de qual controle de origem será usado ainda não foi decidida
Configurar pasta de trabalho
A primeira etapa é separar uma pasta onde os scripts do banco de dados de teste residirão depois que você começar a verificar o código do banco de dados na pasta de trabalho.
Crie uma nova pasta chamada “Scripts SQLBookShopV2” na Unidade C.
Configurar banco de dados de exemplo SQLBookShopV2
Abra o dbForge Studio for SQL Server e no menu Database clique em “New Database”:
Digite “SQLBookShopV2” no nome do banco de dados e clique no botão “Aplicar alterações” na parte inferior da janela:
Vincular banco de dados à pasta de trabalho
É melhor obter o banco de dados vinculado ao controle de origem logo após criá-lo.
Clique com o botão direito do mouse no banco de dados (SQLBookShopV2) e selecione o item de menu Source Control à Link Database to Source Control:
Localize a pasta de trabalho criada anteriormente para vinculá-la ao banco de dados:
Você pode escolher o modelo de desenvolvimento de banco de dados desejado. Estamos escolhendo o modelo de desenvolvimento de banco de dados compartilhado:
Verifique o pequeno ícone de controle de origem ao lado do banco de dados que confirma que o banco de dados foi vinculado com sucesso ao controle de origem da pasta de trabalho:
Criar tabela de livros
Clique com o botão direito do mouse em Tabelas e clique em Nova tabela e crie a tabela de livros usando o código a seguir e aplique as alterações:
CREATE TABLE SQLBookShopV2.dbo.Book ( BookId INT IDENTITY ,BookTitle VARCHAR(50) NOT NULL ,Notes VARCHAR(200) ,CONSTRAINT PK_Book_BookId PRIMARY KEY CLUSTERED (BookId) ) GO
Confirmar alterações no código do banco de dados
Como criamos uma nova tabela no banco de dados, essas alterações locais devem ser selecionadas pelo controle de origem para serem salvas.
Abra o Gerenciador de controle de código-fonte (que mostra as últimas alterações a serem salvas) clicando com o botão direito do mouse no banco de dados e, em seguida, clique em Fonte à Mostrar Gerenciador de Controle de Origem
Clique em Confirmar para fazer check-in no controle de origem da pasta de trabalho:
Verificação da pasta de trabalho
Vá para sua pasta de trabalho e veja o objeto de tabela salvo lá como resultado do último commit:
Criar tabela BookType
Crie outra tabela BookType usando o seguinte código:
CREATE TABLE SQLBookShopV2.dbo.BooKType ( BookTypeId INT IDENTITY ,Name VARCHAR(50) NULL ,Detail VARCHAR(200) NULL ,CONSTRAINT PK_BooKType_BookTypeId PRIMARY KEY CLUSTERED (BookTypeId) ) GO
Adicionar tabela ao controle de origem
Adicione a tabela recém-criada ao controle de origem usando o mesmo método mencionado anteriormente e verifique a pasta de trabalho para ver se ambas as tabelas estão lá:
Parabéns! Você vinculou com êxito seu banco de dados ao controle de origem da pasta de trabalho.
Precauções da pasta de trabalho
Lembre-se de que uma pasta de trabalho em sua forma pura como controle de origem é como uma pasta comum do Windows e, se for modificada externamente, não poderá mais lembrar seu estado mais recente.
Por exemplo, se excluirmos o código Book.sql da pasta de trabalho e verificarmos as alterações usando o Gerenciador de controle de origem, teremos que adicionar o código da tabela Book novamente na pasta de trabalho.
A responsabilidade de proteger a pasta de trabalho está nos ombros dos desenvolvedores, e não no código-fonte (em sua forma original), a menos que você siga estritamente a solução alternativa que provou ser bem-sucedida.
Coisas para fazer
Agora você pode facilmente colocar seus objetos de banco de dados usando a opção de controle de origem da pasta de trabalho:
- 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 depois de usar o controle de origem da pasta de trabalho.
- Tente criar um procedimento armazenado chamado AddBook para adicionar um novo livro ao Livro table depois de vincular seu banco de dados com o controle de origem da pasta de trabalho.
- Tente criar uma visualização de banco de dados Livros para ver a lista de todos os livros com seus tipos e verificar todas as alterações no controle de origem da pasta de trabalho.
Leitura adicional:
Rastreando alterações no banco de dados usando o controle de origem da pasta de trabalho
Ferramenta útil:
dbForge Source Control – poderoso suplemento de SSMS para gerenciar alterações no banco de dados SQL Server no controle de origem.
