Implantação das associações de função de banco de dados em ambientes de teste

Artigo
07/13/2023

Este tópico descreve como adicionar contas de usuário a funções de banco de dados como parte de uma implantação de solução em um ambiente de teste.

Quando você implanta uma solução que contém um projeto de banco de dados em um ambiente de preparo ou produção, normalmente não deseja que o desenvolvedor automatize a adição de contas de usuário a funções de banco de dados. Na maioria dos casos, o desenvolvedor não saberá quais contas de usuário precisam ser adicionadas a quais funções de banco de dados e esses requisitos poderão ser alterados a qualquer momento. No entanto, quando você implanta uma solução que contém um projeto de banco de dados em um ambiente de desenvolvimento ou teste, a situação geralmente é bastante diferente:

O desenvolvedor normalmente implanta novamente a solução regularmente, muitas vezes várias vezes por dia.

O banco de dados normalmente é recriado em cada implantação, o que significa que os usuários do banco de dados devem ser criados e adicionados às funções após cada implantação.

O desenvolvedor normalmente tem controle total sobre o ambiente de desenvolvimento ou teste de destino.

Nesse cenário, geralmente é benéfico criar usuários de banco de dados automaticamente e atribuir associações de função de banco de dados como parte do processo de implantação.

O fator chave é que essa operação precisa ser condicional com base no ambiente de destino. Se você estiver implantando em um ambiente de preparo ou de produção, você deseja ignorar a operação. Se você estiver implantando em um ambiente de desenvolvimento ou teste, deseja implantar associações de função sem intervenção adicional. Este tópico descreve uma abordagem que você pode usar para enfrentar esse desafio.

Este tópico faz parte de uma série de tutoriais baseados nos requisitos de implantação empresarial de uma empresa fictícia chamada Fabrikam, Inc. Esta série de tutoriais usa uma solução de exemplo, a solução do Contact Manager, para representar um aplicativo Web com um nível realista de complexidade, incluindo um aplicativo ASP.NET MVC 3, um serviço WCF (Windows Communication Foundation) e um projeto de banco de dados.

O método de implantação no centro desses tutoriais baseia-se na abordagem de arquivo de projeto dividido descrita em Noções básicas sobre o arquivo de projeto, na qual o processo de build é controlado por dois arquivos de projeto, um contendo instruções de build que se aplicam a cada ambiente de destino e outro que contém configurações de build e implantação específicas do ambiente. No momento da compilação, o arquivo de projeto específico do ambiente é mesclado no arquivo de projeto independente do ambiente para formar um conjunto completo de instruções de build.

Visão geral da tarefa

Este tópico pressupõe que:

Você usa a abordagem de arquivo de projeto dividido para a implantação da solução, conforme descrito em Noções básicas sobre o arquivo de projeto.
Você chama o VSDBCMD do arquivo de projeto para implantar seu projeto de banco de dados, conforme descrito em Noções básicas sobre o processo de build.

Para criar usuários de banco de dados e atribuir associações de função ao implantar um projeto de banco de dados em um ambiente de teste, você precisará:

Crie um script transact linguagem SQL (Transact-SQL) que faça as alterações necessárias no banco de dados.
Crie um destino de Microsoft Build Engine (MSBuild) que usa o utilitário sqlcmd.exe para executar o script SQL.
Configure seus arquivos de projeto para invocar o destino quando você estiver implantando sua solução em um ambiente de teste.

Este tópico mostrará como executar cada um desses procedimentos.

Criando script das associações de função de banco de dados

Você pode criar um script Transact-SQL de várias maneiras diferentes e em qualquer local escolhido. A abordagem mais fácil é criar o script em sua solução no Visual Studio 2010.

Para criar um script SQL

Na janela Gerenciador de Soluções, expanda o nó do projeto de banco de dados.
Clique com o botão direito do mouse na pasta Scripts , aponte para Adicionar e clique em Nova Pasta.
Digite Teste como o nome da pasta e pressione Enter.
Clique com o botão direito do mouse na pasta Teste , aponte para Adicionar e clique em Script.
Na caixa de diálogo Adicionar Novo Item , dê ao script um nome significativo (por exemplo, AddRoleMemberships.sql) e clique em Adicionar.
No arquivo AddRoleMemberships.sql , adicione instruções Transact-SQL que:
1. Crie um usuário de banco de dados para o logon SQL Server que acessará seu banco de dados.
2. Adicione o usuário do banco de dados a todas as funções de banco de dados necessárias.

O arquivo deve ser semelhante a este:

USE $(DatabaseName)
GO
CREATE USER [FABRIKAM\TESTWEB1$] FOR LOGIN[FABRIKAM\TESTWEB1$]
GO
USE [ContactManager]
GO
EXEC sp_addrolemember N'db_datareader', N'FABRIKAM\TESTWEB1$'
GO
USE [ContactManager]
GO
EXEC sp_addrolemember N'db_datawriter', N'FABRIKAM\TESTWEB1$'
GO

Salve o arquivo.

Executando o script no banco de dados de destino

Idealmente, você executaria todos os scripts Transact-SQL necessários como parte de um script pós-implantação ao implantar seu projeto de banco de dados. No entanto, os scripts pós-implantação não permitem que você execute a lógica condicionalmente com base em configurações de solução ou propriedades de build. A alternativa é executar seus scripts SQL diretamente do arquivo de projeto do MSBuild, criando um elemento Target que executa um comando sqlcmd.exe. Você pode usar esse comando para executar o script no banco de dados de destino:

sqlcmd.exe –S [Database server] –d [Database name] –i [SQL script]

Observação

