You better watch out, you better not cry, gonna find out who's naught and nice - TSQL Tuesday #73 is coming to town! And that is today's topic for this month's TSQL Tuesday, by Mr. Bradley Balls, aka SQLBalls, SQL Server MVP, and friend. Brad must have been thinking naughty thoughts when he came up with this one, but SQLly speaking, this is a great topic! I'm weighing in here a little late, but better late than never! His original invite here. So, let's get into the holiday season, and jump right down that chimney, and hope we can get Santa to approve that database change. Because if the big guy doesn't approve, then you shouldn't be touching that database, at least not without cookies and egg nog.
OK, let's get serious, if you're a developer with keys to the kingdom, ie sa access, or the eager DBA, and make unsolicited and untracked changes to production, this could blow up all over the place. This to me is definitely "naughty" - don't be the naughty DBA, and never make changes to production without having 1.tested them in a QA/UAT environment 2. an approved change ticket; 3. an implementation plan, with scripts; 4. a backout or rollback plan; 5.agreed upon deployement schedule These are the top five things that come to mind when deploying changes into production, to ensure a smooth implementation. In my book, HealthySQL, Chapter 10, Surviving the Audit, I extensively discuss and detail the need for a change control process, as well as the need to control access to the database environment. If you're NOT doing this as a DBA, then you're being naughty, and unnecessarily putting your database and SQL Server, and business at risk! In the Tale of the DBA and Developer section, I layout the best way to achieve the company's goal, by introducing some level of separation of duties, and working towards a friendly DBA/Developer relationship.
Indeed, all changes to the database environment should follow a standard change management process, even if its a simple e-mail chain among the requestors and the approver, typically the developer/DBA and the manager. You may have an internal change tracking ticketing system, or if just using email, all change requests should ideally include:
- Description of the Change
- Reason for the Change
- Documentation/Scripts (deployment & rollback)
- Evidence/support of testing in UAT/QA environment
- Risk statement/level and backout plan
- Ticket assignment
- Approvals
Not only will change management process allow you to document all production changes, it will allow you to audit and track changes, in the instance you'll need to roll back. In my long career, I've seen many things, and any ad-hoc changes to production can lead to disaster, and that is something that is unacceptable, and just plain naughty! If your database change IS on the list, you just might get your production change approved, and that Xmas bonus too!
Adam
Machanic’s (b|t), one of the premier SQL
developers, started the T-SQL Tuesday blog party eons ago. Well, back in 2009. Here are the rules to T-SQL Tuesdaydom:
- Write a
blog post about the topic. Don’t have a blog? Start one!
- Include
the T-SQL Tuesday Logo and link it back to the original invitation post.
- Publish
your blog post Tuesday, December 8, 2015, between 00:00 GMT & 23:59
GMT.
- Leave a
reply on the original invite with a link to your blog post (for the
round-up).
- Share you
post with the community! Tweet it out using the #tsql2sday hashtag
Thanks to Brad for getting us all in the Holiday Spirit, and for a great and timely topic!
And of
course, if anyone is interested in learning more about my book Healthy SQL – A
Comprehensive Guide to Healthy SQL Server Performance, published by Apress, you can go to the url:
http://bit.ly/orderHealthySQLnow
You can also
get the book on Amazon: http://bit.ly/HealthySQLonAmazon
For all
things SQL, news, events, jobs, info, and other fun tweets, follow me on
twitter @Pearlknows and join the #HealthySQL campaign to
keep your SQL Servers healthy!
