• Stairway to Advanced T-SQL Level 9: Compare, Modify, Derive and Validate Date and Time Values
• A Day in the Life of a SQL Server Data Architect
• DBAs at work #3: The finance company Manager DBA
• From the SQL Server Central Blogs - Saving PowerShell Results to the Clipboard–#SQLNewBlogger
• From the SQL Server Central Blogs - Understanding SQL Server IO Size

• Variant Math

Daily Coping Tip

Choose to give or receive the gift of forgiveness

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Change Approvals

This editorial was originally published on Mar 24, 2017. It is being re-run as Steve is on vacation.

Part of a developer's or DBA's career is getting their work released to some system where others can use the system. Some of us may do this more than others, but we all usually have some role, whether in packaging changes up or actually pushing the button that runs a script or copies files to some live server. This can be an exciting and stressful time, depending on how you feel about the quality of the work.

Releasing software often isn't something done in a vacuum. Even in the highly agile, DevOps companies like Amazon and Facebook where developers release code many times a day, there is often some sort of approval process, whether implicit or explicit, before code goes out. Even if it's just a peer that code reviews something, or a business person that examines a test version and pronounces it correct, another person often weighs in on our changes.

That's not always the case, as I know in emergencies, some of us make quick decisions and change or run code that only we have examined. I'd hope that's the exception, rather than the rule, with most database changes.

Today I'm curious. Who approves your database changes? Is there a formal process? An informal one? Does the person making the decision even understand the code or do they depend on you to have written and tested solid T-SQL?

It's been said that the person closest to the work is often the best person to judge if it should be released, but that's only partially true. Deploying code is often disruptive. It introduces change, which customers may or may not like. There may be good reasons to release at discrete intervals, rather than whenever the developer things things are working. This may change with heavy use of feature flags or feature toggles, but in general, code releases are interruptions and we want to limit them.

Unless something is broken, in which case, we often want the change as quick as it can be released. Does that mean we want a different change process? Let us know today.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums