Les développeurs devraient-ils être autorisés à utiliser LocalDB vs une instance de «développement»?

Tout comme la veine de la question qui a été postée ici précédemment autour de " Les développeurs devraient-ils pouvoir interroger les bases de données de production? " Je voulais avoir votre avis sur un autre sujet particulièrement ennuyeux!

De nombreuses entreprises empêchent les développeurs d'installer SQL Server Express et autres sur des machines de développement, favorisant plutôt l'utilisation de serveurs SQL de développement centralisés.

Plus précisément, cela est fait pour garantir:

• Cohérence au niveau des correctifs entre les serveurs de développement et la production
  
• Capacité à prouver et à valider les correctifs ci-dessus
  
• Sécurité des données; seules les données sur les serveurs de développement sont utilisées pour le développement
  
• Récupérabilité; les données sont récupérables et toujours sauvegardées
  
• Différences de classement qui peuvent causer des problèmes lors du passage en production

Pour moi, tous ces arguments sont particulièrement invalides, à l'exception peut-être des correctifs; mais si une base de données sur une machine locale est purement utilisée pour des activités de développement, et non pour des tests, le correctif sera prouvé lorsqu'une application progressera via Test / UAT, etc. jusqu'à Production.

Le classement ne semble pas être une raison valable, car s'il s'agissait d'une préoccupation pour la base de données, elle devrait être définie lors de sa création. Seuls SharePoint et SCCM ont des problèmes à ce sujet pour autant que je sache;)

Maintenant, en supposant que c'est UNIQUEMENT pour le développement, et la base de données ne sera pas "déplacée" en production et les seuls mouvements seraient:

• Scripts qui ont créé la base de données générée pour le déploiement en production
• Sauvegardes des systèmes tiers "de production" en cours de restauration et tronquées le cas échéant pour validation et développement

Quelqu'un peut-il voir des problèmes? Suis-je en train de manquer quelque chose?

Je suppose que l'une des plus grandes préoccupations serait la capacité des instances de base de données locales périmées, mais c'est un problème de gestion de logiciel, pas un IMO DBA.

Oui. Tous les développeurs doivent avoir une instance locale de SQL Server ET une instance de serveur SQL partagée. Ils existent à des fins différentes. Les deux sont nécessaires.

Peut-être que votre environnement actuel ressemble à ceci?

Ci-dessus, plusieurs développeurs créent des modifications et les déploient dans une base de données SQL Developer commune. C'est mauvais. Documents Microsoft MVP Troy Hunt quelques - uns des points de douleur cette approche surannée, ici . Les principaux sont ...

1. Incapacité de contrôler correctement la source. GROS!
2. Incapacité à régler les performances sans droits au niveau du serveur.
3. Incapacité d'expérimenter sans impact sur les autres.

Ce modèle provoque un conflit avec les développeurs. Un des symptômes du conflit est l'étalement de la base de données. De nombreuses bases de données sont créées lorsque les développeurs recherchent un espace sûr et isolé pour faire leur travail. Il y a plusieurs raisons pour lesquelles l'organisation s'accroche à ce modèle. La première est qu'ils n'ont pas investi dans un système de contrôle des sources approprié . Un autre est qu'ils ont simplement hérité de ce modèle de conception et ne peuvent pas être dérangés pour le changer. Microsoft s'éloigne progressivement de ce modèle et se rapproche de quelque chose comme ça ...

Dans le diagramme ci-dessus, chaque développeur utilise Visual Studio pour écrire et enregistrer ses modifications de base de données dans une instance locale de SQL Server. Ces modifications locales sont ensuite synchronisées dans un système de contrôle de source approprié. Ici, chaque développeur peut concevoir et expérimenter dans un environnement où ses modifications n'auront d'incidence sur personne d'autre jusqu'à leur enregistrement. Et à ce moment, les conflits seront résolus.

La base de données locale utilisée ci-dessus peut être des éditions LocalDB, Express ou Developer. Simple-Talk fait un excellent travail en pesant les avantages et les inconvénients de chacun ici . Il y a une raison pour laquelle Microsoft a créé autant de choix pour les bases de données de développement local: LocalDB, Express, Developer .. nous devrions les utiliser!

