gestão da mudança de banco de dados e processo de compilação usando TFS [fechado]

Question

Qualquer pessoa usando o Team Foundation Server para gerenciar suas bases de dados? No momento, estamos usando a subversão. Equipe está reclamando que é difícil criar um processo de compilação no TFS e está se afastando dela.

Qualquer boas indicações, artigos, experiências?

Answer 1

gerenciamento de mudanças DB não tem muito a ver com sua escolha de sistemas de controle de versão, desde que você tem um em primeiro lugar. Claro, se você estiver usando ferramentas de gerenciamento de mudanças de MS você pode estar certo de que eles foram testados contra TFS eo resto da pilha desenvolvedor MS bastante bem. Isso é verdade se você usar DBPro ou as formas muito mais velhas / crappier de integração visto no "projeto de banco de dados" clássico VS ou do SQL Management Studio despojado ligações de projeto / solução. Mas não há nenhuma razão você não pode usar DBPro com o Subversion, ou portão vermelho com TFS para essa matéria.

O mesmo vale para a geração de construção. CC.NET vs Equipe Build, NAnt vs MSBuild, etc ... os MS oficiais ferramentas tendem a ser mais ou menos a par com a concorrência. Você não descreveram seu processo de implantação DB em muitos detalhes, mas eu não posso imaginar que seria significativamente mais difícil de script no MSBuild do que o que você está usando agora, se em tudo. Também não é difícil escolher diferentes conjuntos de ferramentas em diferentes pontos na pilha: você pode ter baseado em MSBuild unidade CC.NET constrói que usar implantação de linha de comando do Red Gate, ou qualquer outra combinação. Acontece que eu acho que a integração oferecido por degola para o mundo MS supera de longe as peculiaridades em qualquer ferramenta de um, mas a escolha está lá.

Deixe-me chegar ao ponto: parece que o principal problema não é técnico, mas recebendo DBAs para realmente adotar o controle de versão, em primeiro lugar. Se o seu "dev" e ambientes "prod" são as suas próprias entidades vivas, ao invés de máquinas genéricos definida exclusivamente com o resultado de algum processo de criação repetível, então você não está realmente usando o controle de versão no meu livro . Imagine se um desenvolvedor de cliente ocasionalmente mão-mexido as DLLs em várias máquinas em torno da empresa, em seguida, se queixou de que eles eram muito difícil para sincronizar; você pensaria que ele era louco.

Além disso, o investimento mais importante é chegar a um lugar onde nada é feito para um DB diretamente (mais do que você fuçar em% programfiles%). Se não está no repositório de origem, ela não existe.

Eu não penso como você chegar lá é tão importante. Você poderia escrever toda a sua cria e altera em Notepad, vê-los a partir da linha de comando, e ter o seu "processo de construção" ser um script shell de 2 linhas que concatena-los em um arquivo bem conhecido onde o script deploy sabe olhar . Ou você pode usar uma ferramenta extravagante como DBPro para amplificar a sua produtividade com o teste intellisense / unidade / desligada modelagem / etc. Há grandes motivos de cabeça o último sentido (especialmente se você acredita programação declarativa é algo por que lutar em geral), mas eu realmente acredito que o primeiro passo é a maior.

Answer 2

Estamos usando o Visual Studio 2008 Team Suite juntamente com TFS. Eu era capaz de importar nossas bases de dados em TFS com relativa facilidade. No entanto, eu descobri que a maioria da equipe (incluindo os DBAs) esquece de TFS atualização quando modificar um objeto no SQL.

Qualquer tipo de processo de construção vai contar com DB Pro para gerar scripts diferença entre o seu ambiente de dev e o ambiente de destino. Descobri que isso é problemático porque o nosso ambiente de dev não é um jogo limpo para o nosso ambiente de produção. As permissões são certamente diferente e temos uma série de outros casos em que as alterações foram aplicadas em dev / QA, mas nunca se mudou para prod (mas também nunca foram invertidas). Tentando isolar as alterações de um monte de outras alterações no DB Pro é um desafio porque a interface do usuário faz você excluir objetos do roteiro final (por isso, se você modificar 2 objetos e 1000 outros são diferentes, você tem que desmarcar os outros 1000 objetos). Além disso, a configuração da comparação esquema é muitas vezes feito em Ferramentas-> Opções enquanto outras ferramentas como Red Gate permitem que você configure a comparação na mesma tela que você iniciá-lo.

Eu acho que a ferramenta tem potencial, mas certamente precisamos de adaptar os nossos procedimentos e sistemas existentes para trabalhar com TFS. Além disso, depois de ter versões em seus objetos de banco de dados é inestimável, mesmo se não é de 100% até data.

Answer 3

Nós usamos TFS com a edição de banco de dados.

O script de criação de banco de dados tem scripts de pós para carregar dados Dev para o DB.

Nós fazemos implanta regulares ao ambiente DEV. Todos os desenvolvedores têm SQL instalado localmente e eles fazem o seu próprio Get Latest e Deploy.

No ambiente de teste de unidade, os Logins, Databases (OLTP e OLAP), replicação, pacotes de ETL, SQL Jobs, etc estão todos mobilizados para suas localizações individuais e tudo é semeado.

Os desenvolvedores não fazer nenhuma alteração fora e não vê-los em porque então a implantação para teste de unidade não funciona.

Answer 4

Há muita opinião mais sobre isso nesta questão Stack Overflow: Quais são os benefícios reais de Visual Database Studio Team System Edition (GDR)? (Eu não sei por que, mas minhas pesquisas me trouxe a esta pergunta em vez disso, e eu tive um monte de opiniões constatação de problemas com isso. Esperemos que esta ligação irá ajudar os outros realizando a mesma pesquisa.)