Web viewVisual Studio ALM Rangers. Documentação: Projetos de Banco de Dados no Visual...

Visual Studio ALM Rangers

Documentação: Projetos de Banco de Dados no Visual Studio 2010

Laboratórios

2010-10-12

Visual Studio ALM Rangers

Microsoft Corporation

Tradução e adaptação para o português:

Rodrigo Benin Ribeiro

[email protected]

Allmatech Tecnologia da Informação Ltda.

www.allmatech.com.br

Visual Studio ALM RangersEste conteúdo foi criado pelo Visual Studio ALM Rangers, um grupo especial formado por membros do time de produto do Visual Studio, Microsoft Services, Microsoft Most Valued Professionals (MVPs) e líderes da comunidade de Visual Studio.

A informação contida neste documento representa a visão atual da Microsoft Corporation sobre os assuntos discutidos na data de sua publicação. Como a Microsoft deve responder a mudanças das condições de mercado, não deve ser interpretado como um comprometimento de parte da Microsoft e a Microsoft não pode garantir a precisão da informação após a data de publicação.

http://www.allmatech.com.br/

mailto:[email protected]

Documentação: Projetos de Banco de Dados no Visual Studio 2010 - Laboratórios

Este documento tem fins informativos. A MICROSOFT NÃO DÁ GARANTIAS, EXPRESSA, IMPLÍCITA OU ESTATUTÁRIA REFERENTE ÀS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO.Microsoft licencia este documento sob os termos do Creative CommonsAttribution 3.0 License. Todos os demais direitos reservados.2009 Microsoft Corporation.Microsoft, Active Directory, Excel, Internet Explorer, SQL Server, Visual Studio, e Windows são marcas registradas do grupo de empresas Microsoft.Todas as outras marcas são de propriedade dos respectivos proprietários.

Copyright 2009 Microsoft Corporation

Traduzido e adaptado para o Português por Allmatech TI



ÍndiceAcrônimos........................................................................................................................................................................................ 6

Histórico do Documento..................................................................................................................................................................7

Colaboradores..................................................................................................................................................................................7

Revisores.......................................................................................................................................................................................... 7

Introdução....................................................................................................................................................................................... 8

Visão Geral.................................................................................................................................................................................. 8

Visual Studio ALM Rangers..........................................................................................................................................................8

Pré-requisitos..............................................................................................................................................................................8

Gerenciamento de Solução e Projeto..............................................................................................................................................9

Refatorando uma Solução do Visual Studio Database para habilitar código compartilhado.......................................................9

Objetivos do cenário:.............................................................................................................................................................9

Passo 1: Examine os bancos de dados físicos com código e objetos sobrepostos..................................................................9

Passo 2: Prepare a Solução de Banco de Dados...................................................................................................................11

Passo 3: Refatorar Referências e Dependências do Banco de Dados...................................................................................17

Passo 4: Refatore a Solução para habilitar Projetos Parciais...............................................................................................22

Passo 5: Propague as mudanças para os components de código compartilhado................................................................24

Controle de Código-Fonte e Gerência de Configuração.................................................................................................................25

Visão Geral dos Cenários:..........................................................................................................................................................25

Cenário #1: Modelo de Branching para um Único Time............................................................................................................26

Introdução............................................................................................................................................................................26

Definições de Branch para este cenário:..............................................................................................................................26

Passo 1: Criar um novo projeto para o banco de dados AdventureWorks...........................................................................27

Passo 2: Faça o Check in do novo projeto no Team Foundation Server...............................................................................34

Passo 3: Crie um branch da solução....................................................................................................................................36

Passo 4: Faça o deploy da solução de banco de dados........................................................................................................42

Passo 5: Fazendo o merge do branch (integrando alterações entre dois branches)............................................................44

Passo 6: Sincronize as alterações do código com a versão atual do banco de dados..........................................................47

Cenário #2: Modelo de Branching para Múltiplos Times...........................................................................................................49

Definições de Branch para este cenáro:...............................................................................................................................49

Passo 1: Crie um branch a partir da solução.........................................................................................................................50

Passo 2: Faça alterações no projeto.....................................................................................................................................54

Passo 3: Faça o merge das mudanças do branch Team1 para o Main..................................................................................56

Passo 4: Faça o merge das mudanças do branch Team2 para o Main..................................................................................58

Integrando Mudanças Externas com o Sistema de Projeto............................................................................................................62

Mantendo Linked Servers no Projeto de Banco de Dados do Visual Studio..............................................................................62

Resumo................................................................................................................................................................................62

Objetivos do Cenário............................................................................................................................................................62

Passo 1: Criar dois novos projetos, um referenciando o outro............................................................................................62





Movimentação Complexa de Dados..........................................................................................................................................67

Resumo................................................................................................................................................................................67

Objetivos dos Cenários.........................................................................................................................................................67

Cenário 1 – Movimentação Complexa de Dados – Comportamento Padrão para Edição de Desenvolvimento...................67

Cenário 2 – Movimentação Complexa de Dados – Engana engine de deployment (Enfraquece a experiência através da IDE, quebra o SCC como mastre, e gera uma desvantagem de performance).............................................................................73

Cenário 3 – Movimentação Complexa de Dados – Resolva o Problema de Performance (Não utilize a deployment engine, SCC torna-se o mestre).........................................................................................................................................................75

Cenário 4 – Movimentação Complexa de Dados –Integrar a Deployment Engine / Tratar conversão de dados externamente ao proejto.....................................................................................................................................................78

Automação de Build e Deploy com Projetos de Banco de Dados no Visual Studio.........................................................................83

Integração WiX com Deployment de Banco de Dados...............................................................................................................83

Resumo................................................................................................................................................................................83

Pré-requisitos.......................................................................................................................................................................85

Objetivos do Cenário............................................................................................................................................................86

Passo 1: Estruturando a solução..........................................................................................................................................86

Passo 2: Criando a Informação da Aplicação........................................................................................................................90

Passo 3: Configurando os redistribuíveis..............................................................................................................................98

Passo 4 – Configurando projetos de banco de dados.........................................................................................................101

Passo 5 – Sequências e Expressões Condicionais................................................................................................................105

Passo 6 – Propriedades e Interface de Usuário (UI)............................................................................................................109

Passo 7 – Armadilhas Comuns............................................................................................................................................113

Conclusão...........................................................................................................................................................................118

O Cenário de Integração com o Team Build............................................................................................................................119

Resumo..............................................................................................................................................................................119

Objetivos do Cenário..........................................................................................................................................................119

Passo 1: Crie uma definição de build..................................................................................................................................119

Passo 2: Enfileire um novo build a partir da definição........................................................................................................128

Passo 3: Verifique o progresso dos builds...........................................................................................................................130

Build e deploy fora do team build............................................................................................................................................132

Resumo..............................................................................................................................................................................132

Objetivos do cenário..........................................................................................................................................................132

Passo 1: Faça o build do projeto de banco de dados com o MSBUILD................................................................................133

Passo 2: Faça o deploy do banco de dados com o VSDBCMD.............................................................................................134

Testes de Banco de Dados e Verificação de Deployment.............................................................................................................135

O Cenário “Básico” de Criação de Testes Unitários.................................................................................................................135

Resumo..............................................................................................................................................................................135


Passo 1: Crie um teste unitário a partir de um modelo.....................................................................................................135

Passo 2: Adicione condições de teste para o teste unitário...............................................................................................140

O Cenário “Avançado” de Criação de Testes Unitários............................................................................................................143





Resumo..............................................................................................................................................................................143


Passo 1: Configure o ambiente para múltiplos desenvolvedores......................................................................................143

Passo 2: Deployment do banco de dados de teste.............................................................................................................145

Passo 3: Gerando dados de teste.......................................................................................................................................146

Passo 4: Testes de Performance Simples............................................................................................................................149

Cenário – Encontrando Alterações de Modelo........................................................................................................................150

Resumo..............................................................................................................................................................................150

Objetivos Gerais do Cenário...............................................................................................................................................153

Cenário 1: Garanta que você testou seu banco de dados com a versão correta de produção SEM ter acesso ao ambiente de produção (Versão confiável do DBA).............................................................................................................................153

Cenário 2: Certifique-se de que você testou a aplicação de banco de dados com a versão obtida, COM acesso ao banco de dados (Versão confiável do desenvolvedor).......................................................................................................................156

Referências..................................................................................................................................................................................157

Documentação Técnica de Design......................................................................................................................................157

Vídeos.................................................................................................................................................................................157

Links Gerais.............................................................................................................................................................................157





AcrônimosEste guia utiliza os seguintes acrônimos comuns:

ACRONIMO DESCRIÇÃO

ATDT Application Tier, Data Tier (camada de aplicação, camada de dados).





Histórico do Documento20090501 v0.1 Willy-Peter Schaub Criar um document base.

20090811 v1.0 Jens K. Süßmeyer UE Revisão Finalizada

20111001 v2.0 Rodrigo Benin Ribeiro Tradução e adaptação para o Português

Colaboradores

Shishir Abhyanker Microsoft , Senior Development Engineer II | Visual Studio ALM Range

Chris Burrows Microsoft, SENIOR CONSULTANT

Larry Guger MVP, Visual Studio ALM Ranger

Barclay Hill Microsoft, Senior Program Manager, Visual Studio for BizApps

Pablo Rincon Microsoft, Software Development Engineer | Visual Studio ALM Range

Scott Sharpe Microsoft, SENIOR Software Development Engineer | Visual Studio ALM Ranger

Jens K. Süßmeyer Microsoft, Senior Consultant | Visual Studio ALM Ranger

LeRoy Tuttle Microsoft, Senior Development Engineer | Visual Studio ALM Range

RevisoresVisual Studio ALM Rangers Visual Studio ALM Core and Extended Rangers

Bijan Javidi Microsoft, Solution Architect | Visual Studio ALM Ranger





Introdução

Visão GeralBem vindo ao Visual Studio Database Projects Hands-on Labs (HOL). Os HOLs estão aderentes à estrutura da documentação do Visual Studio Database Project Guidance disponível no Codeplex. Alinhados com a estrutura deste documento, os cenários dos HOLs estão divididos nas seguintes seções:

Seção de Gerenciamento de Solução e Projeto Controle de Código Fonte e Gerência de Configuração Integrando Mudanças Externas com o Sistema de Projeto Automação de Build e Deploy com o Visual Studio Database Projects Testes de Banco de Dados e Verificação de Deployment

Cada seção irá contribuir para o entendimento do tópico coberto no documento guia.

Visual Studio ALM RangersO Visual Studio ALM Rangers é um grupo especial formado por membros do grupo de produto do Visual Studio, da Microsoft Services, Microsoft Most Valued Professionals (MVP) e Líderes da Comunidade de Visual Studio. A missão deles é prover soluções adicionais para funcionalidades não implementadas e guias de uso.Este guia foi feito para usuários nível Microsoft “200-300” do TFS. O grupo alvo é considerado de usuários do Team Foundation Server de nível intermediário para avançado e possui entendimento em profundidade das funcionalidades do produto em um ambiente do mundo real. Partes deste guia podem ser úteis a novatos e experts no Team Foundation Server, porém este não é nível de profissional focado neste conteúdo.

Pré-requisitosPara completar o passo a passo dos cenários básicos e avançados dos laboratórios será necessário o seguinte ambiente:

Visual Studio ALM Rangers Base Image (TR Hands-On-Lab) - ou

Um único servidor (físico ou virtual) cujo ambiente possua os seguintes softwares instalados e configurados:

Software Versão Nota

Sistema Operacional Windows Server 2008 RC 2 ainda não foi testado

IIS IIS7 Empacotado como parte do SO

SQL Server SQL Server 2008 SP1 Recomenda-se Enterprise Edition

Windows SharePoint Services WSS 3.0 SP2

Microsoft Office Office 2007 SP1 Recomenda-se no mínimo a versão Professional

Team Foundation Server 2010

Visual Studio Ultimate 2010





Gerenciamento de Solução e Projeto

Refatorando uma Solução do Visual Studio Database para habilitar código compartilhado

Objetivos do cenário:

Identificar, manter e compilar de forma independente objetos compartilhados de banco de dados Refatorar projetos e dependências sobrepostas de banco de dados Habilitar SDLC através de componentização em nível de projeto

NOTA

No HOL, nós algumas vezes nos referimos ao caminho local C:\Users\Administrator\Documents\Visual Studio 2010\Projects\SharedCode. Este caminho padrão para os projetos do Visual Studio pode ser utilizado se você iniciar o HOL e criar os projetos você mesmo, passo a passo. Se ao invés disso você quiser utilizar os projetos pré-definidos para cada passo, utilize a pasta mencionada no início de cada passo. Arquivos iniciais e finais estão definidos neste local correspondente ao passo.

Passo 1: Examine os bancos de dados físicos com código e objetos sobrepostos

Para a proposta deste laboratório iremos assumir que estamos refatorando dois bancos de dados existentes que contém tabelas com definições idênticas. O SQL Server Reporting Services apresenta em sua implementação um cenário real com os bancos de dados criados durante a instalação do produto. São eles os bancos ReportServer e ReportServerTempDB.

Duração estimada: 5 minutos

Identificar objetos com o mesmo nome nos bancos de dados ReportServer e ReportServerTempDB1. Abra o SQL Server Management Studio.2. No diálogo Connect to Server, na caixa de texto Server name: digite um ponto final (.) e clique em Connect.3. No painel Object Explorer, expanda a árvore indo para o ponto final ( .) e expanda o nó Databases. Observe a

existência dos bancos de dados ReportServer e ReportServerTempDB.4. Clique com o botão direito em ReportServer, e clique em New Query5. Na janela de query, execute a seguinte query para identificar os objetos com o mesmo nome nos dois bancos de

dados:

SELECT SCHEMA_NAME(schema_id) as SchemaName,name as ObjectName,type_desc as ObjectType

FROM ReportServer.sys.objects WHERE is_ms_shipped = 0INTERSECTSELECT SCHEMA_NAME(schema_id) as SchemaName

,name as ObjectName,type_desc as ObjectType





FROM ReportServerTempDB.sys.objects WHERE is_ms_shipped = 0;

Os resultados da execução da query devem estar similares a este:

Figura 1 Resultados da query para localizar objetos similares

Utilizando a instrução INTERSECT nós consultamos os objetos de sistema do banco ReportServer assim como do banco ReportServerTempDB e encontramos objetos que são comuns a ambos os bancos de dados. Este foi o ponto de partida utilizado para selecionar os objetos em um projeto qualquer.

NOTA

Em geral se você quiser consolidar projetos para criar projetos compartilhados você terá que se certificar de que a estrutura dos objetos é idêntica. Nós recomendamos que você generalize objetos que possuam schemas idênticos, como colunas, tipos de dados, e assim por diante. Objetos podem ter o mesmo nome e não ser idênticos porque seus schemas podem ser diferentes.





Passo 2: Prepare a Solução de Banco de Dados

Caminho dos arquivos finais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step2Duração estimada: 10 minutos

Criar uma solução e um projeto vazio do tipo SQL Server 2008 Database

Parâmetro Valor

Solution SharedCode

Project Database1

1. Abra o Microsoft Visual Studio 2010 (edição Ultimate ou Professional).2. No menu principal clique em File, New, Project.3. No painel Installed Templates, expanda o nó Database, clique em SQL Server e depois em SQL Server 2008 Database

Project.4. Na caixa de texto Name digite o seguinte texto: Database1.5. Na caixa de texto Solution Name digite SharedCode e clique no botão OK.6. No menu principal clique em File, Save All.

Engenharia reversa do banco de dados “ReportServerTempDB” no projeto Database1

Parâmetro Valor

Project Database1

Server .

Database ReportServerTempDB

1. No Solution Explorer, clique com o botão direito em Database1 e clique em Properties.2. Na aba Database1, selecione o check box Include schema name in file name (Figura 2).

Figura 2 Altere as propriedades do projeto para incluir o nome do schema





3. No Solution Explorer, clique com o botão direito em Database1 e clique em Import Database Objects and Settings.4. No Import Database Wizard clique em New Connection5. No diálogo Connection Properties, no combo Server Name digite um ponto final (.)6. No combo Select or enter database name selecione o banco de dados ReportServerTempDB.7. Clique em OK.8. No Import Database Wizard clique no botão Start.9. Quando o processo de importação dos objetos terminar você verá a mensagem “Click Finish to continue.” Clique em

Finish.10. No menu principal clique em File, Save All.

Engenharia reversa do banco de dados “ReportServer” em um novo projeto

Parâmetro Valor

Project Database2

Server .

Database ReportServer

1. No Solution Explorer, clique com o botão direito em Solution ‘SharedCode’ (1 project), clique em Add e clique em New Project.

2. No diálogo Add New Project, confirme que SQL Server 2008 Database Project está selecionado.3. Na caixa de teste Name digite Database2 e clique em OK.4. No Solution Explorer, clique com o botão direito em Database2, e clique em Properties.5. Na aba Database2, selecione o check box Include schema name in file name.6. No Solution Explorer, clique com o botão direito em Database2 e clique em Import Database Objects and Settings.7. No Import Database Wizard clique em New Connection.8. No diálogo Connection Properties, no combo Server Name digite um ponto final (.)9. No combo Select or enter database name, selecione o banco de dados ReportServer e clique em OK.10. No Import Database Wizard clique em Start.11. Quando o processo de importação dos objetos terminar você verá a mensagem “Click Finish to continue.” Clique em

Finish.12. No menu principal, clique File, Save All.





Determine quais tabelas são comuns nos projetos de banco de dados originais

Parâmetro Valor

Source Schema Project Database1

Target Schema Project Database2

Equal tables dbo.ChunkData, dbo.ChunkSegmentMapping, dbo.Segment

1. No menu principal, clique Data, clique Schema Compare, e clique em New Schema Comparison.2. No diálogo New Schema Comparison (Figura 3), verifique que o valor do campo Source Schema Project está definido

com Database1, e que o campo Target Schema Project está com o valor Database2. Clique em OK.

Figura 3 Nova comparação de schemas para encontrar os objetos equivalentes3. Na janela principal selecione a nova aba criada SchemaCompare1.4. No menu principal, clique Data, clique Schema Compare, clique Filter e clique em Equal Objects.5. Na aba SchemaCompare1, inspecione e tome nota das tabelas que possuem definições equivalentes nos dois

projetos de banco de dados. A aba SchemaCompare deverá estar similar a Figura 4.

Figura 4 Resultado da comparação de Schema





6. Feche a aba SchemaCompare1 clicando no X ao lado da aba. Quando for solicitado, descarte as alterações realizadas em SchemaCompare1 (não é necessário salvar o arquivo).

7. No menu principal clique em File, Save All.

NOTA

Na prática, a seleção de objetos e código reutilizáveis deve ser feita como parte de uma decisão deliberada de design. O processo de comparação de schema exibido anteriormente pode ser utilizado para auxiliar essa decisão. Contudo, não deve ser o único método utilizado para realizar esta tarefa!

Engenharia reversa das estruturas das tabelas comuns em um novo projeto

Parâmetro Valor

Project Database3

Shared tables dbo.ChunkData, dbo.ChunkSegmentMapping, dbo.Segment

1. No Solution Explorer, clique com o botão direito em Solution ‘SharedCode’ (2 projects), clique em Add e clique em New Project.

2. No diálogo Add New Project, confirme que SQL Server 2008 Database Project está selecionado.3. Na caixa de texto Name digite Database3 e clique em OK.4. No painel Solution Explorer, clique com o botão direito em Database3, e clique em Properties.5. Na aba Database3, selecione o check box Include schema name in file name.6. No Solution Explorer, clique com o botão direito em Database3 e clique em Import Script.7. No diálogo “Welcome to the Import SQL Script Wizard”, clique em Next.8. No diálogo “Select SQL Script File to Import wizard” selecione a opção Multiple files e clique em Browse.9. No diálogo “Parent Directory for SQL Scripts” vá até C:\Users\Administrator\Documents\Visual Studio 2010\

Projects\SharedCode\Database1\Schema Objects\ e clique na pasta Schemas. Depois clique em Select Folder.10. No diálogo “Select SQL Script File to Import” sob o item Multiple files na árvore de items, desmarque o nó raiz e

expanda totalmente o nó Tables.





11. Na árvore de arquivos abaixo do nó Tables (Figura 5), selecione todos os 14 arquivos sob o nós Tables, Constraints, Indexes, e Keys que estejam relacionados às tabelas dbo.ChunkData, dbo.ChunkSegmentMapping, e dbo.Segment. Depois clique em Finish.

Figura 5 Selecione os arquivos para importar no wizard

12. Quando o processo de importação dos objetos estiver finalizado você verá a mensagem “Click Finish to continue.” Clique em Finish.

13. No menu principal clique File, Save All.





Adicione um VIEW para ser compartilhada que dependa de um objeto de sistema

Parâmetro Valor

Project Database3

View name dbo.vwRowCounts

1. No Solution Explorer, expanda a árvore e vá para o nó Solution ‘SharedCode’ (3 projects), Database3, Schema Objects, Schemas, dbo, Views.

2. Clique com o botão direito no nó Views, clique Add, e então clique em View.3. No diálogo Add New Item – Database 3, certifique-se que View está selecionado.4. Na caixa de texto Name digite dbo.vwRowCounts e clique em Add.5. Na aba dbo.vwRowCounts.view.sql digite o seguinte código TSQL:

CREATE VIEW dbo.vwRowCountsASSELECT Y.object_id

,SCHEMA_NAME(Y.schema_id) as SchemaName,Y.name as ObjectName,X.rows as NumRecs

FROM sys.partitions as X WITH(NOLOCK) INNER JOIN sys.objects as Y WITH(NOLOCK)

ON X.object_id = Y.object_id WHERE X.index_id <= 1 AND Y.is_ms_shipped = 0;

6. No menu principal, clique em File, Save All.7. Note que o Error List agora mostra mensagens sobre as referências não encontradas para sys.objects e sys.partitions.





Passo 3: Refatorar Referências e Dependências do Banco de Dados

Agora que montamos os componentes iniciais em projetos separados nós precisamos refatorar dependências e referências fortemente acopladas de forma que os projetos possam ser compilados juntos formando uma solução coesa. Antes que o código compartilhado possa ser injetado nesses projetos eles precisam compilar individualmente sem erros.

Local dos arquivos iniciais:C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step2_AnswerLocal dos arquivos finais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step3_Answer


Configure o projeto startup e bloqueie o deployment do projeto shared code1. No Solution Explorer, clique com o botão direito em Solution ‘SharedCode (3 projects), e clique em Properties. A

página de propriedades da solução irá aparecer (Figura 6).2. No diálogo Solution ‘SharedCode’ Property Pages, selecione a opção Single startup project e então selecione o

projeto Database3 no mesmo combo.3. No painel esquerdo, clique em Configuration Properties.4. Na lista Configuration, selecione All Configurations.5. No painel direito, desmarque o checkbox Deploy para o Database3 project e clique em OK.

Figura 6 Defina as ações de Build e Deployment para os projetos

NOTA

Na prática você pode desejar variar as outras opções da solução por tipo de configuração, isto é, debug vs. release. Contudo, normalmente você não irá desejar realizar deploy do projeto shared code a não ser que esteja realizando testes unitários contra ele.





Adicione referências a dbschemas externos para resolver objetos de sistema do SQL Server

Parâmetro Valor

Projects Database3 & Database2

master DB sys.objectssys.partitionsdbo.xp_sqlagent_enum_jobsdbo.sysobjects

msdb DB dbo.sysjobsSp_delete_job

1. Utilizando o Windows Explorer, crie uma nova sub-pasta abaixo da pasta da solução (C:\Users\Administrator\Documents\visual studio 2010\Projects\SharedCode\) chamada: DBSCHEMA

2. Copie os arquivos dbschema para os objetos de bancos de dados master e msdb a partir de C:\Program Files\Microsoft Visual Studio 10.0\VSTSDB\Extensions\SqlServer\2008\DBSchemas na pasta criada no passo anterior.

3. No Solution Explorer, clique com o botão direito em Solution ‘SharedCode’ (3 projects), clique em Add e então clique em Add Existing Item.

4. No diálogo Add Existing Item, vá para a pasta criada no passo 1, selecione os arquivos master.dbschema e msdb.dbschema. Clique em Add.

5. No Solution Explorer, expanda a árvore e vá até o nó Solution ‘SharedCode’ (3 projects), Database3, References.6. Clique com o botão direito no nó References, clique em Add Database Reference.7. No diálogo Add Database Reference, selecione a opção Database project schema (.dbschema) e clique em Browse.8. No diálogo Select Database File, vá para a pasta criada no passo 1 e dê um duplo-clique no arquivo

master.dbschema.9. Clique OK. Note algum tempo necessário ao processamento de todo o conteúdo do dbschema.10. Repita os passos de 5 a 9, porém desta vez adicione a referência para master.dbschema no projeto Database1.11. Repita os passos de 5 a 9, porém desta vez adicione a referência para master.dbschema no projeto Database2.12. Repita os passos de 5 a 9, porém desta vez adicione a referência para msdb.dbschema no projeto Database2.13. No menu principal clique em Build, Rebuild Solution.14. No menu principal clique em File, Save All.





Parametrize os nomes dos objetos de terceiros com referência a Database Schemas

Parameter Value

Project Database2

Variable name $(ReportServerTempDB)

Variable value ReportServerTempDB

1. No Solution Explorer, expanda a árvore e vá até o nó Solution ‘SharedCode’ (3 projects), Database2, References.2. Na árvore do Solution Explorer, clique com o botão direito no nó References e clique Add Database Reference.3. No diálogo Add Database Reference (Figura 7), selecione o checkbox Define database variable.4. No lista Database projects in the current solution, selecione Database1.5. Abaixo do checkbox Define database variable, na caixa de texto Name digite: $(ReportServerTempDB).6. No caixa de texto Value, digite: ReportServerTempDB.7. Selecione o checkbox Update the existing schema object definitions and scripts to use the database reference