Si vous devez choisir, il est difficile de ne pas prétendre que chaque développeur a une version locale de SQL Server Developer Edition installée. Il est entièrement gratuit et a une parité de fonctionnalités avec l'édition Enterprise. Cela va permettre à toute votre équipe d'explorer et de concevoir de manière sécurisée l'ensemble de la pile Microsoft BI (SQL Server, SSIS, SSRS et SSAS).

Nous pouvons toujours conserver la base de données communale, mais elle ne devrait pas être destinée au développement, elle devrait l'être à des fins de test. C'est un serveur où les paramètres au niveau du système sont synchronisés avec la production. Matériel, OS, correctifs, etc.

Pour moi, tous ces arguments sont particulièrement invalides

D'accord. Mais ils ne le sont pas pour nous tous. Pourquoi?

Cohérence au niveau des correctifs entre les serveurs de développement et la production

la correction serait prouvée lorsqu'une application progressait via Test

Les correctifs peuvent résoudre les problèmes de stabilité et de corruption des données qui pourraient autrement tourmenter les développeurs. Cela devrait être fait sur des machines de développement malgré tout.

Sécurité des données; seules les données sur les serveurs de développement sont utilisées pour le développement

Il est utile de séparer «ce qui devrait être» de «ce qui est». Les développeurs se retrouvent avec des données sensibles (pas nécessairement PII, mais pas libres non plus) sur leurs bases de données. Ça arrive.

Récupérabilité; les données sont récupérables et toujours sauvegardées

Super important.

Différences de classement qui peuvent causer des problèmes lors du passage en production

Seuls SharePoint et SCCM ont des problèmes à ce sujet

Tout ce qui utilise une table temporaire aura ce problème. C'est extrêmement courant. Vous ne le remarquez jamais parce que la plupart des gens optent pour un classement standard en premier lieu.

en supposant que c'est UNIQUEMENT pour le développement, et la base de données ne sera pas "déplacée" en production

Pourquoi supposerions-nous cela? Les choses vont souvent du développement à la production. Sinon, comment obtenez-vous la production peuplée pour la toute première fois? Des scripts purs? Pas nécessairement lorsque l'application est en pré-production depuis un certain temps.

Je suppose que l'une des plus grandes préoccupations serait la capacité des instances de base de données locales périmées, mais c'est un problème de gestion de logiciel, pas un IMO DBA.

Vous avez simplement besoin d'émettre une déclaration sur ce que vous faites et ne soutenez pas et pourquoi.

LocalDB est un élément central de SSDT maintenant et inévitable. Cependant, il n'est pas accessible à distance et n'a pas de composant de planification (Express a des problèmes similaires). Par conséquent, il n'est généralement pas pris en charge par les administrateurs de base de données en ce qui concerne les sauvegardes, la maintenance et les vérifications d'intégrité.

Mais la consolidation vers des serveurs de développement centralisés reste logique. Et maintenant que Developer Edition est gratuite, il est encore plus facile de justifier d'en avoir plus.

Sur le plan conceptuel, vous êtes sur la bonne voie. Pour une organisation qui a un processus de développement / cycle de vie de développement logiciel (SDLC) mature qui comprend le contrôle du code source, l'intégration continue (CI), des tests automatisés et un groupe informatique qui sait comment gérer divers environnements et postes de travail pour les garder synchronisés en ce qui concerne les logiciels et les correctifs, et les développeurs disciplinés qui a) suivent le processus, b) travaillent ensemble et c) travaillent avec l'informatique, puis avoir 50 (ou autant de) DB de développement peuvent fonctionner:

• Oui, des niveaux de logiciels et de correctifs cohérents peuvent être maintenus sur n'importe quel nombre de postes de travail.
• Oui, tous les "problèmes" peuvent apparaître dans des environnements de test automatisé et / ou QA / UAT.
• De nombreux DB de développement ne sont pas aussi faciles à sauvegarder, mais pas impossible non plus. Si vous utilisez des profils itinérants, les fichiers de données se trouvant dans le dossier «Paramètres locaux» de chaque utilisateur Windows pourraient être plus faciles à sauvegarder. Ou tout au moins, il peut être scripté par le service informatique pour récupérer les fichiers de tous les postes de travail de développement, de la même manière qu'ils garantiraient que tous sont correctement corrigés.

