T-SQL Tuesday #110 – Automate All the Things

Invitation and recap from Garry Bargsley.

Have you heard the phrase “Automate All the Things”?  That seemed to be the top buzz phrase of 2018 and means different things to different people.

Kicking off the T-SQL Tuesday season for 2019, I would like to ask, what does “Automate All the Things” mean to you?  Everyone’s environment is different, everyone’s day-to-day looks different, everyone is a fan of different technologies and everyone’s environment is of different size.  While I might want to automate checking of my backup success across my 500 servers, you might want to automate how new servers are provisioned.  This can be a very broad topic, that could include a broad range of technologies.  You might choose one type of technology to accomplish a task, where I might choose another.

So technically there are two tasks for this month:

  • What do you want to automate or what automation are you proud of completing?
  • What is your go-to technology for automation?

Possible suggestions/ideas:

  • PowerShell
  • Chef
  • Ansible
  • Terraform
  • DevOps
  • tSQLt
  • Containers
  • Cloud
  • VSTS
  • Python
  • Bash
  • Code Deployments
  • VS Code
  • dbatools
  • T-SQL (honorable mention)

T-SQL Tuesday #091 – Databases and DevOps

Invitation  and roundup from Grant Fritchey.

Implementing DevOps with databases presents a unique set of challenges. However, just because something might be hard doesn’t mean that it shouldn’t be done.

I had the opportunity to work with a team of developers, database developers and DBAs under a management team that all agreed on the common goal we had, delivering more, better performing applications, faster. We didn’t know it at the time, but we were doing DevOps.

DevOps gets a bad name because, well, the problems that DevOps sets out to solve, poor communication, bad teamwork, dysfunctional development and badly configured and maintained processes, are  done by the same team that attempts to implement DevOps. However, they look on it as a purely mechanical switch that they throw, assign some poor person to the role of DevOps Coordinator (or something) and then maintain the status quo in regards to their culture and approach to software. Shocking that implementing this doesn’t work.

Then, toss in databases with the whole issues around persistence, and things go nuts.

This then, is my choice for T-SQL Tuesday. How do we approach DevOps as developers, DBAs, report writers, analysts and database developers? How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together? Please, tell me your DevOps stories.