variables, e clique em OK.

Figura 7 Adicione uma referência ao projeto Database1 para resolver os problemas de resolução de nomes

8. No diálogo Preview Changes – Rename Server or Database, reveja as mudanças pendentes e clique em Apply.9. No menu principal, clique em Build e depois clique em Rebuild Solution.10. No menu principal, clique em File, Save All.





Otimize as referências ao dbschema externo para os objetos de sistema do SQL Server

NOTA

Você deve notado que é necessário algum tempo para validar e processar cada referência feita pelos projetos aos arquivos master.dbschema ou msdb.dbschema. Isso se deve ao grande número de objetos definidos em cada um desses arquivos, a maioria dos quais não são necessários nesta solução. Na prática você deve fazer uma cópia desses arquivos por solução e editá-los para remover todas as referências a objetos não utilizados.

Parâmetro Valor

master.dbschema Type=”ISql100DatabaseOptions”Name=”[sys].[objects]”Name=”[sys].[partitions]”Name=”[sys].[sysobjects]”Name=”[dbo].[xp_sqlagent_enum_jobs]”

msdb.dbschema Type=”ISql100DatabaseOptions”Name=”[dbo].[sp_delete_job]”Name=”[dbo].[sp_verify_job_identifiers]”Name=”[dbo].[sysjobs]”

1. No Solution Explorer, expanda a árvore e vá até o nó Solution ‘SharedCode’ (3 projects), Solution Items.2. Dê um duplo-clique no arquivo master.dbschema para editar o seu conteúdo XML.3. Na aba master.dbschema, sob element XML <Model>, delete todas as entidades <Element /> que não se encaixam

no padrão listado na tabela acima. Nós sugerimos que você recorte e cole os elementos desejados do topo do documento, diretamente abaixo do nó <Model>. Após isso, delete o restante das entidades <Element />.

4. Repita os passos 2-3 para o arquivos msdb.dbschema e seus valores.5. No menu principal, clique em Build e então em Rebuild Solution. Finalmente, verifique se você não introduziu novos

erros ou alertas.





Algumas limpezas no projeto

NOTA

Há também uma referência ambígua para uma proc de sistema contida no banco de dados msdb no mesmo projeto (a referência não especifica o owner da SP); então vamos corrigir o problema!

1. No Solution Explorer, expanda a árvore e vá até o nó Solution ‘SharedCode’ (3 projects), Database2, Schema

Objects, Schemas ,dbo, Programmability, Stored Procedures.

2. Clique com o botão direito em dbo.MigrationExecutionLog.proc.sql, e então clique em Exclude from Project.

NOTA

Há uma stored procedure com uma referência não resolvida para um objeto órfão em no projeto Database2 (ReportServer). Provavelmente este problema não existiria se os desenvolvedores originais estivessem usando o VSDB! Vamos excluí-la do projeto de forma que o problema não nos distraia dos objetivos do laboratório.

1. No menu principal, clique em View, Error List.2. No painel Error List, dê um duplo-clique no alerta SQL04151 referente ao arquivo

dbo.Get_sqlagent_job_status.proc.sql.3. Corrija o erro alterando a chamada a SP utilizando o nome totalmente qualificado (fully-qualified name):

EXECUTE @retval = msdb..sp_verify_job_identifiersdeve ser alterado para EXECUTE @retval = msdb.dbo.sp_verify_job_identifiers

4. No menu principal, clique em Build e então em Rebuild Solution.5. No menu principal, clique File, All.

IMPORTANTE

A solução deve compilar por completo sem nenhum erro ou alertas. É importante ter as coisas funcionando bem nesse passo antes de partirmos para a implementação dos arquivos de projetos parciais. Se não tivermos um estado limpo (sem erros ou alertas) pode ser mais complicado identificar os problemas após a implementação dos arquivos de projetos parciais.





Passo 4: Refatore a Solução para habilitar Projetos Parciais

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode \Step3_AnswerLocal dos arquivos finais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step4_AnswerDuração Estiamada: 15 minutos

Verifique que os objetos nos código compartilhado não irão propagar erros1. No Solution Explorer, clique com o botão direito no projeto Database3 e então clique em Properties.2. Na aba Database3, selecione a página Code Analysis.3. No painel da direita, selecione o check box Enable Code Analysis on Build.4. No menu principal, clique em Build e em Rebuild Database3.5. No painel Output, verifique que o build do projeto foi bem sucedido.6. No painel Error List, corrija todos os erros e alertas de análise de código, caso haja algum.7. No menu principal, clique em File, Save All.

Exporte os objetos compartilhados como uma definição de arquivo de projeto parcial1. No Solution Explorer, clique com o botão direito em Database3 e então clique em Export As Partial Project2. No diálogo Save As, clique em New Folder, e depois digite: Partial Projects Export.3. Na caixa de texto File name, digite: Shared Objects e então clique Save.4. No diálogo do Microsoft Visual Studio entitulado Do you want to add this partial project file to your current project?

clique em Yes.

Refatore a configuração padrão do arquivo de projeto parcial1. No Solution Explorer, abaixo de Database3, Partial Projects Export, dê um duplo-clique em Shared Objects.files.2. No diálogo Inconsistent Line Endings, clique em Yes.3. Na aba Shared Objects.files, tome nota do nome da propriedade referenciada no comentário no topo do arquivo;

deve ser algo como Database3BasePath_XX_X_XXX_X_XX_XX_XX.4. Encontre e substitua todas as ocorrências do valor do nome desta propriedade por Database3BasePath. Altere 19

instâncias desse valor.5. Encontre e substitua todas as ocorrências de <Link>Database3BasePath\’ por ‘<Link>Partial Projects Import\Shared

Objects\. Altere 9 instâncias do valor.6. No menu principal, clique em File, Save All.7. Feche a aba Shared Objects.files.

Importe os arquivos parciais de projeto e elimine os conflitos de referências não resolvidas1. No Solution Explorer, clique com o botão direito em Database2 e então clique em Import Partial Project.2. No diálogo do Microsoft Visual Studio entitulado Including a partial project will cause the project to load and

unload. Do you want to save your project and continue? clique em Yes.3. No diálogo Open, vá para a pasta ..\Database3\Partial Projects Export e dê um duplo-clique em Shared Objects.files.4. No menu principal, clique em View e então em Error List.





NOTA

Ao importar os arquivos parciais de projeto do projeto Database3 no projeto Database2, nós de fato duplicamos os objetos para cada objeto compartilhado – aqueles que importamos e os que foram identificados quando fizemos a comparação dos esquemas de banco de dados entre os projetos Database1 e Database2. Estas entradas duplicadas resultaram em diversos erros de referências não resolvidas (SQL03006) os quais precisam ser corrigidos removendo os objetos originais do projeto Database2 e mantendo os objetos importados.

5. No Solution Explorer, expanda o nó Database2 e expanda os seguintes nós: Schemas , dbo, Tables, dbo.ChunkData.table.sql.

6. Clique com o botão direito em dbo.ChunkData.table.sql, clique em View Object in Schema View e então clique em ChunkData.

NOTA

Existem duas entradas para esta tabela, ambas prefixadas por um ícone de erro. Você precisa vizualizar as propriedades de cada uma delas e excluir a que esteja na estrutura de pastas do projeto Database2, mantendo a outra definição referente ao projeto compartilhado Database3.

7. Clique com o botão direito em ChunkData, e então clique em Properties.8. No painel de propriedades, examine o valor da propriedade Full Path. Caso ela esteja fazendo referência ao caminho

do projeto Database2, delete a entidade ChunkData. Caso contrário, inspecione e delete a outra entidade ChunkData.

9. Repita os passos 7-8 para as tabelas ChunkSegmentMapping e Segment.10. No menu principal, clique Build e então clique em Rebuild Database2.11. Examine o conteúdo do painel Error List e repita os passos 7-8 para cada novo objeto chave, constraint, índice no

projeto Database2.12. No menu principal, clique Build e depois em Rebuild Database2.13. Na janela Output, verifique se a compilação do projeto foi bem sucedida.14. No painel Error, certifique-se de que não há erros ou alertas.15. No menu principal, clique em File e então em Save All.16. Repita os passos 1-14, mas desta vez, importe os arquivos parciais do projeto Database3 no Database1.

Exercite diferentes níveis de granularidade do build1. No Solution Explorer, clique com o botão direito Database3 e clique em Rebuild.2. Clique com o botão direito em Database3 e então clique em Unload Project.3. Clique com o botão direito em Database1 e então clique em Rebuild.4. Clique com o botão direito em Database2 e então clique em Rebuild.5. No menu principal, clique Build e então clique em Rebuild Solution.

NOTA





Com este tipo de build você irá notar que atualmente nós não precisamos que a solução Database3 compile os outros dois projetos referenciados. O projeto parcial é referenciado a partir dos arquivos de projeto e você não precisa incluir o projeto Database3 na sua solução.

Passo 5: Propague as mudanças para os components de código compartilhado

Agora que nós refatoramos e consolidamos o código compartilhado em um projeto comum, nós podemos com facilidade realizar mudanças a estas estruturas de forma centralizada e automaticamente propagar estas mudanças para os projetos dependentes.

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step4_AnswerLocal dos arquivos finais: C:\HOL\DatabaseProjectGuidance\SolutionProjectMgmt\SharedCode\Step5_AnswerDuração Estimada: 10 minutos

Altere uma view no projeto compartilhado1. No painel Solution Explorer, expanda a árvore e vá para Solution ‘SharedCode’ (3 projects), Database3. (Caso o

projeto esteja descarregado do passo 4 neste cenário, clique com o botão direito no nó do projeto e selecione Reload Project.) Após, clique no nó Schema Objects, Schemas , dbo, Views, e então efetue um duplo-clique dbo.vwRowCounts.view.sql.

2. Na aba dbo.vwRowCounts.view.sql, edite a definição da view e adicione uma nova coluna chamada ‘DatabaseName’ que retorne DB_NAME() como seu valor.

3. No menu principal, clique em Build e selecione Rebuild Database3.4. No painel Output, verifique que o build do projeto foi bem sucedido, sem erros ou alertas.5. No menu principal, clique em Build e então em Build Solution.6. No painel Output, verifique que o build da solução foi bem sucedido, sem erros ou alertas.

Inspecione os projetos dependentes e verifique que as alterações no código compartilhado foram propagadas1. No painel Schema View, expanda a árvore e navegue até o nó Database1, Schemas, dbo, Views, vwRowCounts,

Columns. Observe a adição da coluna DatabaseName.2. Clique com o botão direito em vwRowCounts e selecione Properties.3. No painel Properties, examine o valor da propriedade Full Path e note que ela faz referência ao arquivo localizado na

árvore de diretórios do projeto Database3.4. Repita os passos 1-3, mas desta vez examine a mesma visão lógica no projeto Database2.




C:\\HOL\\DatabaseProjectGuidance\\SolutionProjectMgmt\\SharedCode\\Step4_Answer


Controle de Código-Fonte e Gerência de Configuração

Visão Geral dos Cenários:

Estes cenários mostram exemplos de situações comuns nas quais os times de desenvolvimento se encontram e oferece padrões de branching (ramificações do controle de código fonte) para solucionar tais situações. Um dos desafios mais frequentes enfrentados empresas de desenvolvimento é quando times distintos necessitam trabalhar em paralelo, ou precisam isolar uma parte do seu trabalho dos demais times. Estes cenários devem permitir aos times rapidamente compreender as várias opções de branching disponíveis. Os cenários devem ainda prover o arcabouço necessário para que os times adotem uma estrutura de branching que atenda às suas necessidades. É importante ressaltar que enquanto estes cenários apresentam soluções válidas para situações específicas é possível que existam soluções alternativas que também sejam válidas.Cada cenário descreve o esquema do banco de dados, a estrutura de projeto do the Visual Studio Database e a hierarquia da estrutura de branching. Mesmo sendo estes elementos complexos para a maioria dos times de desenvolvimento, padrões de branching se apresentam como soluções recorrentes e nós esperamos que os cenários aqui apresentados ajudem a responder questões como: quando ramificar, o que ramificar e o valor que a ramificação traz para tornar os esforços de desenvolvimento mais rápidos e suaves. Em cada cenário nós apresentamos uma situação enfrentada por um time de desenvolvimento hipotético trabalhando no banco de dados AdventureWorks. A estrutura de branching recomendada, assim como o processo de branching e merging serão explorados e examinados em detalhe.





Cenário #1: Modelo de Branching para um Único Time

Objetivos do cenário:

Descrever como os projetos de banco de dados do Visual Studio podem:o Ser integrados com o controle de código-fonteo Suportar o desenvolvimento de banco de dados e o processo de gerenciamento de mudanças

Introdução

Alinhados às recomendações gerais para branching e merging, que podem ser encontradas no guia de branching e merging publicado pelos grupo Visual Studio ALM Rangers no Codeplex “Microsoft Team Foundation Server Branching Guidance” 1

os cenários utilizarão a seguinte metodologia de branching.

Figura 8 Modelo de branching para time único

Definições de Branch para este cenário:

DEV – O branch DEV está isolando todas as atividades relacionadas a novos densevolvimentos, seja para novas funcionalidades, correção de bugs para o próximo release (vNext), ou para integração de grandes mudanças. Esta área é projetada para isolar, conter e estabilizar as novas atividades de desenvolvimento.

MAIN – O branch MAIN é utilizado para a estabilização final (QA) de todas as funcionalidades antes do release da próxima versão (vNext). MAIN deve ser sempre mantido o mais estável possível.

1 http://branchingguidance.codeplex.com/



88

7766

554433

2211 V1.0

Production

Nightly Build(Early Validation)

CI / Nightly Builds(Early validation)

V1.2

RI

V1.2

FI

V1.1

FI

V1.1 (bug fix)

RI

V1.1 FT3V1.1 (start)

FIBranch

MAIN

DEV


http://branchingguidance.codeplex.com/

http://branchingguidance.codeplex.com/


Passo 1: Criar um novo projeto para o banco de dados AdventureWorks

A base para este laboratório será um projeto de banco de dados do Adventureworks, o qual será extraído de um banco de dados pré-existente na máquina do HOL. Caso você já tenha alterado o schema do banco de dados e queira preservar as mudanças certifique-se de fazer um backup ou renomear seu banco de dados antes do exercício.


Restaure o AdventureWorksDB

A máquina do HOL contém um backup do banco de dados AdventureworksDB que foi baixado do SQL Server Samples Site.2 Para restaurá-lo, execute os seguintes passos na máquina do HOL:

Cuidado

Os passos a seguir para restaurar o backup do banco de dados irão sobrescrever o banco AdventureworksDB, caso ele já exista. Se você fez alterações a este banco e quer preservá-las, faça um backup ou renomeie o banco de dados ADVENTUREWORKSDB existente antes do restore.

1. Vá até a pasta C:\HOL\DatabaseProjectGuidance\RestoreDatabase localizada na maquina do HOL.2. Execute o script StartAdventureWorksRestoration.cmd.3. Aguarde o prompt de commando ser fechado. Quando o backup tiver sido restaurado na sua máquina,

qualquer banco de dados com o nome AdventureworksDB será sobrescrito.

2 http://sqlserversamples.codeplex.com/




http://sqlserversamples.codeplex.com/




Crie um novo projeto de banco de dados e importe o schema do AdventureworksDB

1. Inicie o Visual Studio 2010.2. No menu File, aponte para New e clique em Project. Você verá o diálogo New Project mostrado na Figura 9.3. Sob Installed Templates, expanda o nó Database, expanda o nó SQL Server, e selecione o template SQL Server 2008

Wizard.4. Em Name, digite o nome AdventureWorksDB para o nome do projeto.5. Selecione o check box Add to source control.6. Clique em OK para confirmar a criação do projeto.

Figura 9 Diálogo de novo projeto para banco de dados

NOTACertifique-se de que você selecionou um nome e local que não tenha uma estrutura de diretórios muito longa. Como o sistema de projeto cria uma hierarquia para armazenar os scripts dos objetos, os nomes dos arquivos podem ser muito longos, levando a problemas durante a automação.

7. Como queremos colocar os artefatos no controle de versão do Team Foundation Server nós precisaremos especificar o servidor e o workspace (cópia local dos arquivos son controle de versão). Para tanto, o diálogo Connect to Team Project para conectar o projeto ao Team Foundation Server irá aparecer. (Figura 10).





Figura 10 Diálogo para conectar ao Team Project no Team Foundation Server

8. Selecione a máquina local como sendo o servidor de Team Foundation Server e clique em Connect. O diálogo Add <your project> to Source Control irá aparecer. (Figura 11)

9. Selecione Make new folder e nomeie a pasta como HOL_Database. Clique OK para fechar o diálogo.

Figura 11 Diálogo para adicionar a solução ao controle de versão

10. O wizard para importar um projeto de banco de dados a partir de um banco de dados existente (engenharia reversa) aparece. Clique Next. (Figura 12)





Figura 12 Página de boas vindas do New Project Wizard





11. Altere a opção padrão para Organize by Schema e clique em Next. (Figura 13)

Figura 13 Página de Propriedades de Projetos

12. Na página Set Database Options, selecione as opções desejadas e clique em Next. (Figura 14)

Figura 14 Página Set Database Options





13. Na página Import Database Schema, selecione os checkboxes conforme anbaixo. Import options: Import permissions Add imported permissions to the project model

14. Clique Next.(Figura 15)

Figura 15 Página Import Database Schema

15. Clique em New connection e especifique o nome do servidor digitando um ponto final (.) e clique no botão com do banco de dados “AdventureworksDB”. Clique em Finish. (Figura 15)

Figura 16 Página Configure Build and Deploy





16. Aguarde a importação do banco de dados ser finalizada. A mensagem “Click Finish to Continue” será escrita na janela de log. Clique em Finish para fechar o wizard. (Figura 17)

Figura 17 Progresso do processo de engenharia reversa





Passo 2: Faça o Check in do novo projeto no Team Foundation Server

Agora que criamos o projeto de banco de dados no passo 1 nós queremos utilizar o processo de branching e merging. Para fazer isso, nós devemos realizer o check in (subir o código-fonte) do projeto no Team Foundation Server.

Duração estimada: 1 minuto

Faça o check in das mudanças do projeto local para o controle de versão

1. No Solution Explorer, clique com o botão direito no projeto de banco de dados e clique em Check in. (Figura 18)

Figura 18 Iniciando o processo de check-para as mudanças pendentes





2. Certifique-se de que todos os items do projeto estão selecionados no painel Pending changes e então clique em Check in. (Figura 19)

Figura 19 Revise os artefatos para o check in e certifique-se de que todos estão selecionados

3. No menu principal, clique em File e então em Close solution.





Passo 3: Crie um branch da solução

Agora que fizemos o check in da solução e dos artefatos relevantes no Team Foundation Server, nós podemos iniciar o trabalho com as funcionalidades de controle de versão e criar branches (ramos).


1. No menu principal, clique em View e depois em Team Explorer.

2. No Team Explorer, dê um duplo-clique em Source Control (Figura 20). A árvore de código do controle de versão irá aparecer na janela principal do Visual Studio.

Figura 20 Janela do Team Explorer com a visão do projeto





3. Na janela Source Control, vá até o caminho do controle de versão em “$/HOL_DatabaseProjects/HOL_Database”, clique com o botão direito no nó e selecione Branching and merging e então clique em Branch. O diálogo mostrado na Figura 21 irá aparecer.

4. No combo Under Branch from version, selecione Latest version e no campo Target digite o nome HOL_Database-Branch_Rewards. Sempre digite uma descrição para o branch que torne mais fácil reconhecer sua finalidade no futuro. Clique em Ok para prosseguir.

Figura 21 Especifique as informações de origem do código para criar o branch

5. Se você ainda não especificou um workspace o seguinte diálogo irá aparecer, como mostrado Figura 22. Mapeie o Workspace para C:\HOL\DatabaseProjectGuidance\Workspace\HOL_Database-Branch_Rewards e clique em Map.

Figura 22 Crie um mapeamento para um workspace





6. O comando para realizar o branch sera enviado para o servidor e executado. Você verá o branch no Source Control Explorer, como mostrado na Figura 23.

Figura 23 Novo branch no Source Control Explorer

7. Utilizando o Team Explorer, reveja o novo branch e abra a solução HOL_Database.sln.

8. No Solution Explorer, clique com o botão direito no projeto de banco de dados e depois em Check in. (Figure 24)

Figure 24 Inicie o processo de check in para as alterações pendentes





9. Certifique-se de que todos os itens do projeto estejam selecionados no painel Pending changes e clique em Check in. (Figure 25)

Figure 25 Reveja os artefatos para o check In e certifique-se de que todos estão selecionados

10. Agora nós iremos iniciar mudanças no projeto de banco de dados. Mais tarde iremos realizar o merge dos artefatos do projeto de banco de dados de volta para o branch principal (main). Para simular o merge nós iremos importer uma série de arquivos que representam as mudanças que faremos no código do projeto.

11. No Solution Explorer, clique com o botão direito em AdventureWorksDB e em Import Script.

12. Na página “Welcome to the Import SQL Script Wizard” clique em Next.

13. Na página “Select SQL Script File to Import” selecione a opção Single file e clique em Browse.

14. Vá até a pasta C:\HOL\DatabaseProjectGuidance\Source Code Control and Configuration Management\RewardsProgram e selecione o arquivo RewardsProgrammScriptForImport.sql. Clique OK para fechar a caixa de diálogo.





Figura 26 Importe um arquivo com as mudanças para o branch

15. Clique em Finish para iniciar o processo de importação.





16. Quando o processo de importação estiver finalizado você verá a mensagem “Click Finish to continue.” Clique em Finish. (Figura 27)

Figura 27 O wizard importou as mudanças para o branch

Agora que o processo de importação foi concluído com sucesso vamos realizar o deploy das novas mudanças no banco de dados SQL Server.





Passo 4: Faça o deploy da solução de banco de dados

Nós criamos o branch a partir do código-fonte existente e nosso próximo passo será realizar o deploy do banco de dados para uma instância local do SQL Server.


1. No Solution Explorer, clique com o botão direito no nó do projeto e selecione Properties.

Clique com o botão direito no projeto AdventureWorksDB e selecione Properties. Selecione no combo Deploy action a opção “Create a deployment script (.sql) and deploy to the database. Na aba Deploy, ao lado próximo de Target connection clique em Edit para especificar uma conexão SQL válida

para o deployment. Digite um ponto final (.) no nome do servidor e clique em OK para fechar a janela de conexão.

Na aba Deploy, digite HOL_Eval2008_RewardsBranch como sendo o nome do banco de dados a ser criado no deployment. (Figura 28)

Figura 28 Propriedades de deployment do projeto

2. Como o AdventureworksDB inclui um FileStream filegroup e o caminho não será alterado automaticamente durante a importação do projeto, teremos que realizar algumas pequenas alterações para poder realizar o deploy.

No Solution Explorer, vá até Schema Objects, Database Level Objects, Storage, Files e abra o arquivo FileStreamDocuments.sqlfile.sql.

Altere o script .sql conforme abaixo para incluir o nome do banco de dados:

ALTER DATABASE [$(DatabaseName)] ADD FILE (NAME = [FileStreamDocuments], FILENAME = '$(Path3)$(DatabaseName).Documents') TO FILEGROUP [DocumentFileStreamGroup];





