J'ai mis à jour mon message d'origine ci-dessous pour refléter les modifications apportées aux dernières versions de SQL Source Control (3.0) et SQL Compare (10.1).
Étant donné que cette question a été posée il y a plus d'un an, ma réponse ne vous sera peut-être pas très utile, mais pour les autres qui évaluent actuellement SSC, j'ai pensé que je donnerais mon grain de sel. Nous venons de commencer à utiliser SQL Source Control (SSC) et dans l'ensemble, j'en suis assez satisfait jusqu'à présent. Il a cependant quelques bizarreries, surtout si vous travaillez dans un environnement de base de données partagée (par opposition à chaque développeur travaillant localement) et en particulier dans un environnement hérité où les objets de la même base de données sont répartis au hasard entre les équipes de développement.
Pour donner un bref aperçu de la façon dont nous utilisons le produit dans notre organisation, nous travaillons dans un environnement partagé où nous apportons tous des modifications à la même base de données de développement, nous avons donc attaché la base de données partagée au référentiel de contrôle de source. Chaque développeur est chargé d'apporter des modifications aux objets de la base de données via SQL Server Management Studio (SSMS), et lorsqu'ils ont terminé, ils peuvent valider leurs modifications dans le contrôle de code source. Lorsque nous sommes prêts à déployer vers la mise en scène, le maître de construction (moi) fusionne la branche de développement du code de la base de données avec la branche principale (mise en scène), puis exécute SQL Compare en utilisant la version du référentiel de la branche principale de la base de données comme source et le live base de données intermédiaire comme cible, et SQL Compare génère les scripts nécessaires pour déployer les modifications apportées à l'environnement intermédiaire. La mise en place des déploiements de production fonctionne de la même manière. Un autre point important à noter est que, étant donné que nous partageons la même base de données avec d'autres équipes de développement, nous utilisons une fonctionnalité intégrée de SSC qui vous permet de créer des filtres sur les objets de la base de données par nom, type, etc. configurer des filtres sur les objets spécifiques de notre équipe, à l'exclusion de tous les autres objets, afin de ne pas commettre accidentellement les modifications d'autres équipes de développement lorsque nous effectuons nos déploiements.
Donc, en général, c'est un produit assez simple à configurer et à utiliser et c'est vraiment bien parce que vous travaillez toujours avec des objets en direct dans SSMS, par opposition aux fichiers de script déconnectés stockés dans un référentiel source séparé qui risquent de se désynchroniser . C'est également agréable car SQL Compare génère les scripts de déploiement pour vous afin que vous n'ayez pas à vous soucier d'introduire des erreurs comme vous le feriez si vous créiez les scripts vous-même. Et comme SQL Compare est un produit très mature et stable, vous pouvez être sûr qu'il créera les scripts appropriés pour vous.
Cela étant dit, voici quelques-unes des bizarreries que j'ai rencontrées jusqu'à présent :
- SSC est assez bavard dès le départ en termes de communication avec le serveur de base de données afin de suivre les éléments de la base de données qui ne sont pas synchronisés avec le référentiel de contrôle des sources. Il interroge toutes les quelques millisecondes et si vous ajoutez plusieurs développeurs travaillant tous sur la même base de données en utilisant SSC, vous pouvez imaginer que nos dba n'étaient pas très heureux. Heureusement, vous pouvez facilement réduire votre fréquence d'interrogation à quelque chose de plus acceptable, mais au prix de sacrifier les notifications visuelles réactives lorsque des objets ont été modifiés.
- À l'aide de la fonctionnalité de filtrage d'objets, vous ne pouvez pas facilement déterminer, en regardant des objets dans SSMS, quels objets sont inclus dans votre filtre. Vous ne savez donc pas avec certitude si un objet est sous contrôle de source, contrairement à Visual Studio, où des icônes sont utilisées pour indiquer les objets sous contrôle de source.
- L'interface graphique de filtrage d'objets est très maladroite. En raison du fait que nous travaillons dans un environnement de base de données hérité, il n'y a actuellement pas de séparation claire entre les objets que notre équipe possède et ceux appartenant à d'autres équipes, afin de nous empêcher de valider/déployer accidentellement les modifications d'autres équipes , nous avons mis en place un schéma de filtrage pour inclure explicitement chaque objet spécifique que nous possédons. Comme vous pouvez l'imaginer, cela devient assez lourd, et comme l'interface graphique pour éditer les filtres est configurée pour entrer un objet à la fois, cela peut devenir assez pénible, surtout en essayant de configurer votre environnement pour la première fois (j'ai fini par rédiger une application pour ce faire). À l'avenir, nous créons un nouveau schéma pour notre application afin de mieux faciliter le filtrage d'objets (en plus d'être une meilleure pratique de toute façon).
- En utilisant le modèle de base de données partagée, les développeurs sont autorisés à valider toutes les modifications en attente dans une base de données contrôlée par la source, même si les modifications ne leur appartiennent pas. SSC vous avertit si vous essayez de vérifier un tas de changements que ces changements pourraient ne pas être les vôtres, mais à part cela, vous êtes seul. Je trouve en fait que c'est l'une des "bizarreries" les plus dangereuses de PVC.
- SQL Compare ne peut actuellement pas partager les filtres d'objets créés par SSC, vous devrez donc créer manuellement un filtre correspondant dans SQL Compare, il y a donc un risque que ceux-ci se désynchronisent. Je viens de couper et coller les filtres du fichier de filtre SSC sous-jacent dans le filtre de projet SQL Compare pour éviter de traiter avec l'interface graphique de filtrage d'objet maladroite. Je pense que la prochaine version de SQL Compare lui permettra de partager des filtres avec SSC, donc au moins ce problème n'est qu'un problème à court terme. (REMARQUE :ce problème a été résolu dans la dernière version de SQL Compare. SQL Compare peut désormais utiliser les filtres d'objets créés par SSC.)
- SQL Compare ne peut pas non plus être comparé à un référentiel de base de données SSC lorsqu'il est lancé directement. Il doit être lancé depuis SSMS. Je crois que la prochaine version de SQL Compare fournira cette fonctionnalité, donc encore une fois c'est un autre problème à court terme. (REMARQUE :ce problème a été résolu dans la dernière version de SQL Compare.)
- Parfois, SQL Compare n'est pas en mesure de créer les scripts appropriés pour faire passer la base de données cible d'un état à un autre, généralement dans le cas où vous mettez à jour le schéma de tables existantes qui ne sont pas vides, vous devez donc actuellement écrivez des scripts manuels et gérez vous-même le processus. Heureusement, ce problème sera résolu par le biais de « scripts de migration » dans la prochaine version de SSC, et en regardant la première version du produit, il semble que la mise en œuvre de cette nouvelle fonctionnalité a été bien pensée et conçue. (REMARQUE :la fonctionnalité des scripts de migration a été officiellement publiée. Cependant, elle ne prend pas actuellement en charge la création de branches. Si vous souhaitez utiliser des scripts de migration, vous devrez exécuter sql par rapport à votre branche de code de développement d'origine... celle où vous avez enregistré vos modifications... ce qui est assez maladroit et m'a obligé à modifier mon processus de construction d'une manière moins qu'idéale afin de contourner cette limitation. J'espère que cela sera résolu dans une future version.)
Dans l'ensemble, je suis assez satisfait du produit et de la réactivité de Redgate aux commentaires des utilisateurs et de la direction que prend le produit. Le produit est très facile à utiliser et bien conçu, et je pense que dans la prochaine ou les deux prochaines versions, le produit nous donnera probablement la plupart, sinon la totalité, de ce dont nous avons besoin.
