Atualizei minha postagem original abaixo para refletir as alterações nas versões mais recentes do SQL Source Control (3.0) e do SQL Compare (10.1).

Como essa pergunta foi feita há mais de um ano, minha resposta pode não ser tão útil para você, mas para outras pessoas que atualmente estão avaliando o SSC, pensei em dar meus dois centavos. Acabamos de começar a usar o SQL Source Control (SSC) e, no geral, estou bastante satisfeito com ele até agora. No entanto, ele tem algumas peculiaridades, especialmente se você estiver trabalhando em um ambiente de banco de dados compartilhado (em oposição a todos os desenvolvedores trabalhando localmente) e particularmente trabalhando em um ambiente legado onde os objetos no mesmo banco de dados são divididos aleatoriamente entre as equipes de desenvolvimento.

Para dar uma breve visão geral de como estamos usando o produto em nossa organização, estamos trabalhando em um ambiente compartilhado onde todos fazemos alterações no mesmo banco de dados de desenvolvimento, então anexamos o banco de dados compartilhado ao repositório de controle de origem. Cada desenvolvedor é responsável por fazer alterações nos objetos no banco de dados por meio do SQL Server Management Studio (SSMS) e, quando terminar, eles podem confirmar suas alterações no controle do código-fonte. Quando estamos prontos para implantar no staging, o build master (me) mescla o branch de desenvolvimento do código do banco de dados com o branch principal (staging) e então executa o SQL Compare usando a versão do repositório do branch principal do banco de dados como fonte e o live banco de dados de teste como destino e o SQL Compare gera os scripts necessários para implementar as alterações feitas no ambiente de teste. A preparação para implantações de produção funciona de maneira semelhante. Outro ponto importante a ser observado é que, devido ao fato de estarmos compartilhando o mesmo banco de dados com outras equipes de desenvolvimento, usamos um recurso interno do SSC que permite criar filtros em objetos de banco de dados por nome, tipo, etc. configurar filtros nos objetos de nossa equipe específica, excluindo todos os outros objetos, para que não cometamos acidentalmente as alterações de outra equipe de desenvolvimento quando fizermos nossas implantações.

Portanto, em geral, é um produto bastante simples de configurar e usar e é muito bom porque você está sempre trabalhando com objetos ativos no SSMS, em oposição a arquivos de script desconectados armazenados em um repositório de origem separado que correm o risco de ficar fora de sincronia . Também é bom porque o SQL Compare gera os scripts de implantação para você, para que você não precise se preocupar com a introdução de erros, como faria se estivesse criando os scripts por conta própria. E como o SQL Compare é um produto muito maduro e estável, você pode se sentir bastante confiante de que ele criará os scripts adequados para você.

Com isso dito, no entanto, aqui estão algumas das peculiaridades que encontrei até agora:

• O SSC é bastante falador em termos de comunicação com o servidor db para acompanhar os itens do banco de dados que estão fora de sincronia com o repositório de controle de origem. Ele pesquisa a cada poucos milissegundos e se você adicionar vários desenvolvedores todos trabalhando no mesmo banco de dados usando SSC, você pode imaginar que nossos dba não ficaram muito felizes. Felizmente, você pode reduzir facilmente sua frequência de pesquisa para algo mais aceitável, embora ao custo de sacrificar notificações visuais responsivas de quando os objetos foram alterados.
• Usando o recurso de filtragem de objetos, você não pode dizer facilmente, observando objetos no SSMS, quais objetos estão incluídos em seu filtro. Portanto, você não sabe ao certo se um objeto está sob controle de origem, ao contrário do Visual Studio, onde os ícones são usados ​​para indicar objetos controlados por origem.
• A GUI de filtragem de objetos é muito desajeitada. Devido ao fato de estarmos trabalhando em um ambiente de banco de dados legado, atualmente não há uma separação clara entre os objetos que nossa equipe possui e aqueles pertencentes a outras equipes, portanto, para evitar que cometamos/implantamos acidentalmente alterações de outras equipes , configuramos um esquema de filtragem para incluir explicitamente cada objeto específico que possuímos. Como você pode imaginar, isso se torna bastante complicado, e como a GUI para editar os filtros está configurada para inserir um objeto por vez, pode se tornar bastante doloroso, especialmente ao tentar configurar seu ambiente pela primeira vez (acabei escrevendo um aplicativo para fazer isso). No futuro, estamos criando um novo esquema para nosso aplicativo para facilitar melhor a filtragem de objetos (além de ser uma prática melhor de qualquer maneira).
• Usando o modelo de banco de dados compartilhado, os desenvolvedores podem confirmar quaisquer alterações pendentes em um banco de dados controlado por origem, mesmo que as alterações não sejam deles. O SSC avisa se você tentar verificar várias alterações de que essas alterações podem não ser suas, mas, além disso, você está por conta própria. Na verdade, acho que isso é uma das “peculiaridades” mais perigosas do SSC.
• O SQL Compare não pode compartilhar atualmente os filtros de objeto criados pelo SSC, então você teria que criar manualmente um filtro correspondente no SQL Compare, então existe o perigo de que eles fiquem fora de sincronia. Acabei de recortar e colar os filtros do arquivo de filtro SSC subjacente no filtro do projeto SQL Compare para evitar lidar com a GUI desajeitada de filtragem de objetos. Acredito que a próxima versão do SQL Compare permitirá compartilhar filtros com o SSC, então pelo menos esse problema é apenas de curto prazo. (OBSERVAÇÃO:esse problema foi resolvido na versão mais recente do SQL Compare. O SQL Compare agora pode usar os filtros de objeto criados pelo SSC.)
• O SQL Compare também não pode comparar com um repositório de banco de dados SSC quando iniciado diretamente. Ele deve ser iniciado de dentro do SSMS. Acredito que a próxima versão do SQL Compare fornecerá essa funcionalidade, então, novamente, é outro problema de curto prazo. (OBSERVAÇÃO:esse problema foi resolvido na versão mais recente do SQL Compare.)
• Às vezes, o SQL Compare não é capaz de criar os scripts adequados para obter o banco de dados de destino de um estado para outro, geralmente no caso de você estar atualizando o esquema de tabelas existentes que não estão vazias. escreva scripts manuais e gerencie você mesmo o processo. Felizmente, isso será resolvido por meio de “scripts de migração” na próxima versão do SSC e, olhando para a versão inicial do produto, parece que a implementação desse novo recurso foi bem pensada e projetada. (OBSERVAÇÃO:A funcionalidade de scripts de migração foi lançada oficialmente. No entanto, ela não suporta ramificação no momento. Se você quiser usar scripts de migração, precisará executar sql compare com sua ramificação de código de desenvolvimento original... aquela em que você verificou suas alterações... o que é bastante desajeitado e me forçou a modificar meu processo de compilação de uma maneira menos que ideal para contornar essa limitação. Espero que isso seja resolvido em uma versão futura.)

No geral, estou muito feliz com o produto e com a capacidade de resposta da Redgate ao feedback do usuário e a direção que o produto está tomando. O produto é muito fácil de usar e bem projetado, e eu sinto que na próxima versão ou dois o produto provavelmente nos dará a maioria, se não tudo, do que precisamos.