I’ve seen a couple of conversations recently about companies that want to be able to script out their database schema on a daily basis so that they have a current copy of the database; or systems that have to change permissions with the database frequently, and they need to export a copy of those permissions so that they have a copy of those settings.
My question to follow up on these sorts of situations is, why aren’t these settings in Source Control?
Pushing these changes to production requires a change control process (and the approvals that go with these). That means that you have to document the change in order to put it into the change control ticket, so why aren’t these changes pushed into your source control system?
Anything and everything that goes into your production systems should be stored in your source control system. If the server burns down, I should be able to rebuild SQL (for example) from the ground up, from source control. This includes instance level settings, database properties, indexes, permissions, table (and view, and procedures) should all be in your source control system. Once things are stored in your source control system, then the need to be able to export the database schema goes away, as does the need to export the permissions regularly. As these have no point in doing them, there is no need to do them.
Think I’m wrong, convince me in the comments.
Denny
The post If It Requires A Change Control Ticket To Change It, It Should Be In The Change Control System appeared first on SQL Server with Mr. Denny.
