Discussion :

[Alcor5]

Bonjour,


Existe-t-il un moyen pour les développeurs de débugger leur code sur des serveurs des dévl sans être sysadmin ?
Car les sa ne veulent pas donner ce droit, ce que je peux comprendre.

Interdire le debug sur un serveur de prod est normal et cohérent mais sur un serveur de dév, je ne comprends pas trop la logique de Microsoft...


Existe-t-il un moyen ou un quelconque workarround pour permettre le débugging aux développeurs ?
Sur 2008 ou supérieur...

J'avais 2 idées en têtes :
- installer un serveur local sur chacun des postes développeurs (qui serait effectivement sa sur son serveur de dévl)
- débugger via MS Visual Studio


D'avance merci

[iberserk]

Bonjour, sauf erreur de ma part ce n'est pas possible.

[mikedavem]

Hello,

Interdire le debug sur un serveur de prod est normal et cohérent mais sur un serveur de dév, je ne comprends pas trop la logique de Microsoft...

Ce n'est pas la logique de Microsoft mais plutôt de tes administrateurs de bases de données dans ce contexte à mon avis. Sur un serveur de développement les développeurs doivent pouvoir faire leur travail et par conséquent doivent avoir les droits nécessaires à cet effet. En général, tu n'as pas besoin d'être syadmin, même sur un serveur de développement. Chez la plupart de mes clients que je rencontre, les développeurs sont db_owner de leur(s) base(s) de données et peuvent donc tout faire dessus (ils en sont responsable). Le rôle du DBA consiste simplement à garantir une disponibilité de l'instance de développement et une sauvegarde régulière des bases et des objets connexes si jamais vous devez revenir en arrière ou en cas de crash pour faire simple.

Si tu dois avoir des droits supplémentaires, tel que lancer des traces ou avoir accès aux vues de gestion dynamiques il y a également des droits spécifiques pour cela. Bref, je pense qu'un dialogue est nécessaire avec les gens de l'infrastructure et les développeurs ici

++

[julien94320]

Si tu dois avoir des droits supplémentaires, tel que lancer des traces ou avoir accès aux vues de gestion dynamiques il y a également des droits spécifiques pour cela. Bref, je pense qu'un dialogue est nécessaire avec les gens de l'infrastructure et les développeurs ici

Je suis tout a fait d'accord avec David, perso cela m'a permit de résoudre pas mal de point chez des clients. Il ne faut pas hésiter a organiser des réunions avec les DBA et l'infra pour chaque projet cela peut faciliter les demandes et améliorer la qualité des dev's

[Alcor5]

Hello,



Ce n'est pas la logique de Microsoft mais plutôt de tes administrateurs de bases de données dans ce contexte à mon avis. Sur un serveur de développement les développeurs doivent pouvoir faire leur travail et par conséquent doivent avoir les droits nécessaires à cet effet. En général, tu n'as pas besoin d'être syadmin, même sur un serveur de développement. Chez la plupart de mes clients que je rencontre, les développeurs sont db_owner de leur(s) base(s) de données et peuvent donc tout faire dessus (ils en sont responsable). Le rôle du DBA consiste simplement à garantir une disponibilité de l'instance de développement et une sauvegarde régulière des bases et des objets connexes si jamais vous devez revenir en arrière ou en cas de crash pour faire simple.

Si tu dois avoir des droits supplémentaires, tel que lancer des traces ou avoir accès aux vues de gestion dynamiques il y a également des droits spécifiques pour cela. Bref, je pense qu'un dialogue est nécessaire avec les gens de l'infrastructure et les développeurs ici

++

Merci pour la réponse.
Les développeurs sont déjà dbo de leur db en dévl mais ce n'est pas malheureusement suffisant. Et je trouve cela assez paradoxal qu'un dbo puisse créer des tas d'objets mais ne peut pas les débugger...

Je vais engager un dialogue avec nos DBA mais si la seule réponse technique est de devenir sysadmin, j'ai bien peur que la demande soit rejetée...
Et j'avoue que je comprendrai cette décision car je ne trouve pas très sain qu'un développeur soit sysadmin sur un serveur de dévl : il pourrait potentiellement faire beaucoup de dégâts aux autres db, etc...


Pour résumer ma pensée, je trouve la réponse 'devenir sysadmin' de MS bien trop large et permissive "juste" pour débugger des objets d'une db.
Il y a un soucis au niveau de la granularité : un développeur dbo des bases de données A - B - C se verrait attribuer tous les droits absolus au niveau du serveur hébergeant les bases de données A - B -C - D - E - F...
C'est cette logique-là que je ne comprends pas.

Dommage qu'il n'y ait pas d'instruction "ALTER DEBUGGING" au niveau de la base de données...

[mikedavem]

Et je trouve cela assez paradoxal qu'un dbo puisse créer des tas d'objets mais ne peut pas les débugger...

Dommage qu'il n'y ait pas d'instruction "ALTER DEBUGGING" au niveau de la base de données...

Peut être faudrait-t-il préciser ce qu'il y a derrière le mot débugger dans ton cas?

++

[Alcor5]

Peut être faudrait-t-il préciser ce qu'il y a derrière le mot débugger dans ton cas?

++

Par debugger, j'entends lancer le debug via Mgm Studio, pouvoir mettre des breakpoints, jouer avec le stepping, ...
Autrement dit, je souhaite éviter de modifier les stored proc en y insérant des "print" ou des "select" juste pour pouvoir tracer le code.

[mikedavem]

Ok je comprends mieux ta frustration dans ce cas. Effectivement le mode debug sur SQL Server requiert les privilèges sysadmin pour la simple et bonne raison que ce mode impacte le process SQL Server dans son entier et les autres utilisateurs (développeurs en l'occurrence dans ton cas). Il n'est pas rare dans ce mode d'avoir par exemple des verrous intempestifs qui peuvent gêner les autres personnes.

Tu n'auras pas d'autres choix que d'avoir ta propre instance ou d'être sysadmin.

++