3. Clique com o botão direito na solução de banco de dados e selecione Deploy para realizar o deploy da solução para o banco de dados especificado. Você verá o progresso do deployment na janela Output do Visual Studio. (Se você não vizualizar a janela output, você poderá alternar para ela através do menu principal. Clique em View e então em Output. Ao visualizar a janela Output você poderá alterar a opção Show output from para Build. (Figura 29)

Figura 29 Monitorando o progresso do deployment na janela Output

O deployment deverá ser finalizado sem erros, conforme mostrado ao final da das mensagens na janela Output. (Figura 30)

Figura 30 Resultado final na janela Output





Passo 5: Fazendo o merge do branch (integrando alterações entre dois branches)

Agora que fizemos o deploy do banco de dados no servidor e o desenvolvimento foi finalizado, nós iremos fazer o check in das mudanças e realizar o merge destas mudanças com o branch main.


1. Agora que fizemos o deploy da versão ramificada e alterada do projeto para o servidor, nós temos uma versão diferente do banco de dados no nosso branch, para a qual devemos fazer check in.

No Solution Explorer, clique com o botão dierito no projeto de banco de dados e selecione Check in pending changes. O diálogo Pending Changes irá aparecer. (Figura 31)

Certifique-se de que todos os items estão selecionados e clique no botão Check In.

Figura 31 Reveja as alterações pendentes para o HOL_Database-Branch_Rewards

2. Para visualizar os branches existentes e preparar o merge vá para a janela Branch Visualization. Clique em no branch HOL_Database-Branch_Rewards, clique com o botão direito no nó e vá para Branching and merging. Clique em View hierarchy. A janela mostrada na Figura 32 irá aparecer.

Figura 32 Vizualização das ramificações (branching) para o branch criado





3. Na janela Branch Visualization, selecione o símbolo HOL_Database-Branch_Rewards, clique com o botão direito sobre ele e selecione o comando Merge. O Source Control Merge Wizard aparece. (Figura 33)

Figura 33 Source Control Merge Wizard

4. Após revisar a informação do wizard e certificar-se de que o branch de origem é o HOL_Database-Branch_Rewards e o branch de destino é o HOL_Database, e então clique em Next. (Figura 33)

5. Na próxima página certifique-se de que Latest version esteja selecionado para a operação de merge e clique em Next.

6. Na página “summary” clique em Finish para iniciar a operação de Merge.

7. No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione Check in pending changes. O diálogo Pending Changes aparece. (Figura 34)

Certifique-se de que todos os itens estão selecionados e clique em Check In.





Figura 34 Realize o check in das alterações pendentes realizadas durante a operação de merge





Passo 6: Sincronize as alterações do código com a versão atual do banco de dados

Agora que nós fizemos o merge das mudanças de volta para o branch principal (main), vamos fazer o deploy do banco de dados para garantir a sincronia do código-fonte com o deployment atual.

Duração estiamda: 1 minuto

1. No menu principal clique em Data, clique em Schema Compare e então clique em New schema comparison. O diálogo para uma nova comparação de schemas será aberto. (Figura 35)

Figura 35 Diálogo para uma nova comparação de schemas

Para o schema de origem (source schema) selecione o banco de dados de onde você extraiu o schema no passo 1. Trata-se do banco de dados Adventureworks no servidor local.

Para o schema alvo (target schema) (o banco de dados onde desejamos aplicar as alterações) selecione o banco de dados o qual foi feito deploy no passo 4 com o nome HOL_Eval2008_RewardsBranch.

Após definer os schemas de origem e destino clique em OK.

2. Você irá notar que no painel de resultado da comparação de schemas, o banco HOL_Eval2008_RewardsBranch contém alguns objetos que não existem no banco de dados AdventureworksDB. (Figura 36) As alterações do branch main ainda não foram aplicadas para o banco de dados correspondente. Neste ponto as alterações estão somente no controle de versão.





Figura 36 Painel com os resultados da compração de Schemas

3. Para aplicar as diferenças nós iremos utilizar a capacidade do projeto de banco de dados de realizar o deploy incremental das mudanças. Para tanto, no Solution Explorer, clique com o botão direito nos projetos de banco de dados e selecione Properties. Clique na aba Deploy e certifique-se de que as opções Create Deploy Script e Deployment action estejam selecionadas.

4. Clique com o botão direito na solução e clique em Deploy para fazer o deploy da solução para o banco de dados especificado. Você irá ver o progresso do deployment na janela Output do Visual Studio. Ao final das mensagens você deverá ver uma seção chamada Deployment script generated to que contém o caminho para o arquivo .sql para executar no banco de dados relativo ao branch main. Este script pode ser utilizado para sincronizar o banco de dados com o código do branch.





Cenário #2: Modelo de Branching para Múltiplos Times

Descrever como os projetos de banco de dados podem:o Integrar-se ao controle de código-fonteo Suportar o desenvolvimento do banco de dados em múltiplos brancheso Tratar alterações conflitantes entre os branches

Figura 37 Modelo de Branching para Múltiplos Times

Definições de Branch para este cenáro:

TEAM-1 – O branch TEAM-1 está isolando todas as atividades relacionadas a novos desenvolvimentos, seja para novas funcionalidades, correção de bugs para o próximo release (vNext), ou para integração de grandes mudanças. Esta área é projetada para isolar, conter e estabilizar as novas atividades designadas ao Time 1.

TEAM-2 – O branch TEAM-2 está isolando todas as atividades relacionadas a novos desenvolvimentos, seja para novas funcionalidades, correção de bugs para o próximo release (vNext), ou para integração de grandes mudanças. Esta área é projetada para isolar, conter e estabilizar as novas atividades designadas ao Time 2.

MAIN – O branch MAIN é utilizado para a estabilização final (QA) de todas as funcionalidades antes do release da próxima versão (vNext). MAIN deve ser sempre mantido o mais estável possível.





Passo 1: Crie um branch a partir da solução

Para simular diferentes times trabalhando no projeto nós criaremos 2 branches a partir da solução no branch main o qual nós fizemos check in anteriormente (veja o cenário #1).


1. Na janela “Source Control”, vá até o caminho do controle de versão $/HOL_DatabaseProjects/HOL_Database, clique com o botão direito neste nó e selecione Branching and merging. Clique em Branch. O diálogo Branch from HOL_Database irá aparecer, conforme mostrado na Figura 38.

2. No combo Branch from Version, selecione Latest version e digite o nome $/HOL_DatabaseProjects /HOL_Database-Team1 no campo Target Branch Name. Digite uma descrição para o branch que torne fácil reconhecer o seu propósito no futuro. Clique no botão Branch para prosseguir. (Figura 38)

Figura 38 Especifique informações sobre a origem do branch





3. Clique em Yes para confirmar que você deseja criar o branch.

Figura 39 Diálogo de confirmação do Branch

4. O comando de branching será enviado ao servidor e executado. Quando o processo de branching for finalizado, você irá visualizer o branch no Source Control Explorer, conforme mostrado na Figura 23.

Figura 40 Novo branch no Source Control Explorer

5. Reveja o novo branch utilizando o Team Explorer.





6. Na janela “Source Control”, vá até o caminho do controle de versão $/HOL_DatabaseProjects/HOL_Database, clique com o botão direito neste nó e selecione Branching and merging. Clique em Branch. O diálogo Branch from HOL_Database irá aparecer, conforme mostrado na Figura 41.

7. No combo Branch from Version, selecione Latest version e digite o nome $/HOL_DatabaseProjects /HOL_Database-Team2 no campo Target Branch Name. Digite uma descrição para o branch que torne fácil reconhecer o seu propósito no futuro. Clique no botão Branch para prosseguir. (Figura 38)

Figure 41 Especifique informações sobre a origem do branch

8. Clique em Yes para confirmar que você deseja criar o branch.

Figure 42 Diálogo de confirmação do branch





9. O comando de branching será enviado ao servidor e executado. Quando o processo de branching for finalizado, você irá visualizar o branch no Source Control Explorer, conforme mostrado na Figura 23.

Figure 43 Novo branch no Source Control Explorer

10. Reveja o novo branch utilizando o Team Explorer.





Passo 2: Faça alterações no projeto

Após criar dois branches, nós iremos simular diferentes alterações nos branches para preparamos o processo de merge que sera executado no próximo passo.


1. Faça alterações na tabela Purchasing.Vendor no branch Team1.

a. No Source Control Explorer, abra a solução a partir do branch HOL_Database-Team1.b. Abra o arquivo Vendor.table.sql file. Ele está localizado em AdventureWorksDB, AdventureWorksDB,

Schema Objects, Schemas, Purchasing, Tables.c. Adicione a coluna PreferredVendor adicionado a linha de código correspondente no script. O script final

deve ser como o abaixo:

CREATE TABLE [Purchasing].[Vendor] ( [VendorID] INT IDENTITY (1, 1) NOT NULL, [AccountNumber] [dbo].[AccountNumber] NOT NULL, [Name] [dbo].[Name] NOT NULL, [CreditRating] TINYINT NOT NULL, [PreferredVendorStatus] [dbo].[Flag] NOT NULL, [ActiveFlag] [dbo].[Flag] NOT NULL, [PurchasingWebServiceURL] NVARCHAR (1024) NULL, [ModifiedDate] DATETIME NOT NULL, [PreferredVendor] BIT NOT NULL);

2. Faça o check in das alterações pendentes no branch Team1.

No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione a opção Check in pending changes. O diálogo Pending Changes sera exibido. (Figura 44)

Certifique-se de que todos os items estejam selecionados e clique em Check In.

Figura 44 Revisão das alterações pendentes para o branch HOL_Database-Team1

1. Faça alterações na tabela Purchasing.Vendor no branch Team2.

a. No Source Control Explorer, abra a solução a partir do branch HOL_Database-Team1.





b. Abra o arquivo Vendor.table.sql. Ele está localizado em AdventureWorksDB, AdventureWorksDB, Schema Objects, Schemas, Purchasing, Tables.

c. Altere a coluna PurchasingWebServiceURL e reduza o tamanho do tipo de dados de 1024 para 512 caracteres. O script resultante deve se parecer com o abaixo::

CREATE TABLE [Purchasing].[Vendor] ( [VendorID] INT IDENTITY (1, 1) NOT NULL, [AccountNumber] [dbo].[AccountNumber] NOT NULL, [Name] [dbo].[Name] NOT NULL, [CreditRating] TINYINT NOT NULL, [PreferredVendorStatus] [dbo].[Flag] NOT NULL, [ActiveFlag] [dbo].[Flag] NOT NULL, [PurchasingWebServiceURL] NVARCHAR (512) NULL, [ModifiedDate] DATETIME NOT NULL);

3. Faça o check in das alterações pendentes no branch Team2.

No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione Check in pending changes. O diálogo “pending changes” sera exibido. (Figura 45)

Certifique-se de que todos os itens estejam selecionados e clique em Check In.

Figura 45 Reveja as alterações pendentes para o branch HOL_Database-Team2





Passo 3: Faça o merge das mudanças do branch Team1 para o Main

Agora que nós fizemos alterações nos branches Team1 e Team2, nós iremos realizar o merge do conteúdo de volta para o branch main. Neste passo nós iremos nos concentrar no branch Team1.


1. No menu principal, clique em View e então clique em Team Explorer

8. No Team Explorer, vá até o source control no caminho $/HOL_DatabaseProjects/HOL_Database-Team1, clique com o botão direito no nó e selecione Merge. O Source Control Merge Wizard aparece. (Figura 46)






9. Após revisar a informação no wizard certificar-se de que o branch de origem é HOL_Database-Branch_Team1 e o branch de destino é o HOL_Database, clique em Next. (Figura 46)

10. Um diálogo de confirmação irá aparecer. Clique em Finish para iniciar a operação de merge. (Figura 47)

Figura 47 Merge confirmation dialog box

11. No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione Check in pending changes. O diálogo de alterações pendentes aparece. (Figura 48)

Certifique-se de que todos os itens selecionados e clique em Check In.

Figura 48 Faça o check in das alterações pendentes feitas durante a operação de merge





Passo 4: Faça o merge das mudanças do branch Team2 para o Main

Agora que nós fizemos as alterações nos branches Team1 e Team2, nós iremos realizar o merge do conteúdo de volta para o branch main. Neste passo nós iremos nos concentrar no branch Team2. Como nós já fizemos o check in das mudanças do branch Team1 nós precisaremos resolver os conflitos resultantes do processo de merge.


1. No menu principal, clique em View e então clique em Team Explorer.

2. No Team Explorer, vá até o source control no caminho $/HOL_DatabaseProjects/HOL_Database-Team2, clique com o botão direito no nó e selecione Merge. O Source Control Merge Wizard aparece. (Figura 49)






3. Após revisar a informação do wizard e certificar-se de que o branch de origem é o HOL_Database-Branch_Team2 e o branch de destino é o HOL_Database, clique em Next. (Figura 46)

4. Um diálogo de confirmação aparece na página Perform the merge operation. Clique em Finish para iniciar a operação de merge. (Figura 47)

Figura 50 Diálogo de confirmação de merge

5. A execução do merge irá gerar um conflito de merge, conforme mostrado na janela Pending Changes – Conflicts (Figura 51). Escolha a opção Merge changes in Merge Tool para que seja possível vizualizar os conflitos e encaminhar a resolução manualmente. O diálogo de resolução de conflitos será exibido. (Figura 52)

Figura 51 Conflitos de merge serão exibidos no diálogo Pending Changes - Conflicts





6. O diálogo de resolução de conflitos irá lhe mostrar as diferentes alterações realizadas. No lado esquerdo você verá o branch main HOL_Database que já contém as alterações do branch Team1, feitas através do merge no passo 3. No lado direito você verá as alterações que foram feitas no branch Team2. Embora a sugestão de merge já deva ter sido sugerida pela ferramenta, você pode clicar nas partes relevantes para informar ao visualizador de conflitos quais partes você de fato deseja mesclar.

Figura 52 Diálogo de resolução de conflitos

7. Se você ja selecionou as partes relevantes, o script na parte inferior da janela deverá estar como o trecho abaixo:

CREATE TABLE [Purchasing].[Vendor] ( [VendorID] INT IDENTITY (1, 1) NOT NULL, [AccountNumber] [dbo].[AccountNumber] NOT NULL, [Name] [dbo].[Name] NOT NULL, [CreditRating] TINYINT NOT NULL, [PreferredVendorStatus] [dbo].[Flag] NOT NULL, [ActiveFlag] [dbo].[Flag] NOT NULL, [PurchasingWebServiceURL] NVARCHAR (512) NULL, [ModifiedDate] DATETIME NOT NULL, [PreferredVendor] BIT NOT NULL);

8. No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione Check in pending changes. O diálogo Pending Changes deverá aparecer. (Figura 53)

Certifique-se de que todos os items estejam selecionados e clique em Check In.





Figura 53 Faça o check in das alterações pendentes feitas durante a operação de merge





Integrando Mudanças Externas com o Sistema de Projeto

Mantendo Linked Servers no Projeto de Banco de Dados do Visual Studio

Resumo

Neste cenário um banco de dados depende de informações que reside em um outro banco que está em uma instância diferente do SQL Server. Um linked server é creado para prover uma conexão comum para todas as queries que possivelmente acessem este banco de dados. O nome utilizado pelo projeto de banco de dados pode ser diferente entre os ambientes.

Objetivos do Cenário

Descreva como os objetos em um linked server são criados, utilizados e publicados em projetos de bancos de dados Manter a estrutura existente, bem como as validações de referência, mantendo a compilação do schema bem

sucedida.

Duração estiamada: 5 minutos

Passo 1: Criar dois novos projetos, um referenciando o outro

Crie um no projeto de banco de dados para ser referenciado

O projeto a seguir é o tipo de projeto que normalmente seria referenciado em outros projetos.

1. Abra o Visual Studio 2010.2. Clique em File, clique em New e então clique em Project. Você verá o diálogo mostrado na Figura 54.3. Especifique o nome do projeto como sendo ReferencedDatabase e um local para salvar os arquivos.4. Clique em OK para confirmar a criação do projeto.





Figura 54 Diálogo de criação de projetos de banco de dados


Crie uma nova tabela no projeto

1. Clique com o botão direito no projeto de banco de dados e selecione Add. Clique em Table. O diálogo Add New Item irá aparecer. (Figura 55)

Figura 55 Diálogo para adicionar um novo objeto

2. Adicione o seguinte script para definir a nova tabela:

CREATE TABLE [dbo].[ReferenceTable](

CustomerId INT,CustomerName VARCHAR(255)

)

Salve as alterações.

3. Compile projeto clicando com o botão direito no projeto de banco de dados no Solution Explorer e selecionando o item Build. Você irá visualizar o progresso do deployment na janela Output do Visual Studio. (Caso você não veja a





janela Output você poderá exibí-la através do menu principal. Clique em View e então clique em Output. Na janela Output você pode alterar a opção Show output from para Build).

O projeto irá compilar e um arquivo .dbschema será criado representando o schema do projeto. Anote o caminho do arquivo .dbschema a partir da janela Output, logo abaixo da linha contendo a mensagem Writing model to ReferencedDatabase.dbschema.

4. Feche o projeto. No menu principal, clique em File e então clique em Close solution.

Crie um no projeto de banco de dados para fazer referência ao projeto criado no passo anterior

O projeto abaixo é um projeto típico que normalmente faz referência a outros projetos.

5. Abra o Visual Studio 2010.6. Clique em File, clique em New e então clique em Project.7. Você verá o diálogo exibido conforme Figura 1 8. Especifique o nome do projeto como sendo ReferencingDatabase e um local para salvar os arquivos.9. Clique em OK para confirmar a criação do projeto.

Figure 56 Diálogo de criação de projetos de banco de dados


Crie uma referência para o projeto ReferencedDatabase

1. Clique com o botão direito sobre o projeto de banco de dados. Selecione Add e então clique em Add Database Reference. O diálogo Add Database Reference. (Figura 57)





Figura 57 Adicione uma referência para ReferencedDatabase

2. Clique no botão Browse para localizer o arquivo .dbschema referente ao banco de dados do projeto “ReferencedDatabase”.

Marque a opção Define server variables e digite o nome da variável para o nome do servidor como $(MyReferencedServer). Digite o valor MyLinkedServer (este será o nome do servidor linked server nos próximos passos).

Marque a opção Define database variable e digite o nome da variável para o nome do servidor como $(MyReferencedDatabase). Digite o valor ReferencedDatabase (este será o nome do banco de dados nos próximos passos)..

Clique em OK para fechar o diálogo Database Reference.

NOTAA opção “Update the existing schema object definitions” pode ser muito útil se você já desenvolveu um banco de dados que contém referências estáticas a um linked server ou em geral nomes compostos de 3 ou quatro partes. É útil inclusive para fazer engenharia reversa de um banco de dados existente. Esta opção irá Refatorar as existências existentes e torná-las configuráveis através destas variáveis.

Crie uma nova view no projeto que faz referência a tabela do projeto externo (referenciado)

1. Clique com o botão direito no projeto de banco de dados. Selecione Add e então clique em View. O diálogo Add New Item será exibido. (Figura 55)





Figura 58 Diálogo para adicionar uma nova view

2. Adicione o script abaixo para definir o schema da nova view:

CREATE VIEW [dbo].[ReferenceTable]ASSELECT CustomerId FROM[$(MyReferencedServer)].[$(MyReferencedDatabase)].dbo.ReferenceTable

Salve as alterações. Você deverá perceber que não há erros de compilação na janela Error List. (Se você não conseguir visualizar a janela Error você pode visualizá-la através do menu principal View, Error List).

3. Compile projeto clicando com o botão direito no projeto de banco de dados no Solution Explorer e selecionando o item Build. Você irá visualizar o progresso do deployment na janela Output do Visual Studio. (Caso você não veja a janela Output você poderá exibí-la através do menu principal. Clique em View e então clique em Output. Na janela Output você pode alterar a opção Show output from para Build).

4. Feche o projeto. No menu principal, clique em File e então clique em Close solution.

O objetivo com o linked server é criar um objeto que não será recriado em re-deploy de forma que erros e alertas de validação de referência não sejam gerados.





Movimentação Complexa de Dados

Resumo

Os cenários abaixo utilizarão a tarefa de adicionar uma coluna NOT NULL em uma tabela. Esta tarefa é simples mas dependendo do resultado desejado você pode encontrar uma série de problemas. Muitas abordagens irão mover ou renomear a tabela o que pode ter consequências para as chaves estrangeiras ou relacionamentos. Adicionar uma coluna NOT NULL irá cobrir muitos dos problemas que você terá ao alterar chaves estrangeiras entre tabelas.Nós utilizaremos uma estrutura de banco de dados simples para que possamos focar no comportamento da ferramenta sem maiores intereferências.

Este laboratório está dividio em quatro cenários O cenário 1 irá lhe mostrar como as mudanças são geralmente tratadas em um sistema de projeto e quais problemas

você pode encontrar quando faz deploy de mudanças para um banco de dados que contém dados. Os cenários de 2 a 4 irão sugerir abordagens para tratar estas mudanças, incluindo os prós e contras de cada situação.

Objetivos dos Cenários

Entendimento das três formas através das quais é possível integrar código customizado ao sistema de deployment. Balanceamento das necessidades de performance, gestão de fonts e migração complexa de dados sem comprometer

as funcionalidades do banco do dados.

Duração estimada: 2 horas

Cenário 1 – Movimentação Complexa de Dados – Comportamento Padrão para Edição de Desenvolvimento

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1

Local dos arquivos finais: C:\HOL\DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1_Answer

Qual é o comportamento padrão da edição de banco de dados? Existem alguns caminhos possíveis. Se a tabela estiver vazia um comando ALTER TABLE será gerado. Senão, será feita uma tentativa de mover os dados, realizar as alterações e devolver os dados a tabela.

O que acontece se a tabela possuir dados? O que acontece se a tabela possuir relacionamentos com chaves?

Neste cenário nós iremos preparar nosso exemplo e explorar o comportamento padrão da edição de banco de dados. Uma área para o início do laboratório é oferecida para servir de ponto de partida para o projeto. Copie este projeto para uma área de teste. Conforme for progredindo no laboratório, caso você trave em algum ponto, você poderá checar o projeto na área com o resultado final e revisar as diversas seções do laboratório.

Abra o projeto de exemplo

1. Abra a soluçãoa. Abra o Visual Studio 2010.





b. No menu principal clique em File, clique em Open project e então vá até o projeto localizado em C:\HOL\DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1. Abra o arquivo SimpleDatabase.sln.

Se você navegar até o projeto SimpleDatabase (Selecione a pasta Schema Objects/Schemas/Dbo/Tables sob o projeto) você irá perceber que ele descreve uma estrutura de banco de dados conforme abaixo. (Figura 59)

Figura 59 Diagrama de ER dos objetos incluídos no schema

Faça o Build e Deploy da solução

1. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Properties.2. Defina a opção Deploy action para Create a deployment script (.sql) and deploy to the database.3. Especifique a conexão SQL para a instância de banco de dados de destino clicanco em Edit. Digite “.” no campo

server name e SimpleDatabase para o nome do banco de dados.4. Verifique se as opções estão como na Figura 60.





Figura 60 Opções de Deployment para o projeto SimpleDatabase

5. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Deploy.

Agora que temos um banco de dados vazio nós podemos explorar o comportamento da edição do banco de dados conforme formos fazendo as mudanças. Nós iremos dedicar um bom tempo avaliando a saída da engine de deployment, logo iremos alterar a ação de Deploy para que o script seja apenas gerado.

Faça alterações no projeto e avalie o script de deployment

1. Defina a ação de Deploya. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Properties.b. Altere o campo Deploy action para Create a deployment script (.sql).

2. Adicione uma coluna NOT NULL na tabela Companiesa. Abra o arquivo Companies.table.sql expandindo a pasta Schema Objects, Schemas, dbo, Tables.b. Adicione o atributo NOT NULL na coluna LanguageLocale. O script deve ficar igual ao abaixo:

CREATE TABLE [dbo].[Companies](

Id int NOT NULL, ParentId int NULL,Name nvarchar(100) NOT NULL,LanguageLocale nvarchar(5) NOT NULL

)

3. Faça o deploy do projetoa. Clique com o botão direito na solução de banco de dados e clique em Deploy para fazer o deploy para o banco

de dados especificado. Você verá o progresso do deployment na janela Output do Visual Studio. Ao final da saída registrada na janela output você verá uma seção Deployment script generated to: que contém o caminho para o arquivo .sql contendo as instruções de alteração do banco de dados.

b. Abra o arquivo .sql gerado localizado no caminho indicado na janela output.





NOTAHá dois comportamentos que precisamos notar: A engine detecta que você está adicionando uma coluna NOT NULL sem DEFAULT e exibe um alerta de que o deployment irá falhar caso já existam dados na tabela. O alerta aparece na janela Output conforme a seguir: "Warning SQL01270: The column LanguageLocale on table [dbo].[Companies] must be changed from NULL to NOT NULL. If the table contains data,..." O comportamento padrão é gerar um script com a instrução ALTER.

Este comportamento é esperado, mas não é interessante uma vez que não temos nenhum dado na tabela. Vamos então popular as tabelas com dados para que seja possível visualizar o que acontece neste caso.

Popule a tabela com dados de exemplo

4. Remova a coluna LanguageLocalea. Abra o arquivo Companies.table.sql expandindo a pasta Schema Objects, Schemas, dbo, Tables.b. Remova a coluna LanguageLocale deletando o código relevante do script. O resultado deve ser como

abaixo:

CREATE TABLE [dbo].[Companies](

Id int NOT NULL, ParentId int NULL,Name nvarchar(100) NOT NULL

)

c. Certifique-se de que o a ação de deployment esteja configurada para fazer o deploy. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e clique em Properties. Na aba Deploy, o campo Deploy action deve ser alterado para Create a deployment script (.sql) and deploy to the database.

d. Clique com o botão direito na solução e selecione Deploy para publicar as alterações no banco de dados especificado.

5. Gere dados de exemplo

a. No Solution Explorer, abra a pasta Data Generation Plans.b. Dê um duplo-clique no arquivo SampleData.dgen. O plano de geração de dados sera aberto e você irá

visualizar uma prévia dos dados que serão gerados. (Figura 61)

NOTAVocê pode perceber um problema com a mensagem "No Coercible Output" ao tentar definir os valores para cidade e estado. Isso se deve ao caminho divergente definido para esta conexão. Para corrigir o problema, clique nas propriedades para cada campo com o problema e edite a propriedade Connection Information para: Dsn=Excel Files;dbq=C:\HOL\DATABASEPROJECTGUIDANCE\INTEGRATION WITH CUSTOM CODE AND EXTERNAL CHANGES\COMPLEXDATAMOVEMENT\Scenario1_Answer\SolutionItems\USStatesAndCities.xlsx;defaultdir=C:\HOL\DATABASEPROJECTGUIDANCE\INTEGRATION WITH CUSTOM CODE AND EXTERNAL CHANGES\COMPLEXDATAMOVEMENT\Scenario1_Answer\SolutionItems;driverid=1046;maxbuffersize=2048;pagetimeout=5System.Data.OdbcFalse Caso tenha dificuldades para corrigir este problema, você pode prosseguir com os passos do laboratório, que continuarão funcionando. A diferença é que os dados exibidos não irão corresponder ao que é exibido em





alguns passos deste documento. Se a prévia não for exibida corretamente, clique com o botão direito na lista de colunas no alto e selecione “Preview data generation”.

Figura 61 Janela com prévia da geração dos dados de exemplo

c. Pressione F5 para gerar os dados.d. Selecione o banco de dados SimpleDatabase conforme mostrado na Figura 62.

Figura 62 Diálogo para selecionar o banco de dados onde serão gerados os dados

e. Clique em Yes para confirmar a deleção dos dados existentes e a geração dos novos dados. (Figure 63)

Figure 63 Dialog box to check if data has to be first deleted Propague as mudanças com os dados de exemplo inseridos no banco de dados





Agora que temos dados no banco de dados vamos ver o que acontece quando executamos o deploy com a coluna NOT NULL.

1. Defina ação de deploy.a. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Properties.b. Altere o valor do campo Deploy action para Create a deployment script (.sql).

2. Adicione uma coluna NOT NULL na tabela Companiesa. Abra o arquivo Customers.table.sql expandindo a pasta Schema Objects, Schemas, dbo, Tables.b. Adicione a coluna LanguageLocale novamente com o atributo NOT NULL. O script resultante deve estar

como abaixo:

CREATE TABLE [dbo].[Customers](

Id int NOT NULL, CompanyId int NOT NULL,LanguageLocale nvarchar(5) NOT NULL

)



b. Abra o arquivo .sql gerado localizado no caminho indicado na janela output.

CONCLUSÃO

Você irá perceber que o deployment falha porque a engine de deployment não é capaz de determinar o que fazer com os dados existentes uma vez que não há um valor default especificado para a nova coluna. Você irá obter a mesma informação durante o deployment:

Warning SQL01269: The column [dbo].[Customers].[LanguageLocale] on table [dbo].[Customers] must be added, but the column has no default value and does not allow NULL values. If the table contains data, the ALTER script will not work. To avoid this issue, you must add a default value to the column or mark it as allowing NULL values.

Isso significa que o seguinte comando falharia no caso de haverem dados na tabela:





Cenário 2 – Movimentação Complexa de Dados – Engana engine de deployment (Enfraquece a experiência através da IDE, quebra o SCC como mastre, e gera uma desvantagem de performance)

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1_Answer


Estamos empacados? Não. Apenas precisamos eliminar a ambiguidade de forma que a deployment engine possa fazer seu trabalho. A primeira ideia é adicionar um valor DEFAULT ao campo e removê-lo após o fato, no momento adequado.

Adicione uma constraint DEFAULT na tabela

1. Adicione uma Constraint DEFAULT na tabela Companies

a. Abra a pasta Schema Objects/Schemas/dbo/Constraints.b. Clique com o botão direito na pasta Constraints e clique em Add e depois em New Item.c. Escolha o modelo referente a Default Constraint e dê o nome de DC_Companies_LanguageLocal. Clique em

OK para fechar o wizard.d. Quando o script com o modelo default for aberto, troque o a definição do schema para o script abaixo:

ALTER TABLE [dbo].[Companies] ADD CONSTRAINT [DC_Companies_LanguageLocale] DEFAULT 'EN-US' FOR [LanguageLocale]



b. Abra o arquivo .sql gerado localizado no caminho indicado na janela output.c. Você irá ver o seguinte script de alteração com a constraint default adicionada:

Agora o deployment será bem sucedido. Mas por outro lado o banco de dados não está no estado que desejamos. Ele tem um DEFAULT em coluna que nós não queremos. Trata-se apenas de uma conveniência para conseguirmos realizar o deploy. Adicionalmente precisamos considerar que os dados após o deployment está errados, uma vez que não faz sentido que todos os registros tenham o valor ‘EN-US’ na nova coluna. Para resolver estes problemas utilizaremos um PostDeployment script.

Remova a constraint default no script que é executado após deployment

1. Adicione um PostDeployment script para alterar os dados.

a. No Solution Explorer, vá até a pasta Scripts/PostDeployment no projeto de banco de dados, clique com o botão direito e selecione Add e então em Script.

b. Dê o nome PopulateLanguageLocale.sql para o script e clique em OK.





c. Após o script ser aberto, substitua o texto pelo seguinte script:

UPDATE [dbo].[Companies]SET [LanguageLocale] = 'ES-MX'FROM [dbo].[Companies] COINNER JOIN [dbo].Addresses ADDR ON CO.Id = ADDR.CompanyIdWHERE ADDR.State IN ('COLORADO',

'CALIFORNIA', 'UTAH', 'ARIZONA', 'NEW MEXICO', 'TEXAS', 'FLORIDA', 'NEVADA')

NOTACaso haja qualquer problema com o passo de geração de dados este comando não irá alterar nenhum registro.

2. Adicione outro PostDeployment script para excluir a atributo DEFAULTa. No Solution Explorer, no projeto de banco de dados, vá até a pasta Scripts/PostDeployment, clique em Add

e então em clique em Script.b. Dê o nome ManageObjects.sql para o script e clique em OK.c. Após o script ser aberto, substitua o texto pelo seguinte script:

IF EXISTS (SELECT * FROM sys.sysobjects WHERE NAME = 'DC_Companies_LanguageLocale')BEGIN

ALTER TABLE [dbo].[Companies] DROP CONSTRAINT [DC_Companies_LanguageLocale];END

3. Inclua os scripts no arquivo Script.PostDeployment.sqla. No Solution Explorer, navegue até a pasta Scripts/PostDeployment no projeto de banco de dados e abra o

arquivo Script.PostDeployment.sql.b. Inclua os arquivos PopulateLanguageLocale.sql e ManageObjects.sql adicionando as seguintes linhas ao

final do script:

:r .\PopulateLanguageLocal.sql:r .\ManageObjects.sql

Faça o deploy das mudanças para o banco de dados clicando com botão direito na solução de banco de dados e selecionando Deploy para publicar as alterações para o banco de dados especificado.

CONCLUSÃO

Esta abordagem quebra boas práticas e resulta em dois problemas:

O primeiro problema é que o controle de código-fonte não fica sincronizado com o banco de dados alvo. Quando você exclui o arquivo Companies.LanguageLocale.defconst.sql do projeto? Se você executar diversas iterações durante o desenvolvimento você corre o risco de esquecer de atualizar o controle de código-fonte. Você pode adicionar alguns alvos customizados no seu arquivo de projeto para excluir e incluir este arquivo cada vez que faz o deploy. Você pode ainda executar esta tarefa de forma manual. De uma forma ou de outra, o efeito é que você acaba adicionando esforço de manutenção do projeto quando o desejável é poder focar nas funcionalidades.

O Segundo problema é o impacto potencial na performance do deployment. As instruções DEFAULT e UPDATE resultam em consume de disco desnecessário. Tente rodar isso em tabela com 10 milhões de linhas...





Cenário 3 – Movimentação Complexa de Dados – Resolva o Problema de Performance (Não utilize a deployment engine, SCC torna-se o mestre)



Resolver problemas de performance, na maioria dos casos, é prioridade máxima. Tratando isso também poderemos resolver o problema de que o controle de código-fonte não corresponde a verdade (versão mestra), ou seja, fica fora de sincronia com o banco de dados.

1. Abra a soluçãoa. Abra o Visual Studio 2010.b. No menu principal clique em File e então clique em Open project. Vá para o projeto localizado em C:\HOL\

DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1_Answer e abra o arquivo SimpleDatabase.sln.

2. Faça o deploy do banco de dados clicando com o botão direito na solução Database e selecionando Deploy para publicá-la no banco de dados especificado.

3. Adicione outro script de PreDeployment para mover os dados para um local temporário. a. No Solution Explorer, vá até o projeto de banco de dados e clique com o botão direito na pasta

Scripts/PreDeployment, clique em Add e então em Script.b. Dê o nome de CopyCompanies.sql para este script e clique em OK.c. Após o script ter sido aberto, substitua o conteúdo pelo script abaixo:

CREATE TABLE [dbo].[tmp_ms_xx_Companies] ( [Id] INT NOT NULL, [ParentId] INT NULL, [Name] NVARCHAR (100) NOT NULL, [LanguageLocale] NVARCHAR (5) NOT NULL);

ALTER TABLE [dbo].[tmp_ms_xx_Companies] ADD CONSTRAINT [tmp_ms_xx_clusteredindex_PK_Companies_Id] PRIMARY KEY CLUSTERED ([Id] ASC)

WITH (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF, STATISTICS_NORECOMPUTE = OFF);

4. Movo os dados. No arquivo CopyCompanies.sql, acrescente o código a seguir:

IF EXISTS (SELECT TOP 1 1 FROM [dbo].[Companies]) BEGIN INSERT INTO [dbo].[tmp_ms_xx_Companies] ([Id], [ParentId], [Name], [LanguageLocale]) SELECT Com.[Id], Com.[ParentId], Com.[Name],

[LanguageLocale] = CASE ADDR.[State] WHEN ('DISTRICT OF COLUMBIA') THEN 'ES-MX'

WHEN ('COLORADO') THEN 'ES-MX'WHEN ('KENTUCKY') THEN 'ES-MX'WHEN ('ARIZONA') THEN 'ES-MX'WHEN ('TEXAS') THEN 'ES-MX'WHEN ('NEW MEXICO') THEN 'ES-MX'WHEN ('IDAHO') THEN 'ES-MX'WHEN ('ILLINOIS') THEN 'ES-MX'WHEN ('MAINE') THEN 'FR-FR'WHEN ('MINNESOTA') THEN 'FR-CA'WHEN ('ARKANSAS') THEN 'FR-CA'





ENDFROM [dbo].Addresses ADDRINNER JOIN [dbo].[Companies] ComON Com.Id = ADDR.CompanyId

END

5. Exclua o conteúdo da tabela Companies. Aqui é o ponto onde as coisas começam a ficar complicadas. Nós temos que lidar com uma boa quantidade de relacionamentos. Você também notará que nós não iremos apagar a tabela. Ao invés disso, nós iremos truncá-la. A deployment engine espera que a tabela esteja presente e por isso gera um comando ALTER. Porém, nós não poderemos truncar a tabela sem excluir os relacionamentos.

a. No script CopyCompanies.sql adicione o seguinte script:

PRINT N'Dropping FK_CustomersCompanyId_CompaniesId...';GOALTER TABLE [dbo].[Customers] DROP CONSTRAINT [FK_CustomersCompanyId_CompaniesId];GOPRINT N'Dropping FK_CompanyId_Id...';GOALTER TABLE [dbo].[Addresses] DROP CONSTRAINT [FK_CompanyId_Id];GOPRINT N'Dropping FK_CompanyId_CompanyParentId...';GOALTER TABLE [dbo].[Companies] DROP CONSTRAINT [FK_CompanyId_CompanyParentId];GOPRINT N'Truncate table [dbo].[Companies]...';GOTRUNCATE TABLE [dbo].[Companies];

6. Devolva os dados à tabela Companies e recrie os relacionamentos

d. No Solution Explorer, vá até o projeto de banco de dados e clique com o botão direito na pasta Scripts/PostDeployment, clique em Add e então em Script.

e. Dê o nome de MoveCompanies.sql para o script e clique em OK.f. Após o script ter sido aberto, substitua o texto com o seguinte script:

INSERT INTO [dbo].[Companies] ([Id], [ParentId], [Name], [LanguageLocale])SELECT [Id], [ParentId], [Name], [LanguageLocale] FROM [dbo].[tmp_ms_xx_Companies]

SET IDENTITY_INSERT [dbo].[Companies] ON

PRINT N'Creating FK_CustomersCompanyId_CompaniesId...';GOALTER TABLE [dbo].[Customers] WITH NOCHECK ADD CONSTRAINT [FK_CustomersCompanyId_CompaniesId]

FOREIGN KEY ([CompanyId]) REFERENCES [dbo].[Companies] ([Id]) ON DELETE NO ACTION ON UPDATE NO ACTION;GOPRINT N'Creating FK_CompanyId_Id...';GOALTER TABLE [dbo].[Addresses] WITH NOCHECK ADD CONSTRAINT [FK_CompanyId_Id]

FOREIGN KEY ([CompanyId]) REFERENCES [dbo].[Companies] ([Id]) ON DELETE NO ACTION ON UPDATE NO ACTION;GOPRINT N'Creating FK_CompanyId_CompanyParentId...';GOALTER TABLE [dbo].[Companies] WITH NOCHECK ADD CONSTRAINT [FK_CompanyId_CompanyParentId]

FOREIGN KEY ([ParentId]) REFERENCES [dbo].[Companies] ([Id]) ON DELETE NO ACTION ON UPDATE NO ACTION;





GO

7. Inclua o script no arquivo Script.PreDeployment.sqlg. No Solution Explorer, no projeto de banco e dados, vá até a pasta Scripts/PreDeployment e abra o aquivo

Script.PreDeployment.sql.h. Inclua o script CopyCompanies.sql adicionando a seguinte linha ao final do script:

:r .\ CopyCompanies.sql

8. Inclua o script no arquivo Script.PostDeployment.sqli. No Solution Explorer, no projeto de banco e dados, vá até a pasta Scripts/PostDeployment e abra o aquivo

Script.PostDeployment.sql.j. Inclua o script MoveCompanies.sql adicionando a seguinte linha ao final do script:

:r .\MoveCompanies.sql


CONCLUSÃO

Neste cenário obtivemos uma abordagem que nos dá controle sobre o movimento dos dados de forma que melhoramos a performance no melhor nível possível. Desta forma, não precisamos após o deployment nos preocupar com a gestão de arquivos no nosso projeto. Porém, nós violamos o princípio de Gerenciamento de Objetos. Este cenário tem um modelo de dados relativamente simples e mesmo assim temos uma boa quantidade de objetos para gerenciar durante o deployment.Essa abordagem aniquila as melhores inovações que a deployment engine trás para edição do banco de dados.





Cenário 4 – Movimentação Complexa de Dados –Integrar a Deployment Engine / Tratar conversão de dados externamente ao proejto



Agora que resolvemos o problema de performance, mantivemos a experiência na IDE objetiva e mantivemos o controle de versão como sendo o mestre; Como podemos evitar o gerenciamento de objetos durante o deployment?

Para isso precisamos, fora do sistema de projeto, alterar o estado do banco de dados antes de rodar o processo de deployment. Se nós rodarmos um script .sql a partir da linha de comando antes de executarmos o deployment podemos alterar o

estado do banco de dados. A deployment engine irá gerar o script baseado no estado depois da nossa alteração via linha de comando. Podemos

gerar ainda um Post Deployment script para recolocar os dados no banco. Na maioria dos casos esta opção nos permite evitar o problema de gerenciamento de objetos. Foreign keys são uma

exceção.

1. Abra a soluçãoa. Inicie o Visual Studio 2010.b. No menu principal, clique em File e então em Open project. Vá até a pasta C:\HOL\

DatabaseProjectGuidance\Integration with Custom Code and External Changes\ComplexDataMovement\Scenario1_Answer e abra a solução SimpleDatabase.sln.


3. Em script externo mova os dados para uma tabela temporário em TempDB.

NOTAHá três partes neste script.

Criar um banco de dados de conversão Copiar os dados Excluir os relacionamentos de foreign keys.

Como estamos executando o script a partir da linha de comando com o SqlCmd nós corremos o risco de que o servidor não possua sessões abertas quando o script é finalizado. Por este motivo não utilizaremos o TempDb uma vez que uma tabela temporária global seria destruída quando a última sessão aberta for finalizada.

a. No Solution Explorer, vá até o projeto de banco de dados e clique com o botão direito na pasta Scripts/PreDeployment, clique em Add e então em Script.

b. Dê o nome CopyCompaniesTempDB.sql para o script e clique em OK.c. Após o script ter sido aberto, substitua o conteúdo pelo script abaixo:

USE [master]GO

PRINT N'Creating ConversionDB...'GOCREATE DATABASE [ConversionDB]




C:\\DatabaseProjectGuidance\\HOL\\Integration with Custom Code and External Changes\\ComplexDataMovement\\Scenario4_Answer

C:\\DatabaseProjectGuidance\\HOL\\Integration with Custom Code and External Changes\\ComplexDataMovement\\Scenario4_Answer


GOEXECUTE sp_dbcmptlevel [ConversionDB], 100;

USE [ConversionDB]GO

PRINT N'Starting moving table [dbo].[Companies]...';CREATE TABLE [dbo].[Companies] ( [Id] INT NOT NULL, [ParentId] INT NULL, [Name] NVARCHAR (100) NOT NULL);GO

USE [SimpleDatabase]GO

IF EXISTS (SELECT TOP 1 1 FROM [dbo].[Companies]) BEGIN INSERT INTO [ConversionDB].[dbo].[Companies] ([Id], [ParentId], [Name]) SELECT [Id], [ParentId], [Name]

FROM [dbo].[Companies] END

PRINT N'Dropping FK_CustomersCompanyId_CompaniesId...';GOALTER TABLE [dbo].[Customers] DROP CONSTRAINT [FK_CustomersCompanyId_CompaniesId];GOPRINT N'Dropping FK_CompanyId_Id...';GOALTER TABLE [dbo].[Addresses] DROP CONSTRAINT [FK_CompanyId_Id];GOPRINT N'Dropping FK_CompanyId_CompanyParentId...';GOALTER TABLE [dbo].[Companies] DROP CONSTRAINT [FK_CompanyId_CompanyParentId];GOPRINT N'Dropping table [dbo].[Companies]...';GOTRUNCATE TABLE [dbo].[Companies];GO





4. Habilite a verificação e criação de constraints.a. No Solution Explorer, clique com o botão direito no nó de projeto e selecione Properties.b. Nas propriedades do projeto, vá até a aba Deploy.c. Clique em Edit ao lado de Deployment configuration file settings.d. Marque a opção CheckNewConstraints. (Figura 64)

Figura 64 Marque a opção "CheckNewConstraints"

NOVA FUNCIONALIDADE

5. Se nós executarmos este script antes da execução do deploy a tabela Companies não possuirá dados e as foreign keys será excluídas. A deployment engine irá alterar (ALTER) a tabela Companies e recriar as foreign keys. Esta é uma nova funcionalidade para projetos de banco de dados do Visual Studio 2010. (Figura 64)

Quando esta opção é habilitada, a deployment engine irá criar uma nova chave ou constraint, mas com a opção NO CHECK. Ao final da execução do script de deploymen, após a execução do script de Post-Deployment, será criado um bloco de script com comandos para habilitar as constraints. Isto nos permite deixar a deployment engine a continuar gerenciando a criação de chaves e constraints enquanto move os dados através do script de Post-Deployment.





6. Agora temos que mover os dados de volta para o banco através de um script de post deployment.

a. No Solution Explorer, vá até o projeto de banco de dados e clique com o botão direito na pasta Scripts/PostDeployment, clique em Add e então em Script.

b. Dê o nome MoveCompaniesTempDB.sql para o script e clique em OK.c. Após o script ter sido aberto, substitua o conteúdo pelo script abaixo:

PRINT N'Converting Companies Data...'GO

INSERT INTO [dbo].[Companies] ([Id], [ParentId], [Name], [LanguageLocale])SELECT CO.[Id], CO.[ParentId], CO.[Name], [LanguageLocale] = CASE ADDR.[State]

WHEN ('NEW MEXICO') THEN 'ES-MX'WHEN ('COLORADO') THEN 'ES-MX'WHEN ('CALIFORNIA') THEN 'ES-MX'WHEN ('ARIZONA') THEN 'ES-MX'WHEN ('TEXAS') THEN 'ES-MX'WHEN ('FLORIDA') THEN 'ES-MX'WHEN ('NEVADA') THEN 'ES-MX'WHEN ('UTAH') THEN 'ES-MX'WHEN ('WASHINGTON') THEN 'FR-FR'WHEN ('MINNESOTA') THEN 'FR-CA'WHEN ('MAINE') THEN 'FR-CA'ELSE 'EN-US'

ENDFROM [ConversionDB].[dbo].[Companies] COINNER JOIN (SELECT DISTINCT CompanyId,

MAX(State) AS [State] FROM [dbo].[Addresses] GROUP BY CompanyId) ADDR ON ADDR.CompanyId = CO.Id

ORDER BY CO.[Id] ASC;

GO

USE [master]GO

PRINT N'Dropping ConversionDB...'GODROP DATABASE [ConversionDB]GO

d. No Solution Explorer, no projeto de banco e dados, vá até a pasta Scripts/PostDeployment e abra o aquivo Script.PostDeployment.sql.

e. Inclua o script MoveCompaniesTempDB.sql adicionando a seguinte linha ao final:

:r .\MoveCompaniesTempDB.sql

7. Agora precisamos garantir uma boa experiência na IDE. Para atingir esse objetivo teremos que alterar as opções de build do projeto. O arquivo *.dbproj importa uma série de alvos que definem as tarefas de build e deploy. Elas nos oferecem o gancho necessário para as ações de pre e post deployment.

a. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Unload Project.b. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Edit

SimpleDatabase.dbproj.





RECOMENDAÇÃO

Os arquivos de projeto são basedos em XML e podem ser “bagunçados” facilmente. Se você não está familiarizado com o processo de edição dos arquivos de projeto, sugerimos que você crie uma cópia do arquivo por segurança antes de editá-lo.

c. Tudo que nós precisamos fazer é definir uma propriedade especial para a linha de comando que iremos executar.

d. Adicione o código a seguir após as definições de PropertyGroup para as configurações de Release e Debug conforme o script abaixo: <PropertyGroup> <PreDeployEvent>sqlcmd -S localhost –I ..\..\Scripts\Pre-Deployment\CopyCompaniesTempDB.sql</PreDeployEvent> </PropertyGroup>

e. No Solution Explorer, clique com o botão direito no projeto SimpleDatabase e selecione Reload Project.f. Após o projeto ter sido recarregado, clique com o botão direito no projeto SimpleDatabase e selecione

Deploy.

NOTANa janela output, você verá que o comando é chamado antes de qualquer outro script de deployment e que o texto de debug será redirecionado para a linha de comando, e em consequência para a janela output. Isto nos dará a chance de executar os procedimentos de preparação antes que a deployment engine principal seja executada.

CONCLUSÃO

Neste cenário final nós apresentamos uma abordagem que preserva a funcionalidade da deployment engine e nos dá controle sobre a movimentação dos dados com boa performance. Esta abordagem evita que seja necessário realizar o gerencimamento dos objetos nos scripts de pre e post deployment. Além disso, preserva a experiência da IDE, mantém o controle de versão sincronizado como versão mestra e nos dá controle sobre o processo de conversão de dados e seu desempenho.





Automação de Build e Deploy com Projetos de Banco de Dados no Visual Studio

Integração WiX com Deployment de Banco de Dados

Resumo

O VSDBCMD faz um bom trabalho ao realizar deployments de banco de dado, sendo relativamente simples customizar o processo através de scripts na ferramenta de edição de sua preferência. Caso seja necessário uma experiência de instalação mais completa você provavelmente deve utilizar o Windows Installer. O Windows Installer oferece os benefícios de empacotamento de todos os artefatos desenvolvidos, como código-fonte e schemas de banco de dados juntos, versionando os seus releases, tornando-os detectáveis via WMI/MOM, executar checagem de pré-requisitos antes da instalação e tratamento e configuração de ambiente relacionadas ao seu banco de dados. O Windows Installer provê ainda o tratamento de erros e a definição de um workflow para o processo de setup.

Nas páginas a seguir nós iremos guiá-lo através de um cenário avançado. Mas antes de começarmos devemos mencionar que o Windows Installer XML (WiX) é uma linguagem XML para criar arquivos de instalação do tipo *. msi. Este cenário não é um tutorial de WiX. Ao invés disso, focamos nos pontos de integração entre projetos de banco de dados e o WiX. Caso você não esteja familiarizado com o Wix e com o SDK do Windows Installer, recomendamos que execute um dos tutoriais online disponíveis antes de executar este laboratório. Alex Shevchuk publicou um tutorial excelente3 referente à WiX e Windows Installer.

Para este exemplo nós iremos utilizar projetos de banco de dados simples, uma vez que o tamanho e a complexidade do schema do projeto não se mostra relevante para os procedimentos de instalação. A estrutura da solução e a interação entre os difrentes tipos de projetos são mais relevantes para este caso. Nós iremos explorar todos as opções com o mínimo de complexidade necessária para que você se concentre na compreensão do funcionamento do WiX. Os projetos a seguir serão utilizados nos laboratórios para guiá-lo nesta intenção:

Customers é um banco de dados simples com algumas tabelas, views e stored procedures. Sales é um banco de dados simples para registro de pedidos que faz referência o banco de dados Customers. CustomerServer é um projeto do tipo server que gerencia linked servers e tarefas agendadas do SQL Agent. CustomersCLR é um proejto do tipo SqlCLR que definie alguns tipos customizados para o banco de dados Customers. Ambos os bancos Sales e Customers fazem referência para objetos de sistema e consequentemente ao

master.dbschema.

3 http://blogs.technet.com/alexshev/pages/from-msi-to-wix.aspx





Abaixo uma lista rápida dos pontos de integração que serão importantes no momento de fazer o empacotamento da instalação.

O master.dbschema precisa fazer parte da instalação ou você correrá o risco de que o VSDBCMD falhe. O Customers.dbschema precisa fazer parte da instalação do banco de dados Sales pelo mesmo motivo anterior. O banco de dados CustomersServer precisa ser instalado antes do banco de dados Customers. O banco de dados

Customers precisa ser instalado antes do banco de dados Sales. É necessário habilitar o suporte a CLR no banco CustomersServer que pertence a um Server Project ao invés de um Database Project.

Antes de realizarmos o deployment do projeto de banco de dados CustomerServer será necessário parar o serviço do SQLAgent e depois reiniciá-lo. Evitaremos criar um job SQL que faça referência a um banco de dados não existente, o que falharia o job durante sua execução.

Os bancos de dados Customers e Sales precisam expor seus caminho para dados e logs, de forma que possam ser definidos durante a instalação.

Figura 65 Diagrama de dependência para o processo de deployment





Em uma visão de alto nível, WiX cria um instalador que faz os seguinte:

Como usuário seu papel principal é popular as variáveis do SqlCmdVar.

Figura 66 Exemplo para mapeamento das propriedades do MSI para as SQLCmdVars

Após a solução básica e o instalador do WiX estarem prontos, a maior parte do trabalho é configurar o mapeamento das variáveis SqlCmdVars para propriedades do MSI.

Pré-requisitos

Para trabalhar com os projetos instalados (.wixprj) você vai precisar instalar o Windows Installer XML Toolset 3.5. Como trata-se de um projeto do Codeplex, você pode fazer o download através do site do Codeplex em Windows Installer XML (WiX) toolset.4 Se você estiver utilizando o HOL pré-instalado, o toolset já estará instalado na máquina. Também está disponível na sua máquina em C:\HOL\Prerequisite Software\Prerequisite\Wix35.msi.

4 http://wix.sourceforge.net/



Empacota os arquivos

Reune os parâmetros de

usuário

Copia os arquivos

Realiza alterações no

registro

Executa o VSDBCMD


http://wix.sourceforge.net/

http://wix.sourceforge.net/



Saber como utilizar as funcionalidades do Wix para fazer deploy de banco de dadoso Customizar a interface do instaladoro Customizar sequências de instalaçõeso Incluir redistribuíveis para o deployment do banco de dados


Passo 1: Estruturando a solução

1. Inicie o Visual Studio 2010.2. Abra a solução. No menu principal clique em File e então clique em Open project. Vá para o camimnho em C:\

HOL\DatabaseProjectGuidance\BuildAndDeploy\WiXDBProSample. 3. Abra o aqrquivo de solução WiXDBProSample.sln.

IMPORTANTE

Se você receber um erro alertando que o projeto .wixproj não pode ser aberto porque o tipo de projeto não é suportado, você provavelmente não possui o Windows Installer XML Toolset 3.5 instalado. Dê uma olhada na seção de pré-requisitos para obter instruções de como instalar o toolset.

Figura 67 Mensagem de erro caso você não possua o WiX installer toolset instalado

A solução tem uma estrutura específica. Esta estrutura irá auxiliá-lo a manter a rastreabilidade às referências de arquivo no seu projeto WiX. A estrutura importante está na pasta BuildSupportFiles que abriga todos os redistribuíveis do VsDbCmd. Por padrão, estes redistribuíveis são instalados pelo instalador do Visual Studio 2010 em $(VisualStudioInstallDir)\VSTSDB\Deploy.

Esta solução contém um projeto do tipo server e um do tipo CLR. O projeto Sales faz referência ao projeto Customers que por sua vez faz referência ao projeto CustomersCLR. Ambos os bancos de dados são publicados no mesmo servidor representado por CustomerServer. Nós podemos explorar uma série de cenários de instalação através desta solução. O que não está coberto são os cenários envolvendo projetos parciais e projetos compostos. Você pode ter uma visão geral do projeto na Figura 68.





Figura 68 Visão geral da solução do projeto

1. O projeto de instalação consiste de diversos arquivos, mostrados na Figura 69.

Figura 69 Visão geral do projeto de instalação resultante

a. A maior parte das funcionalidades do instalador estão no arquivo Product.wxs. b. Os arquivos na pasta Common e Databases são os arquivos os quais precisamos empacotar e instalar. c. Os arquivos na pasta UI definem a interface de usuário.d. Os arquivos em Resources são arquivos de apoio.e. O arquivo Sequences.wxi define a ordem na qual ações especiais devem ocorrer.

2. Faça referência aos projetos dependentes no projeto Setup. Quando fazemos referência a um projeto a partir de um projeto Wix é possível acessar o diretório desse projeto referenciado. Essa característica torna o gerenciamento de arquivos mais simples.

a. No Solution Explorer, localize o projeto com o nome Setup. Clique com o botão direito na pasta References e selecione Add reference. O diálogo Add Reference será exibido (Figura 70).





Figura 70 Diálogo Add Reference para os projetos dependentes

b. Selecione todos os projetos exceto o projeto CustomersCLR. Como o projeto Customers faz referência ao projeto CustomersCLR o assembly .dll correspondente será copiado no diretório de destino do projeto Customers.

c. Clique em Add para adicionar as referências e cliquem em OK para aplicar as mudanças e fechar o diálogo.

3. Após definir as referências de projeto você poderá fazer referência aos arquivos de saída dos projetos.

a. Projetos de banco de dados e projetos de servidor geram a saída de um build para a pasta \sql\$(configuration), onde $(configuration) define a configuração de build utilizada, por exemplo, Debug ou release. (Figura 71) Você pode exibir os arquivos e pastas na estrutura de pastas que não estão sob controle do projeto clicando no ícone Show all files no topo do Solution Explorer.





Figura 71 Pasta de saída dos artefatos resultantes do build

b. Estes são os arquivos que iremos publicar utilizando o VsDbCmd. Para fazer referências a arquivos que estão em projetos referenciados utilizamos a seguinte forma:

Source="$(var.Customers.TargetDir)Customers.dbschema"

Quando fazemos referência a um projeto o WiX automaticamente criar uma variável var.<ProjectName>. A partir daí é possível utilizar macros padrão do MSBuild como TargetDir, ProjectDir, SolutionDir, etc.




Passo 2: Criando a Informação da Aplicação

O Windows Installer provê um banco de dados das aplicações instaladas na máquina chamado ARP (Add Remove Programs). Este é um ótimo mecanismo para gerenciamento de do processo de instalação. Se todos os seus deployments forem feitos através do Windows Installer, você pode utilizar este banco de dados para determinar qual é a versão instalada da sua aplicação de banco de dados. Isto lhe permitirá gerenciar pré-requisitos de banco de dados, por exemplo.O Windows Installer define Produtos que contém Funcionalidades que são constituídas de Componentes. Você pode estruturar seu produto de diversas maneiras. Este exemplo explorar uma funcionalidade principal no projeto Server e funcionalidades dependentes no projeto Database. A vantagem dessa estrutura é que ela garante que o projeto Server será instalado quando qualquer projeto de banco de dados for selecionado. Isolando os projetos de banco de dados em funcionalidades separadas é possível reutilizar o projeto de setup mesmo que apenas um dos projetos mude.Este exercício irá explorar os pontos principais de um arquivo .msi. As tarefas em alto nível são:

Criar uma definição de Produto Criar as Funcionalidades e Componentes Criar a estrutura de Diretório Criar a Interface de Usuário

4. No Solution Explorer, abra o arquivo “Product.wxs” no projeto do instalador. (Figura 69)

A primeira seção deste arquivo define variáveis que nos ajudam a gerenciar as diferenças entre as plataformas x86 e x64. Você verá referências a estas variáveis em outras seções da instalação.

<?define Major = "1" ?><?define Minor = "0" ?><?define Build = "0" ?><?define Revision = "0" ?><?define Version = "$(var.Major).$(var.Minor).$(var.Build).$(var.Revision)" ?><?if $(var.Platform) = "x64" ?>

<?define ProgramFilesFolder = "ProgramFiles64Folder" ?><?define ProgramFilesFolderX86 = "ProgramFilesFolder" ?><?define SystemFolder = "System64Folder" ?><?define SystemFolderX86 = "SystemFolder" ?><?define SoftwareKey = "Software" ?><?define SoftwareKeyX86 = "Software\Wow6432Node" ?><?define FrameworkKey = "Software" ?>

<?else?><?define ProgramFilesFolder = "ProgramFilesFolder" ?><?define ProgramFilesFolderX86 = "ProgramFilesFolder" ?><?define SystemFolder = "SystemFolder" ?><?define SystemFolderX86 = "SystemFolder" ?><?define SoftwareKey = "Software" ?><?define SoftwareKeyX86 = "Software" ?>

<?endif?>

A próxima seção define Product(name). No nosso caso, o nome do produto é WiXDBProSample.


<Product Id="78fd1848-d60e-448d-99cd-2562c0a856dc" Name="!(loc.ProductName)" Language="1033" Version="$(var.Version)" Manufacturer="!(loc.ProductManufacturer)" UpgradeCode="1e9672fc-86de-4073-957b-5fb712688b04">

<Package InstallerVersion="200" Compressed="yes" />

<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />

O atributos em <Product> Name, Version e Manufacturer serão exibidos na seção Programas e Recursos do Painel de Controle. (Figura 72)

Figura 72 Exemplo da informação exibida no Painel de Controle após a instalação

O trecho $(var.Version) faz referência a propriedade version que definimos na seção de variáveis.Você também irá notar que nós localizamos algumas variáveis !(loc.ProductName) as quais você pode reconhecer através do prefixo .loc. As traduções estão definidas no arquivo específico para localização Strings.wxl. (Figura 69)

5. No Solution Explorer, abra o arquivo Strings.wxl que está na pasta Resources.

<WixLocalization Culture="en-us" xmlns="http://schemas.microsoft.com/wix/2006/localization"> <String Id="ProductName">WiXDBProSample v1.0</String> <String Id="ProductNameNoVersion">WiXDBProSample</String> <String Id="ProductManufacturer">Microsoft</String> <String Id="ProductDir">!(loc.ProductNameNoVersion)</String> <String Id="ProductMenu">!(loc.ProductName)</String> <String Id="ProductKey">!(loc.ProductNameNoVersion)</String> <String Id="ProductUrl">http://codeplex</String>

<String Id="Databases">Databases</String> <String Id="Database1">Customers</String> <String Id="Database2">Sales</String> <String Id="DatabaseServer1">Customers Server Settings</String>

</WixLocalization>

Você pode criar versões diferentes deste aquivo alterando o atributo Culture="en-us" para o idioma desejado.




6. Na sequeência iremos definir algumas propriedades. As propriedades que estão em caixa alta são denominadas “public properties” e você pode definir os seus valores ao executar o arquivo .msi a partir da linha de comando. Iremos demonstrar essa opção adiante.

 <Property Id="ALLUSERS" Value="1" />

<PropertyRef Id="NETFRAMEWORK20" /><PropertyRef Id="NETFRAMEWORK20_SP_LEVEL" /><PropertyRef Id="NETFRAMEWORK20INSTALLROOTDIR" /><PropertyRef Id="NETFRAMEWORK30" /><PropertyRef Id="NETFRAMEWORK30_SP_LEVEL" /><PropertyRef Id="NETFRAMEWORK30INSTALLROOTDIR" /><PropertyRef Id="NETFRAMEWORK35" /><PropertyRef Id="NETFRAMEWORK35_SP_LEVEL" /><PropertyRef Id="NETFRAMEWORK35INSTALLROOTDIR" />

<Property Id="SQL08DIR">

<RegistrySearch Id="Sql08DirSearch" Type="raw" Root="HKLM"Key="$(var.SoftwareKey)\Microsoft\Microsoft SQL Server\100" Name="VerSpecificRootDir" />

</Property>

<Property Id="CUSTOMERSDB" Value="Customers" /><Property Id="SALESDB" Value="Sales" />

<Property Id="SQLINSTANCE" /><Property Id="SqlServer" Value="localhost" />

As propriedades que nos interessam agora são:

<Property Id="CUSTOMERSDB" Value="Customers" /><Property Id="SALESDB" Value="Sales" /><Property Id="SQLINSTANCE" /><Property Id="SqlServer" Value="localhost" />

CUSTOMERSDB É utilizado para definir o nome do banco de dados Customers. Esta opção é muito útil em desenvolvimento e teste, uma vez que é possível executar o instalador diversas vezes para criar bancos de dados específicos para desenvolvimento ou teste.SALESDB É utilizado para definir o nome do banco de dados Sales. SQLINSTANCE É utilizado para definir o valor da instância SQL.

IMPORTANTE

Embora o VsDbCmd lhe permita controle do servidor para o qual você irá fazer o deploy, NÃO FAÇA deploy para um servidor diferente de localhost. O efeito disso seria registrar o software como tendo sido instalado na Maquina1 quando na verdade o software foi instalado em Maquina2. Além disso, podem haver problemas como controle da conta de usuário e de delegação de acesso (double hop). Adicionalmente, você irá perder todas as vantagens de gerenciamento do Windows Installer.

A próxima seção define uma série de pré-requisitos para a instalação.

<Condition Message="An administrator must approve or install [ProductName].">

Privileged</Condition>

<?if $(var.Platform) = "x64" ?>

<Condition Message="[ProductName] must be run on a x64 system.">VersionNT64

</Condition><?endif ?>

<?if $(var.Platform) = "x86" ?>

<Condition Message="[ProductName] must be run on a x86 system.">VersionNT And Not VersionNT64

</Condition><?endif ?>

<Condition Message="[ProductName] is only supported on Windows Vista, Windows Server 2008, or higher.">

Installed Or VersionNT >= 600</Condition>

<Condition Message="[ProductName] requires .NET Framework 2.0 Service Pack 2 to be installed.">

Installed Or (NETFRAMEWORK20 And NETFRAMEWORK20_SP_LEVEL >= "#2")</Condition>

<Condition Message="[ProductName] requires .NET Framework 3.5 Service Pack 1 to be installed.">

Installed Or (NETFRAMEWORK35 And NETFRAMEWORK35_SP_LEVEL >= "#1")</Condition>

NOTA

É importante notar que estas condições se aplicam para toda a instalação. Algumas condições aplicam-se somente para Funcionalidades especifícias ou para Componentes. Mais adiante demonstraremos uma forma de determinar se o SQL Server está instalado quando a funcionalidade Database é selecionada.

A próxima seção define a estrutura de diretório onde iremos copiar os arquivos do nosso programa.

<Directory Id="TARGETDIR" Name="SourceDir">

<Directory Id="$(var.ProgramFilesFolder)">



<Directory Id="INSTALLDIR" Name="!(loc.ProductDir)"><Directory Id="DatabasesDir" Name="Databases">

<Directory Id="DatabaseServer1Dir" Name="!(loc.DatabaseServer1)" /><Directory Id="Database1Dir" Name="!(loc.Database1)" /><Directory Id="Database2Dir" Name="!(loc.Database2)" />

</Directory></Directory>

</Directory>

<Directory Id="ProgramMenuFolder">

<Directory Id="ProductMenuFolder" Name="!(loc.ProductMenu)"><Component Id="UninstallShortcut" Guid="{14C164C5-1C09-480b-A47D-

3371F54A6CAE}"><RegistryKey Root="HKCU"

Key="$(var.SoftwareKey)\Microsoft\!(loc.ProductKey)"><RegistryValue Value="!(loc.ProductName)"

Type="string" KeyPath="yes" />

</RegistryKey>

<Shortcut Id="UninstallProduct" Name="Uninstall !(loc.ProductName)" Target="[$(var.SystemFolder)]msiexec.exe" Arguments="/x [ProductCode]" Directory="ProductMenuFolder" Description="Uninstalls !(loc.ProductName)" />

<RemoveFolder Id="UninstallShortcutRemoveProductMenuFolder" On="uninstall" />

</Component></Directory>

</Directory></Directory>

NOTAS

O diretório SourceDir é uma funcionalidade embutida no WiX que refere-se ao drive de instalação. O atalho UninstallProduct é uma forma conveniente de proporcionar a desinstalação do seu produto. Isto pode ser muito útil durante o desenvolvimento ou para debugging.

A próxima seção define as Funcionalidades e Componentes do produto.

É fácil visualizar estes itens através da interface definida na Figura 73. Funcionalidades e Componentes são grupos de arquivos que definem uma unidade coesa do programa. Quando você define os arquivos que fazem parte do Componente ou da Funcionalidade eles recebem GUIDS. Isto permite ao serviço de instalação rastrear esses arquivos do programa de forma que seja possível escrever upgrades ou correções pontuais que afetem apenas alguns arquivos específicos e não necessariamente o produto inteiro.

Figura 73 Interface de instalação de Componente que é renderizada a partir de propriedades especificadas no XML do instalador

Esta interface (Figura 73) é mapeada para a estrutura de diretório através da seção Features.<Feature Id="Databases" Title="!(loc.Databases)" Display="2" Level="1">

<ComponentRef Id="UninstallShortcut" /><ComponentRef Id="VsDbCmd" /><ComponentRef Id="DatabaseServer1" />

<Feature Id="Database1" Title="!(loc.Database1)" Level="1"><ComponentRef Id="Database1" />

</Feature><Feature Id="Database2" Title="!(loc.Database2)" Level="1">

<ComponentRef Id="Database2" /></Feature>



<ComponentGroupRef Id="Product.Generated" /></Feature>

NOTA

Note a referência ao componente para o VsDbCmd e para o DatabaseServer1. Eles são definidos como parte da funcionalidade Databases e serão instalados quando Database1 ou Database2 forem selecionados.

A próxima seção define as ações customizadas que iremos executar como parte da nossa instalação

O Windows Installer não foi de fato desenvolvido para executar funcionalidades customizadas. Ele realiza um excelente trabalho de mapeamento entre arquivos, componentes e banco de dados com chaves de registro associadas. Apesar disso, você precisa utilizar passos alternativos caso queira adicionar funcionalidades especiais. Os elementos Custom actions definem as informações que são necessárias para executar o comando. Os comandos atuais são executados no arquivo “Sequences.wxi”.

<CustomAction Id="PrerequisitesExSql08" Error="[ProductName] requires Sql08 to be installed." />

<CustomAction Id="SetSQLServer" Property="SqlServer" Value="localhost" Execute="firstSequence" /><CustomAction Id="SetSQLServerInstance" Property="SqlServer" Value="localhost\[SQLINSTANCE]" Execute="firstSequence" />

A ação PrerequisitesExSql08 irá disparar um erro caso as Custom Actions sejam executadas. Explicaremos mais sobre este ponto ao explorarmos o arquivo Sequences.wxi.

As outras duas ações são utilizadas para construer o nome do servidor ao executarmos o VsDbCmd. No arquivo Sequences nós iremos utilizar expressões condicionais para definir a propriedade SQLServer para localhost ou localhost\<InstanceName>.

As seções finais fazem referência ao arquivo Sequences.wxi e aos arquivos de interface para definir a sequência de ações customizadas e de formulários a serem exibidos.

<?include Sequences.wxi ?>

<UIRef Id="WixUI_FeatureTreeEx" /><WixVariable Id="WixUILicenseRtf" Value="Resources\License.rtf" />

7. Por último, nós precisamos fazer referência a todos os demais arquivos que fazem parte do projeto WiX.

Nós iremos explorá-los em detalhe nos exercícios seguintes.<?include Components\Common\VsDbCmd.wxi ?><?include Components\Databases\DatabaseServer1.wxi ?><?include Components\Databases\Database1.wxi ?><?include Components\Databases\Database2.wxi ?><?include UI\WixUI_FeatureTreeEx.wxi ?><?include UI\UserRegistrationDlg.wxi ?><?include UI\CustomPropertiesDlg.wxi ?>


Passo 3: Configurando os redistribuíveis

Para fazer o deploy de um projeto para um banco de dados nós precisamos dos redistribuíveis do VsDbCmd redistributables instalados na máquina. Conforme mencionado anteriormente, estes arquivos estão em um local especial da solução. Isso nos permite conectar na estrutura de macros do Visual Studio.

1. No Solution Explorer, vá para o projeto de instalação e abra o arquivo VsDbCmd.wxi na pasta Components\Common.

Esta estrutura será repetida para cada projeto de banco de dados que fizer parte da instalação. Vamos avaliar este arquivo em detalhe para que seja possível melhor compreender o processo.O primeiro trecho instrui ao WiX que este arquivo é um fragmento do arquivo maior Product.wxs. Lembre-se de que nós incluímos este arquivo no exercício anterior.

<Include xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"> <Fragment>

IMPORTANTE

Há uma estrutura de registro específica que deve existir para que o VsDbCmd funcione. Isso é um erro do VsDbCmd na versão final do Visual Studio 2008. A ação a seguir nos permitirá criar as entradas de registro necessárias caso você esteja utilizando Visual Studio 2008.

Por que nós definimos uma CustomAction ao invés de utilizar o elemento <Registry/>? Esta abordagem nos permite controlar quando uma criação de registro deve acontecer baseada em decisões por Funcionalidade ou Componente. Assim, se uma funcionalidade de banco de dados não for selecionada para uma instalação em suma máquina em particular, estas chaves não serão geradas desnecessariamente. Você verá como especificar essa condição no exercício de “Sequências”.

<CustomAction Id="SetDbeRegKey1" Property="RunDbeRegKey1" Value=""[WindowsFolder]system32\reg.exe" add "HKCU\Software\Microsoft\VisualStudio\9.0" /v VsDbCmd /t REG_SZ /d "The registry key containing this value must exist for VsDbCmd.exe to work." /f" /><CustomAction Id="RunDbeRegKey1" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" /><CustomAction Id="SetDbeRegKey2" Property="RunDbeRegKey2" Value=""[WindowsFolder]system32\reg.exe" add "HKCU\Software\Microsoft\VisualStudio\9.0\VSTSDB\Database" /f" /><CustomAction Id="RunDbeRegKey2" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" /><CustomAction Id="SetDbeRegKey3" Property="RunDbeRegKey3" Value=""[WindowsFolder]system32\reg.exe" add "HKCU\Software\Microsoft\VisualStudio\9.0\VSTSDB\Tracing" /f" /><CustomAction Id="RunDbeRegKey3" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" />

2. A seguir definiremos o componente e o colocamos em um diretório.

Nós criamos a estrutura de diretório no exercício anterior e agora iremos fazer referência a essa estrutura, extendendo-a para o Componente.

<DirectoryRef Id="INSTALLDIR"> <Directory Id="VsDbCmdDir" Name="VsDbCmd">





<Component Id="VsDbCmd" Guid="{D6A12A03-B57D-4886-8B08-D5B47F809833}">

3. Adicione os arquivos e componentes que o VsDbCmd requer para execução. (Figura 74)

Por padrão, eles estão localizados \Program Files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Deploy. Esta solução possui uma cópia na pasta Solution\BuildSupportFiles\AnyCpu\VsDbCmd.

Figura 74 Arquivos necessários para executar o VSDBCMD incluídos no projeto de instalação

4. Para incluí-los no instalador é necessário alterar o XML conforme o script abaixo:

<File Id="VsDbCmdVsDbCmd.exe" Name="VsDbCmd.exe" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\VsDbCmd.exe" KeyPath="yes" /><File Id="VsDbCmdVsDbCmd.exe.config" Name="VsDbCmd.exe.config" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\VsDbCmd.exe.config" /><File Id="VsDbCmdDatabaseSchemaProviders.Extensions.xml" Name="DatabaseSchemaProviders.Extensions.xml" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\DatabaseSchemaProviders.Extensions.xml" /><File Id="VsDbCmdMicrosoft.Data.Schema.dll" Name="Microsoft.Data.Schema.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\Microsoft.Data.Schema.dll" /><File Id="VsDbCmdMicrosoft.Data.Schema.ScriptDom.dll" Name="Microsoft.Data.Schema.ScriptDom.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\Microsoft.Data.Schema.ScriptDom.dll" /><File Id="VsDbCmdMicrosoft.Data.Schema.ScriptDom.Sql.dll" Name="Microsoft.Data.Schema.ScriptDom.Sql.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\Microsoft.Data.Schema.ScriptDom.Sql.dll" /><File Id="VsDbCmdMicrosoft.Data.Schema.Sql.dll" Name="Microsoft.Data.Schema.Sql.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\Microsoft.Data.Schema.Sql.dll" /><File Id="VsDbCmdsqlceer35EN.dll" Name="sqlceer35EN.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\sqlceer35EN.dll" /><File Id="VsDbCmdsqlceme35.dll" Name="sqlceme35.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\sqlceme35.dll" /><File Id="VsDbCmdsqlceqp35.dll" Name="sqlceqp35.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\sqlceqp35.dll" /><File Id="VsDbCmdsqlcese35.dll" Name="sqlcese35.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\sqlcese35.dll" /><File Id="VsDbCmdSystem.Data.SqlServerCe.dll" Name="System.Data.SqlServerCe.dll" Source="$(var.SolutionDir)BuildSupportFiles\AnyCpu\VsDbCmd\System.Data.SqlServerCe.dll" />





NOTA

Existem alguns pontos a serem destacados: $(var.SolutionDir) Esta é a macro do Visual Studio que aponta para o diretório da Solução. Os atributos Source e Name são específicos. Se o caminho Source não não coincidir você irá obter um erro de

compilação. De toda forma, se o atributo Name estiver incorreto a instalação será feita com o nome incorreto, o que irá provocar erros em tempo de execução. Outro efeito é que serão exibidas mensagens de erro que poderão iludí-lo quanto ao real problema do contexto.

O atributo KeyPath é um requisito do WiX. Todo Componente deve ter pelo menos um arquivo com o atributo KeyPath.

5. Finalmente, existem alguns requisites do WiX que precisam ser incluídos para a realização de uma desinstalação.

<Shortcut Id="VsDbCmdShortcut1" Name="VsDbCmd.exe command prompt"

Description="VsDbCmd.exe command prompt" WorkingDirectory="INSTALLDIR" Advertise="yes"/>

<RemoveFolder Id="VsDbCmdShortcutsRemoveProductMenuFolder" On="uninstall" />




Passo 4 – Configurando projetos de banco de dados

O guia do WiX recomenda a criação de um Componente para cada arquivo que você desejar instalar, o que simplifica os cenários de upgrade ou correções menores. Nestes cenários o Windows Installer verifica a existência do produto e simplismente copia as novas versões dos arquivos específicos. Cada arquivo faz parte de um único component e possui uma GUID. Durante o processo upgrade (ou correção) o instalador compara os GUIDS copia/exclui somente os arquivos cujos GUIDS foram alterados. Embora seja uma boa prática criar um componente para cada arquivo isso não é obrigatório. Para os pacotes de projeto de banco de dados este ponto não faz muito sentido. Dificilmente será criado um processo de upgrade que copia a nova versão de um arquivo como, por exemplo, o Database.sqlcmdvars, de forma que funcionalidades do banco de dados sejam alteradas. Nós iremos criar um único componente que hospedará todos os arquivos do projeto.No exercício anterior nós explicamos os elementos do componente. Vamos manter o foco na tarefa principal que é mapear a saída do projeto de banco de dados para o pacote de instalação.

1. No Solution Explorer, vá até o projeto de instalação e abra o arquivo Database1.wxi na pasta Components\Databases. Você verá o seguinte script:

<File Id="Database1.dbschema" Name="Customers.dbschema" Source="$(var.Customers.TargetDir)Customers.dbschema" KeyPath="yes" /><File Id="Database1.deploymanifest" Name="Customers.deploymanifest" Source="$(var.Customers.TargetDir)Customers.deploymanifest" /><File Id="Database1Database.sqlcmdvars" Name="Customers_Database.sqlcmdvars" Source="$(var.Customers.TargetDir)Customers_Database.sqlcmdvars" /><File Id="Database1Database.sqldeployment" Name="Customers_Database.sqldeployment" Source="$(var.Customers.TargetDir)Customers_Database.sqldeployment" /><File Id="Database1Database.sqlsettings" Name="Customers_Database.sqlsettings" Source="$(var.Customers.TargetDir)Customers_Database.sqlsettings" /><File Id="Database1Script.PostDeployment.sql" Name="Customers_Script.PostDeployment.sql" Source="$(var.Customers.TargetDir)Customers_Script.PostDeployment.sql" /><File Id="Database1Script.PreDeployment.sql" Name="Customers_Script.PreDeployment.sql" Source="$(var.Customers.TargetDir)Customers_Script.PreDeployment.sql" />

<File Id="Database1master.dbschema" Name="master.dbschema" Source="$(var.Customers.TargetDir)master.dbschema" />

<File Id="CustomersCLR.dll" Name="CustomersCLR.dll" Source="$(var.Customers.TargetDir)CustomersCLR.dll" />

NOTA

Quando o build de um projeto de banco de dados é executado, a pasta .\sql é populada com os arquivos que são necessários ao processo de deployment utilizando o VsDbCmd. Dependendo da configuração (release ou debug) estes arquivos serão criados em pastas diferentes dentro da pasta .\sql. Nós temos uma forma conveniente de fazer referência a pasta utilizando uma macro do Visual Studio $(var.Customers.TargetDir) .

Como o banco de dados faz referência a objetos de sistema nós precisamos incluir o arquivo master.dbschema. Como o banco de dados faz referência ao projeto CustomerCLR nós precisamos incluir também essa .dll.


2. Agora que os arquivos foram incluídos podemos definir o comando utilizado para instalar o banco de dados. As linhas a seguir são responsáveis por este passo:

<CustomAction Id="CmdLineSetDatabase1" Property="CmdLineRunDatabase1" Value=""[WindowsFolder]system32\cmd.exe" /c pushd "

[Database1Dir]" & "[VsDbCmdDir]VsDbCmd.exe" /a:Deploy /cs:"Data Source=[SqlServer];Integrated Security=True;Pooling=False" /dd+ /manifest:"[#Database1.deploymanifest]" /p:TargetDatabase="[CUSTOMERSDB]" /dsp:Sql" /><CustomAction Id="CmdLineRunDatabase1"

BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" TerminalServerAware="yes"/>

NOTA

O comando pushd é uma extensão da linha de comando. Ele armazena o nome do diretório atual para ser utilizado pelo comando popd antes de alterar o diretório para o destino especificado.

O comando pushd é extremamente importante. Se você não utilizar o comando pushd o diretório de trabalho será o System32 ou System64WoW, dependendo da arquitetura do SO (32 ou 64 bits). O Pushd garante que o script .sql gerado durante o deployment será levado ao local de instalação de cada banco de dados.

No Passo 2 nós configuramos algumas propriedades cruciais que agora começaremos a utilizar. Qualquer diretório definido no WiX podem ser referenciados através do seu Id. [WindowsFolder], [Database1Dir], e [VsDbCmdDir] são evoluídos para o seus caminhos respectivos.

A propriedade [SqlServer] é uma privada e resolve tanto localhost quanto localhost\[SQLINSTANCE]. Se o usuário informa uma instância de SQL específica, seja na interface ou através da linha de comando, o atributo SqlServer inclui o nome da instância.

O item [#Database1.deploymanifest] equivale ao caminho completo do deploymanifest. /p:TargetDatabase é definido com o valor provido pelo usuário [CUSTOMERSDB]. Note o atributo TerminalServerAware. Estes atributos definem para o SO que há uma instalação sendo executada

em uma sessão do Terminal Server. Podem ocorrer erros atípicos nesse cenário, normalmente em sessões do Windows 2003 Terminal Services.





Agora que temos um banco de dados definido, vamos dar uma olhada em alguns trechos específicos dos outros dois projetos.

3. No Solution Explorer, vá até o projeto de instalação e abra o arquivo Database2.wxi localizado na pasta Components\Databases.

Quase todo o conteúdo é o mesmo do Database1.wxi exceto por alguns nomes de arquivos específicos que incluem o nome do projeto. Atenção a estas linhas:

<File Id="Customers.dbschema" Name="Customers.dbschema" Source="$(var.Sales.TargetDir)Customers.dbschema" />

<util:XmlConfig Id="SalesSqlCmdVar1"File="[Database2Dir]Sales_Database.sqlcmdvars"Action="create" ElementPath="//SqlCommandVariables/Properties/Property[\

[]PropertyName='Customers'[\]]/PropertyValue"Value="[CUSTOMERSDB]"Node="value"Sequence="1"On="install"/>

Como o banco de dados Sales faz referência ao banco de dados Customers, é necessário nós incluir o arquivo Customers.dbschema.Além disso, como o nosso instalador nos permite alterar o nome do banco de dados no momento da instalação, é necessário atualizar o arquivo sales_database.sqlcmdvars. É para este fim que utilizamos a tag <util:XmlConfig . O schema util é uma extensão do WiX que adiciona uma série de novas funcionalidades à experiência padrão do Windows Installer. Para habilitar estas capacidades é preciso incluir a dll como uma referência de projeto e importá-la nos arquivos WiXS.

<Include xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

O elemento XmlConfig possui uma série de atributos:

O atributo Action é definido para criar ou atualizar o item caso ele exista. O atributo ElementPath é um trecho XSL que significa: Encontre o elemento “Property” que contém um elemento

filho chamado “PropertyName” com o conteúdo texto equivalente a “Customers” e então encontre um elemento irmão que tenha o nome de “PropertyValue”. Isto serve para definir o contexto do nó.

O atributo Value especifica o valor do contexto do nó. O atributo Node especifica quando atualizar um atributo ou o Texto do contexto do nó. Se existirem múltiplas mudanças utilize o nó Sequence para especificar a ordem das mudanças.

Finalmente, observe algumas diferenças entre os projetos de servidor (Server Projects) e os projetos de banco de dados (Database Projects).No projeto do instalador, abra o arquivo DatabaseServer1.wxi localizado na pasta Components\Databases.A diferença prática está no fato de que o projeto de servidor possui um conjunto diferente de arquivos de saída.

<File Id="DatabaseServer1Master.sqlcmdvars" Name="master_Master.sqlcmdvars" Source="$(var.CustomersServer.TargetDir)master_Master.sqlcmdvars" /><File Id="DatabaseServer1Master.sqldeployment" Name="master_Master.sqldeployment" Source="$(var.CustomersServer.TargetDir)master_Master.sqldeployment" /><File Id="DatabaseServer1Master.sqlsettings" Name="master_Master.sqlsettings" Source="$(var.CustomersServer.TargetDir)master_Master.sqlsettings" />





<File Id="DatabaseServer1Server.sqlsettings" Name="master_Server.sqlsettings" Source="$(var.CustomersServer.TargetDir)master_Server.sqlsettings" />

Projetos de servidor apontam para o banco de dados master e é por este motivo que possuem o prefixo “master” hard-coded. Eles possuem ainda um arquivo especial chamado Server.sqlsettings.




Passo 5 – Sequências e Expressões Condicionais

Neste exercício nós iremos controlar como e quando executar todos as CustomActions que foram definidas. Existem três detalhes que devem ser monitorados:

A sequência dos eventos de instalação. As diferentes sequências de instalação: Install, Uninstall, Repair, e assim por diante. Execução condicional. Dependendo das Funcionalidades e Componentes que foram instalados você pode desejar

não executar uma das ações customizadas.

O Windows Installer possui uma sequência de eventos que são definidos no Windows Installer SDK. Nós desejamos executar o deployment após os arquivos terem sido instalados e o arquivo .sqlcmdvars tenha sido modificado com o valores de nossas propriedades. É necessário garantir também que os requisitos de registro relativos ao VsDbCmd tenham sido aplicados antes de executarmos o deployment.

1. No Solution Explorer, vá até o projeto de instalação e abra o arquivo Sequences.wxi localizado na pasta raiz. Você verá o seguinte conteúdo:

<InstallExecuteSequence> <Custom Action="PrerequisitesExSql08" Before="InstallInitialize">!Databases=2 And &Databases=3 And Not SQL08DIR</Custom>

 <Custom Action="SetDbeRegKey1" Before="RunDbeRegKey1">!Databases=2 And &Databases=3</Custom> <Custom Action="RunDbeRegKey1" Before="SetDbeRegKey2">!Databases=2 And &Databases=3</Custom> <Custom Action="SetDbeRegKey2" Before="RunDbeRegKey2">!Databases=2 And &Databases=3</Custom> <Custom Action="RunDbeRegKey2" Before="SetDbeRegKey3">!Databases=2 And &Databases=3</Custom> <Custom Action="SetDbeRegKey3" Before="RunDbeRegKey3">!Databases=2 And &Databases=3</Custom> <Custom Action="RunDbeRegKey3" Before="InstallFiles">!Databases=2 And &Databases=3</Custom>

<Custom Action="SetSQLServerInstance" Before="StartServices">SQLINSTANCE <>""</Custom> <Custom Action="CmdLineSetDatabaseServer1" After="StartServices">!Databases=2 And &Databases=3</Custom> <Custom Action="CmdLineRunDatabaseServer1" After="CmdLineSetDatabaseServer1">!Databases=2 And &Databases=3</Custom>

<Custom Action="CmdLineSetDatabase1" After="CmdLineRunDatabaseServer1">!Database1=2 And &Database1=3 And ?Database1=2 And $Database1=3</Custom> <Custom Action="CmdLineRunDatabase1" After="CmdLineSetDatabase1">!Database1=2 And &Database1=3 And ?Database1=2 And $Database1=3</Custom>

<Custom Action="CmdLineSetDatabase2" After="CmdLineRunDatabaseServer1">!Database2=2 And &Database2=3 And ?Database2=2 And $Database2=3</Custom>


<Custom Action="CmdLineRunDatabase2" After="CmdLineSetDatabase2">!Database2=2 And &Database2=3 And ?Database2=2 And $Database2=3</Custom></InstallExecuteSequence>

Cada elemento Custom refere-se a uma CustomAction que definimos anteriormente. Os atributos Before e After definem onde na sequência de instalação estas ações customizadas devem ser executadas. Há um conjunto de ações definidas que compõem a sequência padrão de instalação. (Figura 75)

Ação Condição Sequência

LaunchConditions 100

AppSearch 400

CCPSearch NOT Installed 500

RMCCPSearch NOT Installed 600

ValidateProductID 700

CostInitialize 800

FileCost 900

CostFinalize 1000

SetODBCFolders 1100

InstallValidate 1400

InstallInitialize 1500

AllocateRegistrySpace NOT Installed 1550

ProcessComponents 1600

UnpublishComponents 1700

UnpublishFeatures 1800

StopServices VersionNT 1900

DeleteServices VersionNT 2000

UnregisterComPlus 2100

SelfUnregModules 2200

UnregisterTypeLibraries 2300

RemoveODBC 2400

UnregisterFonts 2500

RemoveRegistryValues 2600

UnregisterClassInfo 2700

UnregisterExtensionInfo 2800

UnregisterProgIdInfo 2900

UnregisterMIMEInfo 3000

RemoveIniValues 3100

RemoveShortcuts 3200

RemoveEnvironmentStrings 3300

RemoveDuplicateFiles 3400

RemoveFiles 3500

RemoveFolders 3600

CreateFolders 3700

MoveFiles 3800

InstallFiles 4000



http://msdn.microsoft.com/en-us/library/aa372495(VS.85).aspx











































PatchFiles 4090

DuplicateFiles 4210

BindImage 4300

CreateShortcuts 4500

RegisterClassInfo 4600

RegisterExtensionInfo 4700

RegisterProgIdInfo 4800

RegisterMIMEInfo 4900

WriteRegistryValues 5000

WriteIniValues 5100

WriteEnvironmentStrings 5200

RegisterFonts 5300

InstallODBC 5400

RegisterTypeLibraries 5500

SelfRegModules 5600

RegisterComPlus 5700

InstallServices VersionNT 5800

StartServices VersionNT 5900

RegisterUser 6000

RegisterProduct 6100

PublishComponents 6200

PublishFeatures 6300

PublishProduct 6400

InstallFinalize 6600

Figura 75 Order definida da sequência de instalação

No passo 3 nós incluímos uma extensão para o WiX que nos permite alterar os arquivos XML. Estas extensões adicionam eventos à sequência. Estes eventos aparecem no arquivo Sequences com sendo Custom Actions às quais você pode se vincular através dos atributos Before e After. As ações util:XmlConfig ocorrem exatamente antes da ação StartServices. Tudo isso faz parte de uma extensa explicação de porquê as Customs Actions para o deployment de banco de dados são encadeadas de forma a acontecerem após o evento StartServices. Isto garante que as ações de deployment ocorrem após os arquivos XML (*.sqlcmdvars) e após as mudanças no Registro.Agora que temos as Custom Actions na sequência necessária, precisamos controlar quando uma Custom Action deve ser executa. Para fazê-lo, nós iremos utilizar uma condição especial de sintaxe que o Windows Installer usa. Você insere essas condições no texto dos elementos do tipo Custom. <Custom Action="RunDbeRegKey3" Before="InstallFiles">!Databases=2 And &Databases=3</Custom>

A condição acima valida o seguinte: “a funcionalidade Databases não está instalada e a funcionalidade Databases está instalando”. <Custom Action="SetSQLServerInstance" Before="StartServices">SQLINSTANCE <>""</Custom>

Esta condição valida o seguinte: a propriedade SQLINSTANCE <> ‘’. Como o WiX é uma linguagem XML sobre o Windows Installer é necessário evitar os caracteres como <, >, and &. <Custom Action="CmdLineSetDatabase1" After="CmdLineRunDatabaseServer1">!Database1=2 And &Database1=3 And ?Database1=2 And $Database1=3</Custom>































Este último exemplo valida se: “a funcionalidade Databases não está instalada e a funcionalidade Databases está instalando e o component Database1 não está instalado e o componente Database1 está instalando”. Lembre-se que no exercício 2 nós mapeamos Database1 e Database2 para os nomes amigáveis Customers e Sales. O que essas condições fazem é garantir que a custom action é executada somente se o usuário tiver selecionado aquela funcionalidade ou componente para a instalação, além de garantir que estas ações não serão executadas caso o usuário esteja desinstalando.





Passo 6 – Propriedades e Interface de Usuário (UI)

Há somente mais um ponto que precisamos endereçar para obtermos um instalador funcionando. Nós precisamos criar uma interface que mapeie as entradas do usuário para as propriedades que controlam o deployment.

1. No Solution Explorer, vá até o projeto Install e abra o arquivo CustomPropertiesDlg.wxi localizado na pasta UI.2. Este arquivo contém a definição de uma página do wizard do instalador. Há uma série de estruturas que definem

os elementos de interface e maior parte deles é autoexplicativa. A parte um pouco menos intuitiva são os delegates dos eventos Back e Next.

<Property Id="WixUI_CustomPropertiesDlgBack" Value="CustomizeDlg" /><Property Id="WixUI_CustomPropertiesDlgNext" Value="VerifyReadyDlg" />

Estas propriedades fazem referência as interfaces de diálogo que são definidas no arquivo WiXUI_FeatureTreeEx.wxi.O principal ponto de interesse é a definição das três caixas de texto que capturam as entradas de usuário.

<Control Id="CustomProperty1Label" Type="Text" X="45" Y="70" Width="280" Height="15" TabSkip="no" Text="SQL Server Instance Name" /><Control Id="CustomProperty1Edit" Type="Edit" X="45" Y="80" Width="280" Height="18" Property="SQLINSTANCE" Text="{80}" />

<Control Id="CustomProperty2Label" Type="Text" X="45" Y="100" Width="280" Height="15" TabSkip="no" Text="Name of the Customers Database" /><Control Id="CustomProperty2Edit" Type="Edit" X="45" Y="110" Width="280" Height="18" Property="CUSTOMERSDB" Text="{80}" />

<Control Id="CustomProperty3Label" Type="Text" X="45" Y="130" Width="280" Height="15" TabSkip="no" Text="Name of the Sales Database" /><Control Id="CustomProperty3Edit" Type="Edit" X="45" Y="140" Width="280" Height="18" Property="SALESDB" Text="{80}" />

O atributo Property mapeia a entrada de usuário para uma propriedade particular. Abaixo vemos como o diálogo será renderizado quando o instalador for executado. (Figura 76)

Figura 76 Diálogo de Propriedades customizadas criadas no instalador





3. No Solution Explorer, clique com o botão direito no projeto Install e selecione Build.4. Enquanto você pode executar o arquivo Install.msi através de um duplo-clique é mais interessante executá-lo

através de uma linha de comando e capturar as informações de log. (Figura 77)

Utilize o comando a seguir para chamar o pacote msiexec:

Msiexec.exe /I WiXDBProInstall_X64.msi /l*v WixDBProInstall_x64.install.log

Se você já executou a instalação manualmente, desinstale o produto através do Painel de Controle e exclua (drop) os bancos de dados Customer e Sales. Para excluir os bancos de dados, abra o SQL Management Studio, conecte na instância local do SQL Server, clique com o botão direito nos bancos de dados citados e selecione Drop database.

Figura 77 Executando o instalador a partir da linha de comando utilizando o parâmetro /l

6. Quando a instalação é finalizada, abra o arquivo WiXDBProInstall_x64.install.log, que está localizado na mesma pasta do pacote de instalação. Há aparentemente bastante ruído neste arquivo. Todas as informações tem um propósito, porém está além dos objetivos deste laboratório explicar estes detalhes.

7. Role até o ponto onde as Custom actions começam a ser executados, próximo ao final do arquivo. Você está procurando pelas linhas a seguir:

MSI (s) (CC:DC) [14:06:34:904]: Executing op: ActionStart(Name=CmdLineRunDatabaseServer1,,)Action 14:06:34: CmdLineRunDatabaseServer1. MSI (s) (CC:DC) [14:06:34:906]: Executing op: CustomActionSchedule(Action=CmdLineRunDatabaseServer1,ActionType=17473,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Windows\system32\cmd.exe" /c pushd "C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\" & "C:\Program Files\WiXDBProSample\VsDbCmd\VsDbCmd.exe" /a:Deploy /cs:"Data Source=localhost;Integrated Security=True;Pooling=False" /dd+ /manifest:"C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\CustomersServer.deploymanifest" /dsp:Sql)MSI (s) (CC:10) [14:06:34:935]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI42AA.tmp, Entrypoint: CAQuietExecCAQuietExec: TSD00560 The project and target databases have different collation settings. Deployment errors might occur.CAQuietExec: TSD00566 Deployment script generated to:CAQuietExec: C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\CustomersServer.sqlCAQuietExec: CAQuietExec: *** SQL01268C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\CustomersServer.sql (47,0) .Net SqlClient Data Provider: Msg 14262, Level 16, State 1, Procedure sp_verify_category_identifiers, Line 50 The specified @category_name ('Sales') does not exist.CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\CustomersServer.sql (47,0) An error occurred while the batch was being executed.CAQuietExec: Error 0x80070001: Command line returned an error.





CAQuietExec: Error 0x80070001: CAQuietExec FailedCustomAction CmdLineRunDatabaseServer1 returned actual error code 1603 but will be translated to success due to continue markingMSI (s) (CC:DC) [14:06:49:194]: Executing op: ActionStart(Name=CmdLineRunDatabase1,,)Action 14:06:49: CmdLineRunDatabase1. MSI (s) (CC:DC) [14:06:49:197]: Executing op: CustomActionSchedule(Action=CmdLineRunDatabase1,ActionType=17473,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Windows\system32\cmd.exe" /c pushd "C:\Program Files\WiXDBProSample\Databases\Customers\" & "C:\Program Files\WiXDBProSample\VsDbCmd\VsDbCmd.exe" /a:Deploy /cs:"Data Source=localhost;Integrated Security=True;Pooling=False" /dd+ /manifest:"C:\Program Files\WiXDBProSample\Databases\Customers\Customers.deploymanifest" /p:TargetDatabase="Customers" /dsp:Sql)MSI (s) (CC:C4) [14:06:49:234]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI7A7D.tmp, Entrypoint: CAQuietExecCAQuietExec: TSD00566 Deployment script generated to:CAQuietExec: C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sqlCAQuietExec: CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (38,0) Creating Customers...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (171,0) Creating ...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (182,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (191,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (208,0) Creating PK_Addresses...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (217,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (230,0) Creating PK_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (239,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (251,0) Creating PK_CompanyAddresses...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (260,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (272,0) Creating PK_CompanyContacts...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (281,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (296,0) Creating PK_Contacts...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (305,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (317,0) Creating PK_Customers...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (326,0) Creating .....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (335,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (346,0) Creating PK_Partners...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (355,0) Creating .....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (364,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (375,0) Creating PK_Vendors...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (384,0) Creating .....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (393,0) Creating FK_Companies_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (402,0) Creating FK_CompanyAddresses_Addresses...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (411,0) Creating FK_CompanyAddresses_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (420,0) Creating FK_CompanyContacts_Companies...





CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (429,0) Creating FK_CompanyContacts_Contacts...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (438,0) Creating FK_Customers_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (447,0) Creating FK_Partners_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (456,0) Creating FK_Vendors_Companies...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (465,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (489,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (505,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (516,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (530,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers\Customers.sql (572,0) Checking existing data against newly created constraintsMSI (s) (CC:DC) [14:07:34:774]: Executing op: ActionStart(Name=CmdLineRunDatabase2,,)Action 14:07:34: CmdLineRunDatabase2. MSI (s) (CC:DC) [14:07:34:780]: Executing op: CustomActionSchedule(Action=CmdLineRunDatabase2,ActionType=17473,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\Windows\system32\cmd.exe" /c pushd "C:\Program Files\WiXDBProSample\Databases\Sales\" & "C:\Program Files\WiXDBProSample\VsDbCmd\VsDbCmd.exe " /a:Deploy /cs:"Data Source=localhost;Integrated Security=True;Pooling=False" /dd+ /manifest:"C:\Program Files\WiXDBProSample\Databases\Sales\Sales.deploymanifest" /p:TargetDatabase="Sales" /dsp:Sql)MSI (s) (CC:44) [14:07:34:814]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI2C8D.tmp, Entrypoint: CAQuietExecCAQuietExec: TSD00566 Deployment script generated to:CAQuietExec: C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sqlCAQuietExec: CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(39,0) Creating Sales...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(172,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(185,0) Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(196,0) Creating ....CAQuietExec: *** SQL01268C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(200,0) .Net SqlClient Data Provider: Msg 4504, Level 16, State 1, Procedure Customers, Line 3 Could not create view 'Customers' because CLR type 'CustomerAddressType' does not exist in the target database 'Sales'.CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql

(200,0) An error occurred while the batch was being executed.CAQuietExec: Error 0x80070001: Command line returned an error.CAQuietExec: Error 0x80070001: CAQuietExec FailedCustomAction CmdLineRunDatabase2 returned actual error code 1603 but will be translated to success due to continue marking





Passo 7 – Armadilhas Comuns

Note que temos erros mesmo que a instalação tenha sido bem sucedida. Esta é uma das partes mais complicadas do deployment utilizando o VsDbCmd. Algumas vezes você pode obter sucesso parcial. Quando você estiver desenvolvendo ou inspecionando a experiência de instalação pode ser útil deixar o banco de dados no seu estado de deploy parcial, para que seja possível solucionar esses erros. Isso pode ser útil se você tiver muitas atividades nos scripts de pre e post deployment.Há um efeito colateral da comparação de schema realziada pela deployment engine: você pode reexecutar a instalação e trazer o banco de dados para o estado desejado. Isso é particularmente verdade se sua sequência de instalação não estiver correta.

Nós podemos controlar quando a instalação é abortada caso ocorra um erro quando definimos elementos CustomAction que executam o VsDbCmd.

5. No Solution Explorer, vá até o projeto Install e abra o arquivo Database2.wxi localizado na pasta “Components\Databases”. Examine as seguintes linhas:

<CustomAction Id="CmdLineRunDatabase2" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" TerminalServerAware="yes"/>

O atributo Return informa o Windows Installer para executar a linha de comando e ignorar qualquer resposta. Vamos alterá-lo para check.<CustomAction Id="CmdLineRunDatabase2"

BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" TerminalServerAware="yes"/>

6. Pressione F6 para realizar o build do projeto Install novamente.

7. No Painel de Controle, clique em Programas e Recursos. Selecione WiXDBProSample v1.0 e escolha Desinstalar.

8. Abra o SQL Management Studio e exclua os bancos de dados Sales e Customers. Para excluir os bancos de dados conecte na instância local do SQL Server, clique com o botão direito nos bancos citados e selecione Drop database.

9. Execute o WiXDBProInstall_x64 a partir da linha de comando e você irá perceber este erro. (Figura 78)





Figura 78 Instalação abortada do projeto de instalação do WiX

10. Nós intencionalmente alteramos o arquivo Database2.wxi para que você pudesse ver um efeito importante. Se você abrir o arquivo WixDBProInstall_x64.install.log você verá o seguinte:

CAQuietExec: TSD00566 Deployment script generated to:CAQuietExec: C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sqlCAQuietExec: CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (39,0)

Creating Sales...CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (172,0)

Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (185,0)

Creating ....CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (196,0)

Creating ....CAQuietExec: *** SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (200,0)

.Net SqlClient Data Provider: Msg 4504, Level 16, State 1, Procedure Customers, Line 3 Could not create view 'Customers' because CLR type 'CustomerAddressType' does not exist in the target database 'Sales'.CAQuietExec: SQL01268 C:\Program Files\WiXDBProSample\Databases\Sales\Sales.sql (200,0) An error occurred while the batch was being executed.CAQuietExec: Error 0x80070001: Command line returned an error.CAQuietExec: Error 0x80070001: CAQuietExec Failed

O que aconteceu é que mesmo com o VsDbCmd retornando um erro e a instalação tendo falhado, o banco de dados e uma série de objetos foram criados.

Vamos fazer com que a instalação funcione corretamente.

Para resolver o erro CustomerAddressType acima nós precisamos adicionar uma referência ao projeto CLR.

11. No projeto Sales, clique com o botão direito na pasta references no Solution Explorer and selecione Add Reference. O diálogo Add Reference será exibido. (Figura 79)





Figura 79 Diálogo Add Reference

12. Selecione o projeto CustomersCLR e clique em OK.

13. Crie uma definição para o CustomersAddressType no projeto Sales.

a. No Solution Explorer, vá até o projeto Sales. (Figure 80)

Figure 80 O projeto de banco de dados Sales

b. Clique com o botão direito na pasta User Defined Types CLR e selecione New Item.c. Selecione o template User Defined Type (CLR).d. Para o nome do arquivo digite CustomerAddress e clique em Add.e. Após o novo arquivo ser aberto, substitua o texto com o seguinte script:

CREATE TYPE [dbo].[CustomerAddressType]EXTERNAL NAME [CustomersCLR].[CustomerAddressType]

14. Precisamos incluir o arquivo CustomersCLR.dll na instalação definindo-o no arquivo Database2.wxi file.

a. No Solution Explorer, vá até o projeto Install e abra o arquivo Database2.wxi que está localizado na pasta Components\Databases.

b. Procure pela linha que definie Customers.dbschema

<File Id="Customers.dbschema" Name="Customers.dbschema" Source="$(var.Sales.TargetDir)Customers.dbschema" />

c. Insira a linha a seguir após essa definição. Preste atenção no valor do Id para que não colida com a definição em Database1.wxi.

<File Id="Sales.CustomersCLR.dll" Name="CustomersCLR.dll" Source="$(var.Sales.TargetDir)CustomersCLR.dll" />





15. Nós também precisamos resolver o problema no projeto CustomerServer.

a. No exercício anterior vimos o erro a seguir durante o deployment:

CAQuietExec: *** SQL01268 C:\Program Files\WiXDBProSample\Databases\Customers Server Settings\CustomersServer.sql (47,0) .Net SqlClient Data Provider: Msg 14262, Level 16, State 1, Procedure sp_verify_category_identifiers, Line 50 The specified @category_name ('Sales') does not exist.

Precisamos corrigir um erro no nosso script de post deployment.

16. Em CustomersServer sob Scripts\PostDeployment abra o arquivo em ShippingDatePost.sql.

a. Encontre as linhas abaixo:/****** Object: JobCategory [[Uncategorized (Local)]]] Script Date: 09/28/2009 15:00:27 ******/IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'Customers' AND category_class=1)BEGINEXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'Customers'IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

b. Altere N'Customers' para N'Sales'.

Este script também irá falhar caso o banco de dados Sales não exista, de forma que devemos rearranjar a sequência de execução.

17. No Solution Explorer, vá até o projeto Install e abra o arquivo Sequences.wxi lozalizado na pasta raiz.

a. É necessário rearranjar os atributos After para que fiquem conforme abaixo:

<Custom Action="CmdLineSetDatabase1" After="StartServices">!Database1=2 And &Database1=3 And ?Database1=2 And $Database1=3</Custom><Custom Action="CmdLineRunDatabase1" After="CmdLineSetDatabase1">!Database1=2 And &Database1=3 And ?Database1=2 And $Database1=3</Custom>

<Custom Action="CmdLineSetDatabase2" After=" CmdLineRunDatabase1">!Database2=2 And &Database2=3 And ?Database2=2 And $Database2=3</Custom><Custom Action="CmdLineRunDatabase2" After="CmdLineSetDatabase2">!Database2=2 And &Database2=3 And ?Database2=2 And $Database2=3</Custom>

<Custom Action="CmdLineSetDatabaseServer1" After=" CmdLineRunDatabase2">!Databases=2 And &Databases=3</Custom><Custom Action="CmdLineRunDatabaseServer1" After="CmdLineSetDatabaseServer1">!Databases=2 And &Databases=3</Custom>

18. No Solution Explorer, clique com o botão direito no projeto Install e selecione Build.

19. Agora nós podemos executar o instalador novamente a partir da linha de comando:

Msiexec.exe /I WiXDBProInstall_X64.msi /l*v WixDBProInstall_x64.install.log





Figura 81 Saída da linha de comando do instalador iniciado

Após o instalador ter sido executado, você deve visualizar a saída mostrada na Figura 81. Agora, quando você abre o arquivo de log, não deve haver falhas.





Conclusão

Neste laboratório nós exploramos o deployment de bancos de dados através de uma experiência com o Windows Installer baseado no WiX. Definimos um produto com suas funcionalidades e diretórios, empacotamos a saída dos projetos de banco de dados e construímos a sequência de instalação. Finalmente, percorremos alguns cenários de falha para demonstrar algumas noções de troubleshooting e armadilhas comuns neste processo.Embora tenhamos obtido um processo de instalação bem sucedido, podemos melhorá-lo tratando as armadilhas que econtramos. Isto seria um aumento considerável do escopo deste laboratório, portanto não iremos guiá-lo nesse passo-a-passo. Abaixo estão os assuntos mais importantes e algumas ideias de como endereçar cada área.

O problema mais complicado certamente é o rollback. Neste laboratório nós demonstramos um cenário onde estamos realizando o deployment de múltiplos bancos de dados. Isso pode ser comum para aplicações de uma grande empresa que constituem um ecossistema conectado. Temos algumas ferramentas a nossa disposição mas não há uma única abordagem que resolvem todos os problemas.Faça backup do banco de dados antes do deployment. Esta é a estratégia mais confiável, porém vem acompanhada de uma redução de performance. Você ppode habilitar este comportamento nas opções Deployment configuration do projeto, selecionando Back up database before deployment. (Figura 82)

Figura 82 Opção para criar um backup antes do deployment

Para implementar essa estratégia siga os passos a seguir:

1. Habilite a opção de Backup.2. Escreva um script .sql que restaure o backup.3. Execute esse script .sql em uma CustomAction que esteja condicionada a execução do rollback.

Se você pode tolerar o tempo necessário durante a instalação, esta é a opção mais direta e eficiente.Se você não puder esperar pelo tempo de backup e restore, há uma abordagem que lhe dá controle granular.

Separe o deployment do schema do deployment dos dados. A ideia é aplicar todas as alterações de schema utilizando o VsDbCmd e então criar um único script que aplica qualquer alteração aos dados.

Para implementar essa estratégia siga os seguintes passos:1. Execute uma CustomAction que importa o schema do banco de dados alvo. Isto preserva o estado atual do banco de

dados e nos permite reaplicá-lo caso algo dê errado.2. Escreva um script .sql que move os dados para uma banco de dados temporário ou para um arquivo.3. Execute o script .sql em uma CustomAction que esteja condicionada para executar durante a instalação.4. Faça o deploy dos seus bancos de dados.5. Escreva um script .sql que aplica as alterações de dados. Certifique-se de que sejam transacionais.6. Execute o script .sql em uma CustomAction condicionada a execução da instalação.7. Escreva uma CustomAction que executa o deploy do schema que preservamos no passo 1. Condicione sua execução

ao rollback da instalação.8. Escreva um script .sql que restaura os dados preservados no passo 2.9. Execute o script em uma CustomAction. Condicione sua execução ao rollback da instalação.

Se você decidir utilizar essa abordagem, considere criar um Setup.exe no qual você tenha controle completo do código de interface. Fazendo isso você irá simplificar os instaladores e poderá tratar lógicas complexas e conversão de texto que o WiX não trata.





O Cenário de Integração com o Team Build

Resumo

O Team build com o Team Foundation Server provê uma forma fácil e automatizada para compilar, fazer o build, executar testes automatizados, fazer release de arquivos em um local pré-definido (build drop) e fornecer informações sobre a qualidade da informação do build publicando informações em relatórios através de um data warehouse. Com estes processos automatizados, problemas de interoperabilidade podem ser encontrados antecipadamente no ciclo de vida da aplicação. Como os projetos de banco de dados do Visual Studio podem ser incluídos em Team Builds, eles provêm uma excelente forma de garantir builds estáveis e com qualidade conhecida.


Criar definições de build Enfileirar builds a partir de uma definição de build Investigar problemas encontrados durante a execução do build e verifique o progresso do builds enfileirados

Local dos arquivos iniciais: C:\DatabaseProjectGuidance\HOL\Database Project Build and Deployment Automation Management


Passo 1: Crie uma definição de build

Para utilizar o Team Build em nosso projeto de banco de dados precisamos criar uma definição de build e armazená-la no Team Foundation Server. O passo irá criar uma definição de build pronta para ser enfileirada no processo do Team Build.


1. No menu principal, clique em View e então em Team Explorer.

2. Expanda o Team Project HOL_DatabaseProjects. (Figura 83)





Figura 83 Visão do projeto no Team Explorer

3. Selecione o nó Builds.

4. Clique com o botão direito e selecione New Build definition. (Figura 84)

Figura 84 Criando uma nova definição de build

5. Digite o nome AdventureWorksExample para a nova definição de build e opcionalmente digite uma descrição. Procure identificar com clareza o build para que seja fácil para os demais membros do time diferenciá-lo sem precisar inspecionar os detalhes.





NOTA

Nota: Se o erro a seguir for exibido, o controlador não foi configurado. Para configurar o service de build veja “Configurando uma Máquina de Build”5

Figura 85 Diálogo alertando sobre a ausência de um controlador de build

5 http://msdn.microsoft.com/en-us/library/ms181712.aspx




http://msdn.microsoft.com/en-us/library/ms181712.aspx




6. Para completer a definição de build, todos os passos no menu da esquerda (como mostrada na figura abaixo) devem ser

preenchidos. Contudo, os passos obrigatórios estão identificados com o triângulo . (Figura 86)

Figura 86 Informações obrigatórias da definição de build destacadas por um triângulo amarelo

7. Clique em Trigger. A tela a seguir aparece. O disparador (trigger) do build indica como o build será iniciado. No Team Foundation Server existem 5 formas:

o Manual – O build precisa ser manualmente iniciado.o Continuous Integration – O build será iniciado cada vez que ocorrer um check-in.o Rolling builds – Os builds após a ocorrência de um check-in e após o tempo transcorrido.o Gated Check-in – O build só será gravado de fato no controle de código-fonte após o término do build, caso

ele seja bem sucedido, inclusive em relação aos testes associados. o Scheduled – O build é iniciado em data/hora específica. Esta é a opção na qual é possível agendar um build

mesmo que nenhum check-in tenha ocorrido.

Selecione a trigger Continuous Integration para indicar que o build deve ser feito a cada check-in. (Figura 87)

Figura 87 Opção para disparar um build





8. Clique no item Workspace. O workspace é o mapeamento entre a pasta no controle de versão no Team Foundation Server e o diretório onde os arquivos serão extraídos na máquina de build.

9. Você não precisa alterar nada nesta tela. Contudo, para intergração continua, a pasta do controle de versão selecionada corresponde à estrutura sob a qual ao ocorrer um check-in será disparado um build.

Figura 88 Mapeamento do Workspace para o build

10. Clique no item Build defaults. A tela Build Defaults é onde são detalhados o controlador (máquina onde o build será executado) e o local onde os artefatos do build serão copiados ao final do processo.





11. Selecione um controlador de build a partir da lista. O controlador de build é comumente referido como “máquina de build”.

NOTA

Se você estiver usando sua própria máquina virtual você precisa selecionar o seu próprio controlador.

12. Digite o local \\localhost\drops no campo output location. Este é o local onde os artefatos de build serão copiados após o processo de build ser finalizado. Este local precisa ser obrigatoriamente um compartilhamento de rede (UNC).

NOTA

Se você estiver utilizando sua própria If you are using you own image you must have already set up a file share to which the Team Foundation Build process has access.

13. Clique em Process. O Source Control Explorer será exibido. A tela de seleção do template de processo build é nova no Visual Studio 2010. Ela define parâmetros a serem utilizados durante o processo de build. (Figura 89)





Figura 89 Defina informações sobre o processo de build

14. Clique na caixa de texto Items to build e clique em no botão . O diálogo Items to Build é exibido. Figura 90.

Figura 90 Diálogo Items to Build

15. Clique em Add. No diálogo browse, vá até o caminho $/HOL_DatabaseProjects/BuildAndDeploy/AdventureworksDB e selecione AdventureworksDB.sln como sendo a solução para o build. Clique em OK para aceitar a seleção. Você deve ver agora o sumário mostrado na Figura 91 .





Figura 91 Solução selecionada para o build

16. O Team Foundation Build descobre quais são os testes a serem executados através das opções definidas na seção Automated Test. Por padrão o Team Foundation Build utiliza uma máscara para identificar quais testes devem ser executados. Conforme mostra a Figura 92 o valor da mascara é **\*test*.dll. Como não temos nenhum teste unitário neste projeto, o build irá ignorar esta seção.

17. Clique em Retention Policy. A política de retenção diz respeito a quantos builds são preservados para projetos de médio porte. A Figura 92 mostra os valores padrão. Não é necessário alterar nada nesta tela.

Figura 92 Configuração de política de retenção de build

18. Neste ponto o processo de definição de build está concluído. Após clicar em Save no menu principal (ou pressionar CTRL+S), a nova definição de build aparece dentro da pasta build no Solution Explorer. (Figure 93)





Figure 93 A nova definição de build criada





Passo 2: Enfileire um novo build a partir da definição

Agora que criamos a definição de build iremos criar uma nova instância da definição de build, inserida na fila de build.


1. No Team Explorer, clique com o botão direito na nova definição de build AdventureWorksExample. A tela é exibida conforme mostrado na Figura 94.

Figura 94 Ações relativas à definição de Build

2. Selecione Queue New Build. O diálogo Queue Build “HOL_DatabaseProject” é exibido. (Figura 95)

Figura 95 Diálogo Queue Build





3. Clique em Queue para enfileirar o build desejado. O Build Explorer é exibido e na aba Queued são listados os builds atualmente enfileirados. (Figura 96)

Figura 96 O build é exibido no Build Explorer





Passo 3: Verifique o progresso dos builds

Agora que enfileiramos o novo build iremos visualizar como verificar o build sendo executado, bem como o histórico de builds previamente executados.


1. No Build Explorer, dê um duplo-clique no build (Figura 96) para ver mais detalhes sobre o build. (Figura 97)

Figura 97 Progresso do build atualmente sendo executado

2. Após o build ser concluído, uma tela similar a Figura 98 aparece.





Figura 98 Build bem sucedido na fila de build

3. Para ver as saídas dos builds, clique em View Log - Open Drop Folder.

Figura 99 Saída do build gerada





Build e deploy fora do team build

Resumo

Ocasionalmente, você pode não ter uma IDE disponível ou o Team Foundation Build para realizar o build do projeto. Nestes casos, o comando MSBUILD fará o trabalho por você. Você poderá realizar o build dos projetos e utilizar a saída do build para fazer o deploy do banco de dados. Esse cenário pode ser obtido com apenas alguns passos

Objetivos do cenário

Aprender como realizar o build dos projetos de banco de dados com o MSBuild Fazer o deploy utilizando VSDBCMD

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB

Pré-requisitos: Para completar o passo do deployment ao final, você precisa ter o banco de dados Adventureworks na máquina local. Se for necessário restaruar o banco de dados execute o comando C:\HOL\DatabaseProjectGuidance\HOLSetup\RestoreDatabase\StartAdventureWorksRestoration.cmd

NOTA

Antes de iniciar este laboratório, é importante compreender que quando um projeto é compilado através do Visual Studio, uma chamada é feita em segundo plano para o MSBuild.

O MSBuild é o motor de build responsável por compilar código baseado nas informações contidas nos arquivos de projeto fornecidos (.dbpro, csproj, etc). Os projetos de banco de dados do Visual Studio não são exceção. Eles também são compilados através do MSBuild.

O MSBuild pode ser invocado a partir da linha de comando para compilar um projeto da mesma forma que a IDE do Visual Studio faz. Adicionalmente, o MSBuild pode ser parametrizado para suportar cenários mais complexos de build.

Siga estes passos para compilar o Adventureworks através do MSBuild.






Passo 1: Faça o build do projeto de banco de dados com o MSBUILD

1. Abra o Visual Studio Command prompt. Clique em Start, aponte para All Programs, aponte para Microsoft Visual Studio 2010 point to Microsoft Visual Studio 2010 Tools e então clique em Visual Studio Command Prompt (2010). A janela a seguir será exibida.

Figura 100 Visual Studio Command Prompt (2010)

NOTA

A parte importante é que se você abrir o Visual Studio command prompt ao invés do prompt de comando padrão, você terá todas as variáveis de ambiente necessárias já definidas para acessar as aplicações de desenvolvimento relevantes. Se você estiver em uma máquina que não possui o Visual Studio instalado é possível econtrar o MSBUILD.EXE na pasta do Framework .Net localizada em C:\Windows\Microsoft.NET\[FrameworkVersion].





Passo 2: Faça o deploy do banco de dados com o VSDBCMD

1. Faça o build do projeto executando o comando a seguir:

MSBuild C:\HOL\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDBAdventureworksDB.dbproj

O MSBuild será executado, compilando o projeto de banco de dados e enviando a saída (.dbschema e arquivos de propriedades) para o diretório de saída padrão.

2. Execute uma comparação de Schema utilizando o VSDBCMD e cria o script com o “delta”.

3. Vá até o caminho do VSDBCMD.exe execute o comando a seguir:

VSDBCMD.exe /a:Deploy /cs:"Data Source=.;Integrated Security=True;Pooling=False" /dsp:Sql /model:"C:\HOL\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\sql\debug\AdventureworksDB.dbschema" /p:TargetDatabase=AdventureWorks2008 /p:SqlCommandVariablesFile="C:\hol\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\sql\debug\AdventureworksDB_Database.sqlcmdvars" /manifest:"C:\hol\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\sql\debug\AdventureworksDB.deploymanifest" /script:"C:\hol\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\AdventureworksDB_Database_Delta.sql" \AdventureWorks.sql

O script com o “delta” resultante será gerado na pasta C:\hol\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\AdventureworksDB_Database_Delta.sql" \AdventureWorks.sql.

4. Faça o deploy do script “delta” executando o comando a seguir:

sqlcmd –i C:\hol\DatabaseProjectGuidance\BuildAndDeploy\AdventureworksDB\AdventureworksDB_Database_Delta.sql

Isso executa o deploy do script “delta” no banco de dados de destino.

NOTA

O deployment também pode ser feito utilizando o parâmetro /dd+ no VSDBCMD. Isso irá automaticamente realizar a comparação de schema e executar o deploy das mudanças no banco de dados utilizado para comparação. As opções adicionais também podem ser investigadas na seção “Cenário – Encontrando Alterações de Modelo”.





Testes de Banco de Dados e Verificação de Deployment

O Cenário “Básico” de Criação de Testes Unitários

Resumo

O fluxo de trabalho coberto neste documento simula a execução de tarefas típicas de um desenvolvedor tentando validar sua aplicação de banco de dados. Como todos os laboratórios neste guia, utilizaremos o banco de dados Adventureworks.


Familiarizar desenvolvedores com as capacidades dos Testes Unitárioso Customizando condições de testeo Adicionando testes adicionaiso Executando Testes Unitários

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\VerificationAndTesting\UnitTesting\BasicUnitTesting

Local dos arquivos finais:C:\HOL\DatabaseProjectGuidance\VerificationAndTesting\UnitTesting\BasicUnitTesting_Answer

Duração Estimada: 5 minutos

Passo 1: Crie um teste unitário a partir de um modelo

Para criar um projeto de teste simples, iremos extender o projeto AdventureworksDB. Este projeto já está presente no nosso diretório do HOL.

a. Inicie o Visual Studio 2010.b. No menu principal, clique em File e então clique em Open project. Vá até o projeto localizado em

C:\HOL\DatabaseProjectGuidance\Verification and Testing\UnitTesting\BasicUnitTesting e abra o arquivo em AdventureWorksDB.sln.

A única forma na qual testes unitários de banco de dados podem ser adicionados é através do Schema view.

O Schema view pode ser acessado de duas formas. A mais comum é através do ícone schema view localizado na barra de ferramentas do Solution Explorer. (Figura 101)

Figura 101 Botão Schema view no Solution Explorer

Uma outra maneira de acessar o Schema view é através do menu View, através do menu principal:




C:\\HOL\\DatabaseProjectGuidance\\VerificationAndTesting\\UnitTesting\\ \\BasicUnitTesting

C:\\HOL\\DatabaseProjectGuidance\\VerificationAndTesting\\UnitTesting\\ \\BasicUnitTesting


View, Database Schema View (Figura 102)

Figura 102 Acessando o Database Schema View através do menu principal do Visual Studio

A janela schema view do banco de dados será exibida. (Figura 103)

Figura 103 Janela Database Schema View exibindo os objetos inclusos.

Expanda o nó Schemas, dbo, Programmability e então clique com o botão direito na pasta Stored Procedures no Schema view. O seguinte menu de contexto é exibidoconforme a Figura 104.

Figura 104 Menu de contexto no Schema view





Selecione o item Create Unit Tests. O diálogo Create Unit Tests será exibido. (Figura 105) Testes unitários podem ser inseridos em um projeto de testes existente. Como não temos nenhum projeto

de testes na nossa solução neste momento, iremos criar um novo projeto e novas classes de teste unitário. Digite as informações a seguir:

Project: selecione a opção new Visual C# test project. New project name: Digite AdventureWorksDatabaseTests Current Selection: Selecione apenas o item dbo.uspGetEmployeeManagers.

Após concluir os passos acima o diálogo deve estar conforme a Figura 105.

Figura 105 Diálogo Create Unit Tests com as informações necessárias preenchidas





NOTA

Para este laboratório nós iremos testar uma stored procedure. Contudo, a partir desta interface você pode adicionar outras funções de banco de dados que deseja testar.

Clique em OK. O diálogo de configurações de testes unitários do projeto é exibido.

Neste tela você irá definir as configurações para os testes de banco de dados. Para este laboratório as configurações a seguir devem ser selecionadas:

Execute Unit Tests Using the following data connection: Selecione a conexão AdventureWorks2008.

Automatically Deploy the database project before unit tests are run: Marque esta opção. Database Project: Selecione o projeto AdventureWorksExample.dbproj Deployment Configuration: Selecione o item Debug

Após completar a configuração o diálogo deve estar como na imagem a seguir:

Figura 106 Configurações de teste unitário de banco de dados preenchidas

Clique em OK. Isso completa a criação do projeto de testes unitários para a SP dbo.uspGetEmployeeManagers. O diálogo deve estar similar ao exibido na Figura 107.





Figura 107 Modelo padrão de teste unitário aberto após a criação





Passo 2: Adicione condições de teste para o teste unitário

Após a criação do projeto de testes e do teste unitário você pode especificar que tipo de teste será executado. As condições de teste padrão são:

Data Checksum: Gera um checksum dos dados retornados para que possam ser comparados cada vez que o teste unitário é executado.

Empty Resultset: Valida se o retorno de execução está vazio. Execution Time: A duração do teste deve ser menor do que o tempo especificado. Expected Schema: O schema do retorno deve coincidir com o schema definido. Inconclusive: O resultado do teste será sempre inconclusivo. Non Empty Resultset: O retorno de execução não deve conter dados. Row Count: O retorno de execução deve conter um número específico de linhas. Scalar Value: O retorno de execução deve ser um valor escalar específico.

Mais informações podem ser econtradas na documentação MSDN Using Test Conditions in Database Unit Tests.6

Neste passo iremos adicionar uma condição de teste do tipo data checksum para garantir que o os dados retornados no teste corresponda um conjunto de dados específico.

1. Anteriormente, nós abrimos um modelo de teste unitário para stored procedure. Agora vamos alterar o modelo e definir o valor da variável @BusinessEntityID de 0 para 3. (Figura 108)

Figura 108 Variável alterada no template

2. Nas condições de teste exibidas na janela abaixo, remova a condição Inconclusive selecionando-a e clicando no ícone .

3. Selecione o item Data Checksum na lista de checksums disponíveis e clique no botão . Isto irá adicionar uma condição do tipo Checksumcondition ao teste.

6 http://msdn.microsoft.com/en-us/library/aa833423(VS.80).aspx






Figura 109 Adicionando uma condição de teste do tipo checksum

Se você observar o valor da condição verá a mensagem “The expected checksum needs to be configured” (O checksum esperado precisa ser configurado). Para configurar o checksum, selecione as condições de teste e vá para a janela Properties (dependendo da sua configuração, isso pode ser acessado pressionando F4). Com isso a tela de propriedades será exibida conforme Figura 110.

Figura 110 Janela de configuração de propriedades da condição de teste do tipo checksum

4. Na seção Configuration clique no botão ao lado da texto “Press to configure”. A janela será exibidia conforme a Figura 111:

Figura 111 Janela de configuração da condição checksum





5. Na janela de configuração do checksum selecione a conexão de banco de dadose confirme que @BusinessEntityID = 3 esteja definido no código exibido.

6. Clique em Retrieve para obter o schema resultante para o qual o checksum será calculado. A janela deve estar similar a Figura 112.

Figura 112 Editor de configurações de checksum exibindo o schema resultante

7. Clique em OK para gerar o checksum a partir dos dados exibidos. A janela retornará para as condições de teste. Se você observer atentamente poderá ver que o campo Value foi atualizado com o checksum. (Figura 113)

Figura 113 Condição de teste atualizada com o novo valor de checksum

8. Com isso fianlizamos a inclusão da condição de teste. Agora você pode executar o teste utilizando o Test Explorer. Clique em Test, clique em Windows e então clique em Test view. Selecione o teste relevante clicando com o botão direito e selecione Run selection.





O Cenário “Avançado” de Criação de Testes Unitários

Resumo

Nesta seção iremos continuar o cenário básico, adicionando técnicas avançadas de teste de forma a auxiliar a geração de dados de teste, habilitar testes de qualidade contra o código, garantindo a qualidade dos artefatos e sua interoperabilidade.


Suporte a múltiplos desenvolvedores utilizando diferentes configurações Utilização de transações para melhoria de performance Utiliação de planos de geração de dados (Data Generation Plans) Execução de um teste de performance

Local dos arquivos iniciais: C:\HOL\DatabaseProjectGuidance\VerificationAndTesting\UnitTesting\ AdvancedUnitTesting

Local dos arquivos finais: C:\HOL\DatabaseProjectGuidance\VerificationAndTesting\UnitTesting\ AdvancedUnitTesting_Answer


Passo 1: Configure o ambiente para múltiplos desenvolvedores

O Visual Studio 2010 lhe dá a habilidade de sobrescrever as configurações padrão quando os testes são executados. Isto é tipicamente utilizado em dois cenários diferentes:

Quando há múltiplos desenvolvedores com configurações diferentes A máquina de build precisa executar os testes contra um banco de dados diferente.

Esta seção do laboratório avançado lhe mostrará como preparar o ambiente para suportar difierentes opções de configuração.

1. Abra o Visual Studio 2010.2. Abra a solução do Adventure Works que utilizamos no laboratório anterior.3. Abra o arquivo app.config no projeto de teste. Dentro da configuração você irá encontrar uma seção

<DatabaseUnitTesting>. Neste seção, adicione o atributo AllowConfigurationOverride no element DatabaseUnitTesting com o valor definido para true. Depois disso, o código deve estar como abaixo:

<DatabaseUnitTesting AllowConfigurationOverride=”true”>.

NOTA

Ao definir este valor estamos especificando que desejamos sobrescrever a configuração da aplicação com outro arquivo.





4. O próximo passo é adicionar uma nova configuração. Adicione um novo arquivo .xml ao projeto de testes clicando em Add new Item e então clique em Select XML file. Nomeie o arquivo como TFSBuild.dbunittest.config.

5. Abra o arquivo .xml e copie o conteúdo do arquivo app.config para este novo arquivo.

6. Altere a string de conexão para que o catálogo inicial em <ExecutionContext> e <PrivilegedContext> sejam “AdventureWorksBuildTests” conforme o exemplo a seguir:

<ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.;Initial Catalog=AdventureWorksBuildTests;Integrated Security=True;Pooling=False" CommandTimeout="30" /> <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.;Initial Catalog=AdventureWorksBuildTests;Integrated Security=True;Pooling=False" CommandTimeout="30" />

7. Abaixo da Solução, na pasta Solution Item você irá encontrar um arquivo chamado local.testsettings. Dê um duplo-clique no arquivo para abrir a janela “Test Settings”. De forma alternative, vá até o item de menu Test, clique em Edit Test Settings e então clique em Local (local.testsettings).

8. Selecione a opção Deployment, selecione Enable deployment e adicione o arquivo de configuração que você criou no passo 4. Para adicionar o arquivo de configuração, clique em Add File e vá até o arquivo TFSBuild.dbunittest.config. (Figura 114)

Figura 114 Alterando as configurações de deployment





Quando os testes unitários são executados no servidor de build, o agente de build seleciona o arquivo de configuração baseado na opção “AllowConfigurationOverride” e então utiliza o nome da máquina ou ou nome da conta de execução para carregar o arquivo apropriado.

Passo 2: Deployment do banco de dados de teste

1. No Solution Explorer, clique com o botão direito no projeto de banco de dados e selecione Properties.

2. Altere a opção Deploy action para Create a deployment script (.sql) and deploy to the database.

3. Na aba Deploy, clique em Edit, próximo ao campo Target connection para especificar uma conexão SQLConnection válida para o deployment. Digite um ponto final (.) para o nome do servidor e então clique em OK para fechar o diálogo de conexão.

4. Na aba Deploy, digite AdventureWorksExample para o nome do banco de dados a ser criado no deployment.

5. Clique com o botão direito na solução e selecione Deploy para realizar o deployment do banco de dados especificado. Você verá o progresso do deployment na janela Output do Visual Studio.

6. Confirme que o banco de dados foi criado abrindo o Server Explorer e navegando até a conexão AdventureWorksExample. Confirme que os artefatos (tabelas, stored procedures, etc.) foram criados conforme definido no projeto original do banco de dados AdventureWorks.





Passo 3: Gerando dados de teste

1. Ao testar unitariamente um banco de dados é importante garantir que o banco de dados está em um estado consistente antes e depois da execução dos testes. Este passo irá mostrar como criar um plano de geração de dados básico que popula o banco de dados com dados consistentes a cada execução deployment.

2. Comece clicando com o botão direito no projeto de banco de dados no Solution Explorer, selecione Add e então clique em Data Generation Plan.(Figura 115)

Figura 115 Adicionando um plano de geração de dados através do menu de contexto do projeto

3. No diálogo Add New Item, selecione Data Generation Plan a partir da lista de templates. Dê o nome ao plano de EmployeeData.dgen. (Figura 116)





Figura 116 Adicionando um novo plano de geração de dados

4. Clique em Add. Após o plano ter sido carregado, clique com o botão direito na lista de tabelas e selecione Exclude All Tables from Data Generation e então selecione somente a tabela HumanResources.Employee. Note que as tabelas dependentes Person.Contact, Person.BusinessEntity, Person.Person também são marcadas para geração.

5. Clique com o botão direito na tabela HumanResources.Employee e selecione Preview Data Generation. A janela Data Generation Preview será exibida mostrando os dados que serão gerados utilizando este plano.

6. Execute o plano através do menu do Visual Studio, clicando em Data, Data Generator e então em Generate Data. Selecione AdventureWorksExample a partir da lista de bancos de dados no diálogo Connect to Database e clique em OK. Se você quiser excluir qualquer dado existente, clique em Yes ao ser solicitado.

7. Após a execução do plano de geração de dados você irá notar que diversas tabelas terão indicadores verdes denotando que a execução do plano foi bem sucedida para estar tabelas. Perceba que duas tabelas estão marcadas com um x vermelho. São elas HumanResources.Employee e Person.Person. O indicador verde são referents as tabelas que tiveram qualquer dado excluído. Essas tabelas possuem chaves estrangeiras nas tabelas HumanResources.Employee ou Person.Person. O erro resultante diz respeito à incompatibilidade entre os dados gerados e as colunas nas tabelas.

8. Feche a janela Data Generation Population e retorne ao plano de geração de dados. Selecione a tabela Person.Person e na janela de seleção de colunas limpe o conteúdo das colunas AdditionalContactInfo e Demographics. Isso irá interromper a geração de dados para estas colunas.

9. Selecione a tabela HumanResources.Employee. A geração dos dados para diversas colunas irá falhar para esta tabela devido ao fato de que os dados não estão em conformidade com as constraints de algumas colunas. Nós iremos ignorar a maioria destas colunas e corrigir os dados para uma delas.

10. Limpe a seleção das colunas SalariedFlag, VacationHours, SickLeaveHours e CurrentFlag.





11. Selecione a coluna BirthDate e abra a janela Properties pressionando F4. Na janela Properties, defina o campo Max value para 12/31/1990 e Min field para 1/1/1930.

12. Selecione MaritalStatus e altere o gerador (Generator) nas colunas para serem Regular Expression. Na expressão digite o valor M|S que fará com sejam gerados somente os valores M ou S.

Figura 117 Na janela Properties altere o valor da expressão para gerar somente “M” ou “S”

13. Selecione a coluna Gender e altere o item na coluna Generator para Regular Expression. Informe M|F para o valor da expressão, de forma que sejam gerados somente os valores “M”ou “F”.

14. Selecione a coluna HireDate. Na janela Properties, altere Max value para 12/30/2009 12:00:00 AM e Min value para 7/1/1996 12:00:00 AM.

15. Selecione a tabela Person.Person. A geração dos dados para diversas colunas irá falhar para esta tabela devido ao fato de que os dados não estão em conformidade com as constraints de algumas colunas. Nós iremos ignorar a maioria destas colunas e corrigir os dados para uma delas.

16. Selecione a coluna PersonType e altere o gerador da coluna para Regular Expression. Para a expressão digite o valor GC|SP|EM|IN|VC|SC que restringirá a geração dos valores ao conjunto GC, SP, EM, IN, VC ou SC.

17. Execute o plano de geração de dados clicando no menu Data do Visual Studio. Selecione a opção Data Generator e então clique em Generate Data. Escolha o banco de dados AdventureWorksExample na lista de bancos de dados no diálogo Connect to Database e clique em OK. Caso queira excluir qualquer dado pré-exisitente clique em Yes ao ser solicitado.





Passo 4: Testes de Performance Simples

Agora que geramos dados para o banco de dados, iremos executar alguns testes de performance.

1. Abra o teste unitário que você criou no cenário anterior e dê um duplo-clique no arquivo DatabaseUnitTest1.cs no projeto de teste.

2. Para adicionar um tempo máximo de execução para o teste, sob Test Conditions, selecione Execution Time e clique no ícone com o sinal de + verde.

Note que o valor estipula que o teste deve ser executado no tempo máximo de 00:00:30.

3. Na janela Properties, digite o valor 00:00:00.500. Isso indica que o teste somente será considerado bem sucedido se for executado em no máximo meio segundo. Ao adicionar esse tipo de condição aos testes é possível monitorar de forma contínua a performance de execução. Ao associar a execução destes testes a geração de dados é possível simular bancos de dados de diversos tamanhos e avaliar a performance sob estas condições.

4. Agora você pode executar o teste utilizando o Test Explorer. Vá até o novo teste abrindo a janela Test view. Para abrir esta janela, clique no menu Test, clique em Windows e então clique em Test view. Selecione o teste desejado clicando com o botão direito e selecione a opção Run selection.





Cenário – Encontrando Alterações de Modelo

Resumo

Após o banco de dados ter sido publicado em produção ocorrem situações específicas quando o ciclo de desenvolvimento é quebrado. Pode haver casos em que seja necessário alterar diretamente o schema do banco de dados de produção, como procedures, índices, etc., no intuito de aplicar correções emergenciais para um bug severo descoberto durante o ciclo de desenvolvimento. Embora estes casos devam ser exceções, a realidade nos mostra que isso ocorre a todo tempo e, pior ainda, as correções não são propagadas adequadamente para o desenvolvimento, testes futuros, controle de código-fonte e novas funcionalidades. Este tipo de situação traz diversos problemas a qualquer ciclo de desenvolvimento após a alteração. Pense nas situações a seguir que são muito comuns se você lida com clientes que não possuem um ciclo de desenvolvimento com processos claros e bem definidos:

Após o deployment da versão 1 do banco de dados, o administrador de banco de dados percebeu que as queries estão sendo executadas com muita lentidão, causando gargalos de memória, IO e ciclos de CPU. Ele investigou os planos das queries e descobriu que falta um índice para uma tabela em particular, forçando o SQL Server a realizar operações custosas de table scan. Para resolver o problema o nosso eficiente DBA criou um índice na tabela para satisfazer as queries lentas, tornando os processos de consulta mais rápidos. Infelizmente ele não informou os desenvolvedores sobre a adição deste índice, tampouco fez o check-in de suas alterações no Team Foundation Server. Com o desenvolvimento da versão 2 do banco de dados o VSDBCMD reconhece que o índice não faz parte do arquivo .dbschema utilizado no deployment, removendo o índice “desnecessário” que causa a falta de sincronia para a tabela específica. Obviamente isso fará com que o problema de lentidão do início dessa história volte a ocorrer. Pense na mesma situação ocorrendo para uma stored procedure que causa deadlocks no banco de dados, ou em outros problemas severos sendo corrigidos temporariamente pelo DBA e que serão continuamente desfeitos a cada publicação de nova versão do banco de dados.

Em alguns casos o processo de deployment do banco de dados não inclui o uso do comando VSDBCMD diretamente antes do deployment porque os DBA’s tem medo de executá-lo contra um banco de dados rodando em produção. Neste caso você constrói o script de deployment em outra máquina, leva-o para a máquina de produção e então executa o script. Neste caso você assume que o schema esperado é exatamente o mesmo publicado na versão 1 (ou na última versão publicada). Contudo, o arquivo .dbschema foi construído e testado partindo da premissa de que o schema em produção é o mesmo publicado no último deployment. Considerando as alterações feitas diretamente em produção, das quais o time de desenvolvimento não tem notícia, o atual script de deployment poderá falhar.

Esta lista de cenários é interminável e sempre há situações de altíssimo estresse no time, onde o único objetivo a ser alcançado é concluir as tarefas e corrigir os bugs. Não é muito difícil perder o controle das mudanças feitas durante esse período.

Em grandes projetos, o time de Build é responsável por prover os bits para o procedimento de deployment. Eles criam os artefatos relevantes a partir dos projetos e os coletam do BuildDrop (local onde o resultado do build é copiado) para entregar aos DBA’s. O time de build não se envolve com o deployment do banco de dados em produção e raramente os DBA’s se importam com o que acontece em desenvolvimento, controle de código-fonte e testes.





Figura 118 Ilustração do caminho comum dos arquivos para deployment

A situação é sempre a mesma. Você já realizou o deployment da versão 1 do banco de dados e agora quer atualizar o banco de dados para a versão 2 (upgrade). Nós iremos apresentar abordagens diferentes para encontrar desvios de modelo, bem como quando utilizar cada uma delas. Você irá notar que estas abordagens tratam diferentes níveis de paranóia e até de confiança entre as pessoas e a deployment engine. A escolha final é uma questão de experiência e depende de diversos fatores como o determinismo das mudanças, como as pessoas conduzem o ciclo de vida do banco de dados, o quão severo é a auditoria dos processos de mudança e deployment, etc. Há ainda fatores como o tamanho do banco de dados, disponibilidade de backups, tempos de restauração e janelas de manutenção, que influenciam nas decisões sobre como reagir no caso de um erro de deployment e no tempo necessário para se reestabelecer o estado anterior do banco de dados.

Confiança é bom, controle é melhor. Embora você possa perguntar ao DBA se algo mudou desde o último deployment da versão 1 do banco de dados, você deveria verificar novamente para ter certeza de que nada ficou de fora, mesmo as mudanças menores que podem não ser relevantes para o DBA, mas que para você podem causar grandes problemas. Adicionalmente, o DBA pode ter confiança nos produtos, mas não deseja que o desenvolvedor execute o VSDBCMD no banco de dados de produção. Consequentemente, ele irá extrair o atual schema de produção e enviar para os desenvolvedores para que eles possam comparar ao schema que ficou registrado na última versão, imediatamente antes do deployment da versão 1. Co isso, podemos ter certeza de que nenhum comportamento inesperado ocorra.





RECOMENDAÇÃO

Descobrir desvios de modelo antes da execução do deployment pode ser sua garantia contra estes problemas durante o deployment. Sugerimos que sempre sejam executados procedimentos de verificação em busca de desvios de modelo antes da execução de um deployment em produção.

Para um ciclo de desenvolvimento de banco de dados perfeito, seria ótimo se fosse possível congelar o schema em produção de forma que pudéssemos nos apoiar sob um schema estável em execução. Caso isso não seja possível em virtude de mudanças inesperadas para correção de problemas, no mínimo precisamos garantir a comparação dos schemas ANTES da execução de qualquer deployment.

Se você puder organizar esta tarefa, é interessante até realizar comparações regulares, independentes de deployment, com o intuito de verificar se não há alterações em produção que precisam ser portadas para o desenvolvimento.





Objetivos Gerais do Cenário

Familiarização com o comando VSDBCMD e suas capacidades para: o Encontrar diferenças nos modeloso Encontrar diferenças entre modelo versus banco de dadoso Realizar o deploy da solução utilizando o VSDBCMD


Cenário 1: Garanta que você testou seu banco de dados com a versão correta de produção SEM ter acesso ao ambiente de produção (Versão confiável do DBA)

1. Extraia o schema atual do banco de dados de produção

Administradores de banco de dados muitas vezes tratam os bancos de dados como se fossem seus filhos. O resultado disso é que eles não querem que ninguém do time de build ou desenvolvimento os toquem. Além disso, há casos onde o banco de dados contém informação sensível e o acesso é restrito a um pequeno gurpo de pessoas. Isso coloca o desenvolvedor na situação onde é necessário instruir o DBA sobre como procurar por desvios de modelo. O comando no passo “c” é o comando que você deve enviar ao DBA para que ele possa executá-lo e lhe devolver o arquivo .dbschema resultante, facilitando o processo de busca por desvios de modelo.

a. Abra o prompt de comando do Visual Studio. Clique em Start, aponte para All Programs, aponte para Microsoft Visual Studio 2010, aponte para Microsoft Visual Studio 2010 Tools e clique em Visual Studio Command Prompt (2010).

b. Localize a pasta C:\HOL\DatabaseProjectGuidance\Verification and Testing\ModelDrift\Scenario1

c. Extraia o schema de banco de dados utilizando o comando VSDBCMD a seguir:

vsdbcmd /action:Import /dsp:sql /modelfile:.\TheVersionExtractedBeforeDeployment.dbschema /cs:"Data Source=.;Initial Catalog=AdventureWorksDB;Integrated Security=True"

Isso irá extrair o schema e gerar um arquivo de modelo na pasta atual.

2. Compare o schema versionado com o schema extraído do modelo atual de produção.

a. Agora iremos comparar o modelo de banco de dados extraído de produção com o modelo do nosso sistema de controle de código-fonte. Este modelo pode tanto ser o modelo do momento em que publicamos a versão 1, sob o qual continuamos o desenvolvimento para a versão 2 ou qualquer branch para hotfixes que corresponda ao sistema atualmente em produção, caso os hotfixes tenham sido propagados para o ciclo de desenvolvimento.





vsdbcmd /action:Deploy /dsp:sql /modelfile:.\V1SchemaOfTheDatabase_WeBuildOurDevelopmentAndTestingOn.dbschema /DeploymentScriptFile:.\V1_Model_Drift_DeployScript.sql /p:TargetDatabase=AdventureWorks2008 /Targetmodel:.\TheVersionExtractedBeforeDeployment.dbschema

Você irá notar que utilizamos o parâmetro /DeploymentScriptFile na chamada da linha de comando. Isso irá instruir o deployment para não aplicar as alterações, apenas criando o arquivo com o script necessário para sincronizar o arquivo especificado como TargetModelFile com o arquivo especificado como SourceModel. Se nenhuma mudança foi realizada após a versão 1, seja em em produção ou em desenvolvimento, podemos ter certeza de que realizamos testes com uma versão estável.

b. Abra o arquivo V1_Model_Drift_DeployScript.sql no diretório atual.

c. Enquanto rola pelo arquivo .sql, você verá que nenhuma mudança é feita ao banco dados. De fato, o único conteúdo do arquivo diz respeito a checagem do ambiente alvo do deployment e preparação do script através da definição de algumas variáveis. A parte do script que faz as alterações, geralmente vem logo após o comando USE DATABASENAME, está vazia. Assim podemos ter certeza de que nenhuma mudança foi feita no tempo transcorrido entre o último deployment.

/*Deployment script for AdventureWorks2008*/

GOSET ANSI_NULLS, ANSI_PADDING, ANSI_WARNINGS, ARITHABORT, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER ON;

SET NUMERIC_ROUNDABORT OFF;

GO:setvar DatabaseName "AdventureWorks2008":setvar DefaultDataPath "":setvar DefaultLogPath ""

GOUSE [master]

GO:on error exitGOIF (DB_ID(N'$(DatabaseName)') IS NOT NULL AND DATABASEPROPERTYEX(N'$(DatabaseName)','Status') <> N'ONLINE')BEGIN RAISERROR(N'The state of the target database, %s, is not set to ONLINE. To deploy to this database, its state must be set to ONLINE.', 16, 127,N'$(DatabaseName)') WITH NOWAIT RETURNEND

GO

IF NOT EXISTS (SELECT 1 FROM [master].[dbo].[sysdatabases] WHERE [name] = N'$(DatabaseName)')BEGIN RAISERROR(N'You cannot deploy this update script to target . The database for which this script was built, AdventureWorks2008, does not exist on this server.', 16, 127) WITH NOWAIT RETURNEND

GO





IF (@@servername != '')BEGIN RAISERROR(N'The server name in the build script %s does not match the name of the target server %s. Verify whether your database project settings are correct and whether your build script is up to date.', 16, 127,N'',@@servername) WITH NOWAIT RETURNEND

GO

IF CAST(DATABASEPROPERTY(N'$(DatabaseName)','IsReadOnly') as bit) = 1BEGIN RAISERROR(N'You cannot deploy this update script because the database for which it was built, %s , is set to READ_ONLY.', 16, 127, N'$(DatabaseName)') WITH NOWAIT RETURNEND

GOUSE [$(DatabaseName)]

GO

NOVA FUNCIONALIDADE

O VSDBCMD introduziu a nova opção de comparação entre modelos no Visual Studio 2010 para tornar mais fácil realizar uma comparação “offline” dos schemas referentes a qualquer conexão de banco de dados.





Cenário 2: Certifique-se de que você testou a aplicação de banco de dados com a versão obtida, COM acesso ao banco de dados (Versão confiável do desenvolvedor)

Desta vez iremos comparar diretamente o modelo da nossa versão 1 arquivada com a versão atualmente em produção. Nós não iremos criar o modelo primeiro para depois fazer uma comparação modelo versus modelo, uma vez que isso requer que o DBA tenha alguma fé nos desenvolvedores e que estes, por sua vez, utilizem as opções corretas do VSDBCMD para apenas criar o script de upgrade, ao invés de aplicá-lo ao banco de dados de destino.

1. Compare o schema de banco de dados versionado com o schema atual do banco de dados de produção.

a. Abra o prompt de comando do Visual Studio. Clique em Start, aponte para All Programs, aponte para Microsoft Visual Studio 2010, aponte para Microsoft Visual Studio 2010 Tools e clique em Visual Studio Command Prompt (2010).

b. Vá para a pasta C:\HOL\DatabaseProjectGuidance\Verification and Testing\ModelDrift\Scenario2

c. Agora iremos comparar o modelo de banco de dados extraído de produção com o modelo do nosso sistema de controle de código-fonte. Este modelo pode tanto ser o modelo do momento em que publicamos a versão 1, sob o qual continuamos o desenvolvimento para a versão 2 ou qualquer branch para hotfixes que corresponda ao sistema atualmente em produção, caso os hotfixes tenham sido propagados para o ciclo de desenvolvimento.

vsdbcmd /action:Deploy /dsp:sql /modelfile:.\V1SchemaOfTheDatabase_WeBuildOurDevelopmentAndTestingOn.dbschema /DeploymentScriptFile:.\v1_model_Drift_DeployScript.sql /p:TargetDatabase=AdventureWorks2008 /cs:"Data Source=.;Integrated Security=True"

d. Abra o arquivo V1_Model_Drift_DeployScript.sql no diretório atual.

e. Enquanto rola pelo arquivo .sql, você verá que nenhuma mudança é feita ao banco dados. De fato, o único conteúdo do arquivo diz respeito a checagem do ambiente alvo do deployment e preparação do script através da definição de algumas variáveis. A parte do script que faz as alterações, geralmente vem logo após o comando USE DATABASENAME, está vazia. Assim podemos ter certeza de que nenhuma mudança foi feita no tempo transcorrido entre o último deployment

NOTA

Esta estratégia não serve apenas como uma forma de encontrar desvios de modelo, mas também como ferramenta para aplicar as mudanças no banco de dados através de scripts. Muitas pessoas preferem criar um script baseado nas mudanças do schema, inspecioná-lo manualmente e aplicá-lo através do SQL Server Management Studio. Imagine que o modelo referenciado em /modelfile seja o modelo que deve ser publicado e que o banco de dados em ConnectionString seja o banco de dados de destino que será atualizado. Para um deployment que inclua somente alterações simples de schema esta técnica pode funcionar. Caso você tenha pre/post scripts você precisa fazer referência ao arquivo de manifesto a ser utilizado no deployment através do parâmeto /ManifestFile.





Referências

Documentação Técnica de Design

A documentação técnica de design e arquitetura está disponível através de solicitação.

Vídeos

Uma série de videos de introdução técnica e de preparação para tecnolologias estão disponíveis.

Links Gerais

Visual Studio ALM Rangers Site

http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx

Team System Widgets

http://www.teamsystemwidgets.com

Videos for Team System

http://msdn.microsoft.com/en-ca/vsts2008/bb507749.aspx?wt.slv=topsectionsee




http://msdn.microsoft.com/en-ca/vsts2008/bb507749.aspx?wt.slv=topsectionsee

http://www.teamsystemwidgets.com/

http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx

Web viewVisual Studio ALM Rangers. Documentação: Projetos de Banco de Dados no Visual...

Documents

Transcript of Web viewVisual Studio ALM Rangers. Documentação: Projetos de Banco de Dados no Visual...