There are tons of posts out there these days talking about how the DBA role is evolving. Mainly around AI and how it impacts the day-to-day mindsets and routines as a DBA. Here are the general common themes I’m seeing:

• AI is going to take our jobs.
• AI is dumb and is not going to take our jobs.
• Look at this cool thing I vibe coded in production using AI.
• AI took down my production environment.

I’m being facetious here, I leverage AI as much as the next person, and I personally think it can be a huge workforce multiplier if used properly, but the overarching theme lands somewhere in the realm of the examples above in my opinion. While AI seems to be dominating the conversation around the future of the DBA role, I think another quieter shift is happening that deserves just as much attention.

I don’t see much chatter around the DBA’s role and necessity in understanding CI/CD and Source Control as it relates to SQL Server. I’d like to dive a bit deeper into that here and share my experience working with GitHub, AzDO Pipelines, and Source Control in general, and really share the importance of adding these tools to your toolbelt as a DBA (and when it’s appropriate to ignore them).

Not My Hat

As a DBA working in a single shop environment (not a consultant working for an MSP) you’re typically wearing more hats than just the one that comes with the job. Sometimes you’re reaching into AD. Sometimes messing with a Kafka topic or Confluent connector. Maybe Fivetran is on the fritz and you need to look at it sternly until data starts flowing again.

But in the average shop, the database developer’s role and the DBA’s role (at least in my experience) usually stay in their own lanes. I am no better than anyone else and will admit it here that I at times have had the “Not My Hat” mentality when it comes to developer / administrator overlap in responsibilities and support ownership.

Interestingly enough, I’m finding myself becoming more and more responsible for supporting what I used to think were “developer realm” things. Mainly CI/CD as it relates to SQL Server.

My Experience

Nearly 100% of my career has been DBA focused. Started as an intentional DBA, went into DBA consulting, learned a lot from really good DBAs. However, I had qualities of not being an efficient DBA at times. I was a button clicker, backlogging opportunities for standardized automation for the simple fact that I could “click through this faster than I can write a script or process to do the same thing.” not realizing that if I put the same amount of time towards automating something, it would save me even more time in the long run.

I have the toolbox of scripts in my Notion on my local laptop, ready to pull out and use for the umpteenth time for the same deployment process that I could probably do with my eyes closed. The concept of Source Control, Git, GitHub, and AzDO Pipelines was incredibly overwhelming to me. I sort of understood the benefit and purpose for developers, but never made the connection and saw the importance of a DBA’s understanding and ownership of these tools as well.

I realized recently that it isn’t due to a lack of skillset that I’ve avoided embracing and implementing CI/CD infrastructures and Source Control into my daily work, it was the wrong mindset.

Understanding Allows You To Help

Like many DBAs, I’m used to making changes directly in production environments while watching developers go through their controlled CI/CD and Source Control processes to make their changes. And while our two worlds live closely together with some overlap, the pain point comes in when things break. The common struggle is the developer doesn’t understand SQL Server, the DBA doesn’t understand the pipeline, and nobody can help each other.

The learning curve is steep with these tools and processes mentioned above. I wasn’t used to functioning with them at all until recently. However, it has opened my eyes up to a new mindset of how I can approach different projects and tasks, and has allowed me to become more of an asset to assist a wider range of people when things that touch my SQL Servers break.

Why You Should Get Familiar With Source Control And CI/CD As A DBA

As I alluded to earlier, the typical normal DBA workflow involves directly touching live SQL Server environments to make changes, but it’s important in a non-emergency situation to be able to maintain a source of truth and control over what is deployed in your environment.

Not only that, if your developers are expected to use CI/CD pipelines for SQL Server deployments then you should be able to have the skillset to help them troubleshoot when a pipeline release breaks.

Zeroing in on Git and GitHub for a second here, but first let me lay out a scene for you (I’m personally guilty of it). So, you have many DBA maintenance jobs that run from one location. Those maintenance jobs happen to leverage PowerShell scripts. Now, if you’re like me, you develop the PS script, put it in some file path on the server, and have the Agent Job call it from there. Inevitably, you’ll need to update that script. So, you do that, but you create a copy of it first and add _OLD or _yyyyMMdd to it. You repeat that cycle until you have 15 scripts in that location you can revert back to in case the current one breaks or doesn’t work right.

This is where leveraging Git and GitHub can make this way cleaner and more controlled for you. There are more steps involved but operationally it gives room for better peer review when you create a PR for script modification, rollback / reverting if your new changes are breaking, and you no longer have to compile a long list of outdated scripts that sit on a server. You just make your changes in an IDE, commit it to the repo, and copy the one script (yes, I am still doing this part manually 🙂 nobody is perfect) to the server to be called by the Agent Job.

Furthermore, even though this is a low hanging fruit reason, this is what I notice the market is demanding in skillset requirements. I’ve seen tons of job postings for DBAs that want expertise in CI/CD and Source Control.

I’m not suggesting DBAs need to become DevOps engineers, but understanding the deployment ecosystem around SQL Server is becoming increasingly important.

How We Leverage This In Our Organization

We use GitHub as our Source Control and AzDO Pipelines as our method of CI/CD to govern and standardize all deployments to our SQL Servers throughout all environments. This allows for consistency and version control when making deployments, but more importantly, prevents accidents before they happen. Here’s what I mean. If a developer is pushing through commands to drop a table in Dev, Test, and Prod, by the time the release pipeline hits Prod, there are Environment Parameters set up at the pipeline level to not allow tables with data in them being dropped as that would equate to data loss. If that condition is met, it just prevented an accidental ping to the DBA saying “Hey we accidentally dropped this table in Prod that we thought was no longer in use, can you restore the database please?”

This is all to say that these processes are meant to protect us from ourselves, and if we want to override these safeguards, they are intentional. The same thing applies for us in regard to CDC deployments (adding or removing a table from CDC tracking), and other SQL Server related deployments as well.

Sometimes We Need To Bypass The Safeguards

As valuable as knowing how to function within Source Control and CI/CD as a DBA is, it’s not always warranted. For example, if there’s an emergency at 2AM, and you have one eye open and the other crusted shut, the last thing you want to do is go through the rigamarole of cloning a repo, making changes, adding, committing, pushing, creating a PR, just to solve an issue. Can you imagine trying to navigate a CI/CD process to failover your AG or stop / start the HADR Endpoint? Yeah, no thanks. So, my point is, there’s a time and a place.

How I Started Learning

I learn best by doing. So I picked a database on one of our admin servers, and added it to source control from the ground up. That means creating the repo in GitHub, creating the feature branches, importing the database into Visual Studio (in our environment we are using SQL Server Data Tools and dacpac deployments), making changes, pushing them to the repo, creating a PR, merging it to master and seeing the CI/CD pipeline push my changes through. Then breaking everything down and re-doing it again.

Not to mention, this project has been huge with exposing me to the AzDO ecosystem.

Most importantly though, I have incredible, experienced, and patient teachers. They’ve allowed me to dive into the deep end while guiding me through the nuances. So, reach out to those who know more than you and be a sponge.

Don’t Stay Stagnant

There is a lot of discussion around AI. But there needs to be more conversation around the quieter evolutions of the DBA role such as proficiently functioning within CI/CD and Source Control and how more and more organizations now expect DBAs to understand CI/CD workflows. You don’t have to master it overnight. But staying in your comfort zone of clicking through SSMS changes directly in production while the rest of the engineering world operates differently isn’t a long term strategy. Evolve. Enjoy the struggle of learning something uncomfortable. It’s worth it.