Para obter mais informações sobre as opções de linha de comando do sqlcmd, consulte Utilitário sqlcmd.

Antes de inserir esse comando em um destino do MSBuild, você precisa considerar em quais condições deseja que o script seja executado:

O banco de dados de destino deve existir antes que você altere suas associações de função. Dessa forma, você precisa executar esse script após a implantação do banco de dados.
Você precisa incluir uma condição para que o script seja executado apenas para ambientes de teste.
Se você estiver executando uma implantação "e se", em outras palavras, se estiver gerando scripts de implantação, mas não realmente executando-os, não deverá executar o script SQL.

Se você estiver usando a abordagem de arquivo de projeto dividido descrita em Noções básicas sobre o arquivo de projeto, conforme demonstrado pela solução de exemplo do Contact Manager, você poderá dividir as instruções de build para o script SQL desta forma:

Todas as propriedades específicas do ambiente necessárias, juntamente com a propriedade que determina se as permissões devem ser implantadas, devem ir para o arquivo de projeto específico do ambiente (por exemplo, Env-Dev.proj).
O próprio destino do MSBuild, juntamente com as propriedades que não serão alteradas entre ambientes de destino, deve ir para o arquivo de projeto universal (por exemplo, Publish.proj).

No arquivo de projeto específico do ambiente, você precisa definir o nome do servidor de banco de dados, o nome do banco de dados de destino e uma propriedade booliana que permite que o usuário especifique se deseja implantar associações de função.

<PropertyGroup>
   <CmTargetDatabase Condition=" '$(CmTargetDatabase)'=='' ">
      ContactManager
   </CmTargetDatabase>
   <DatabaseServer Condition=" '$(DatabaseServer)'=='' ">
      TESTDB1
   </DatabaseServer>
   <DeployTestDBRoleMemberships Condition="'$(DeployTestDBRoleMemberships)'==''">
      true
   </DeployTestDBRoleMemberships>
</PropertyGroup>

No arquivo de projeto universal, você precisa fornecer o local do executável sqlcmd e o local do script SQL que deseja executar. Essas propriedades permanecerão as mesmas, independentemente do ambiente de destino. Você também precisa criar um destino do MSBuild para executar o comando sqlcmd.

<PropertyGroup>
   <SqlCmdExe Condition=" '$(SqlCmdExe)'=='' ">
      C:\Program Files\Microsoft SQL Server\100\Tools\Binn\sqlcmd.exe
   </SqlCmdExe>
</PropertyGroup>

<Target Name="DeployTestDBPermissions" 
        Condition=" '$(DeployTestDBRoleMemberships)'=='true' AND 
                    '$(Whatif)'!='true' ">
   <PropertyGroup>
     <SqlScript>
        $(SourceRoot)ContactManager.Database\Scripts\Test\AddRoleMemberships.sql
     </SqlScript>
     <_Cmd>"$(SqlCmdExe)" -S "$(DatabaseServer)" 
                          -d "$(CmTargetDatabase)" 
                          -i "$(SqlScript)"
     </_Cmd>
   </PropertyGroup>
   <Exec Command="$(_Cmd)" ContinueOnError="false" />
</Target>

Observe que você adiciona o local do executável sqlcmd como uma propriedade estática, pois isso pode ser útil para outros destinos. Por outro lado, você define o local do script SQL e a sintaxe do comando sqlcmd como propriedades dinâmicas dentro do destino, pois elas não serão necessárias antes que o destino seja executado. Nesse caso, o destino DeployTestDBPermissions só será executado se essas condições forem atendidas:

A propriedade DeployTestDBRoleMemberships é definida como true.
O usuário não especificou um sinalizador WhatIf=true .

Por fim, não se esqueça de invocar o destino. No arquivo Publish.proj , você pode fazer isso adicionando o destino à lista de dependências para o destino FullPublish padrão. Você precisa garantir que o destino DeployTestDBPermissions não seja executado até que o destino PublishDbPackages tenha sido executado.

<Project ToolsVersion="4.0" 
         DefaultTargets="FullPublish" 
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   ...
   <PropertyGroup>
      <FullPublishDependsOn>
         Clean;
         BuildProjects;
         GatherPackagesForPublishing;
         PublishDbPackages;
         DeployTestDBPermissions;
         PublishWebPackages;
      </FullPublishDependsOn>
   </PropertyGroup>
   <Target Name="FullPublish" DependsOnTargets="$(FullPublishDependsOn)" />
</Project>

Conclusão

Este tópico descreveu uma maneira de adicionar usuários de banco de dados e associações de função como uma ação pós-implantação ao implantar um projeto de banco de dados. Normalmente, isso é útil quando você recria regularmente um banco de dados em um ambiente de teste, mas geralmente deve ser evitado quando você implanta bancos de dados em ambientes de preparo ou produção. Dessa forma, você deve garantir que use a lógica condicional necessária para que os usuários do banco de dados e as associações de função sejam criados somente quando for apropriado fazer isso.

Leitura Adicional

Para obter mais informações sobre como usar o VSDBCMD para implantar projetos de banco de dados, consulte Implantando projetos de banco de dados. Para obter diretrizes sobre como personalizar implantações de banco de dados para diferentes ambientes de destino, consulte Personalizando implantações de banco de dados para vários ambientes. Para obter mais informações sobre como usar arquivos de projeto personalizados do MSBuild para controlar o processo de implantação, consulte Noções básicas sobre o arquivo de projeto e Noções básicas sobre o processo de build. Para obter mais informações sobre as opções de linha de comando do sqlcmd, consulte Utilitário sqlcmd.

Anterior Avançar

Compartilhar via