MAIS, comme avec presque tout le reste, cela se résume vraiment au contexte de la situation.

L'un des avantages de disposer de bases de données de développement distinctes est que différents projets peuvent être traités simultanément sans impact mutuel. (Bien sûr, cela pourrait être le seul avantage.)

TOUTEFOIS, il y a plusieurs questions à considérer:

• Quelle est la taille de l'équipe et combien de personnes travaillent sur un projet particulier? Plus vous travaillez sur un projet, plus vous avez besoin d'un serveur de développement partagé / centralisé pour que tout le monde reçoive toutes les modifications.

• Côté classement , SQL Server Express LocalDB a une nuance / restriction / limitation particulièrement ennuyeuse:

  Le classement d'instance pour LocalDB est défini sur SQL_Latin1_General_CP1_CI_AS et ne peut pas être modifié. Les classements au niveau de la base de données, au niveau des colonnes et au niveau de l'expression sont pris en charge normalement. Les bases de données contenues suivent les règles de classement des métadonnées et tempdb définies par les classements de bases de données contenues .

  Le tempdbclassement au niveau de l'instance affecte non seulement (c'est-à-dire la résolution de nom d'objet à portée db et le classement par défaut pour les tables temporaires mais pas les variables de table), mais également les noms de variable locale, les noms de curseur / noms de paramètre et les gotonoms d'étiquette. Par conséquent, si vos serveurs de production ont un SQL_Latin1_General_CP1_CI_ASclassement au niveau de l'instance autre que , LocalDB n'est pas un bon choix.

• Utilisez-vous les fonctionnalités Enterprise Edition? S'il ne s'agit que de faire des reconstructions d'index en ligne, cela n'a probablement pas d'importance. Mais si vous utilisez quelque chose comme le partitionnement de table, LocalDB n'est pas un bon choix.

• Le plus gros problème est peut-être l'augmentation globale de la portée des problèmes potentiels résultant de toute disparité environnementale (niveau du système d'exploitation, niveau du correctif logiciel, configuration d'instance, configuration de base de données, etc.) qui pourrait entraîner un bogue. Bien que nous ayons déjà accepté (dans un sens général) que les tests automatisés / QA / UAT trouveraient ces problèmes, ce n'est pas garanti ! Étant donné que les humains font des erreurs et que les humains doivent proposer tous les tests qui vérifieraient tous les chemins de code et toutes les variations de données (types, taille, etc.), il est fort probable qu'un certain nombre de scénarios ne seront pasêtre testé et qu'un bogue pourrait le traverser et ne pas être remarqué jusqu'à ce qu'un client le trouve dans Production. Cela se produit de toute façon, mais les chances augmentent lors de l'utilisation de LocalDB afin que chaque développeur puisse avoir sa propre base de données privée.

Cela se résume vraiment à: quelle est la raison impérieuse de l'utiliser dans un environnement d'équipe? Dans divers emplois, j'ai toujours travaillé dans des groupes où il y avait des développeurs d'applications et des ingénieurs de bases de données, et bien que les développeurs d'applications aient parfois simulé une procédure stockée juste pour le faire plus rapidement (nous ne sommes pas assez DBE), les DBE ont fait la plupart des Programmation DB, y compris la vérification (c'est-à-dire la réparation) de tout code écrit par les développeurs d'applications. L'utilisation de LocalDB aurait rendu beaucoup plus difficile le travail en groupe. Et tout en utilisant SQL Server Express (ou même Developer Edition) pour avoir des instances personnelles sur chaque poste de travail de développement accessibles à distance - ce qui facilite la collaboration - il n'a jamais été vraiment nécessaire d'avoir ce niveau d'isolement car il était rare de avoir des modifications de base de données pour un projet a un impact négatif sur un autre.

Bien sûr, ceux d'entre nous qui étaient des ingénieurs de bases de données (DBE) avaient des installations locales d'Express Edition et / ou Developer Edition. Mais, c'était pour faire des tests qui nécessitaient plus de contrôle sur la configuration / sécurité au niveau de l'instance, etc. que ce qui pouvait être autorisé sur un serveur partagé. Et j'ai utilisé les instances locales de temps en temps, mais pas très souvent. Mais pour mes projets personnels, j'adore LocalDB et je l' utilise assez fréquemment.