1

I'm a developer at a small company where we're struggling for consistent change control. I'm running into issues where non-dev staff are tweaking stored procedures and triggers in production installations. Their changes are being overwritten when we apply upgrades because they've gone outside of the process the dev team uses to verify db changes are incorporated into source control.

How would you recommend approaching this problem from a technical as well as personal perspective?

Edit 1: A little background on our current process might help this along. We're using a continuous integration server (TeamCity) to generate install artifacts and label svn upon check in. I'm using NMigrations to manage schema and sp/trigger changes when we apply fixes. Unfortunately it's beyond my ability to stop unauthorized schema changes so what I would love to find is a design pattern that allows for an overridable trigger/sp definition.

Steve
  • 21
  • 2
  • 5

2 Answers2

0

You need to clearly separate:

Tweaking in prod shouldn't be possible if the release environment is protected through strict ACL preventing anyone duly appointed to deploy and change stuff.
If that deployment process is automated, then all changes will go through the proper channel because anyone will known a simple "push button" process will be enough to deploy the hotfix.

But if getting that fix in source control and deploy it is complicated, then a tweak directly in prod is usually the result...

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Tweaking definitely shouldn't be possible in a production environment. Unfortunately our process hasn't matured far enough to limit this yet. – Steve May 23 '11 at 22:06
0

Limit rights to change stored procedures and triggers, especially on production. Go ahead and let them know first so they aren't blindsided, but clearly protect production from all unauthorized changes.

thursdaysgeek
  • 7,696
  • 20
  • 78
  • 115