Grant Fritchey

19 November 2020

Challenges to Implementing Database DevOps: Minimum Team Size

The next question in this series of blog posts I want to tackle is:
What’s the smallest recommended size of development team that can reasonably set up and manage a DevOps process?

These questions all came from a panel discussion during PASS Summit. The audience interaction was amazing and we had so many great questions, we either didn’t get to them, or there’s more to say. I decided to answer as many as I can in these blog posts.

Minimum Team Size

Because of how we work in the Advocates Team at Redgate, I do a lot of stuff on my own, as do my teammates. However, working on my own, I make a point of putting my code into source control. It gives me a way to track changes and a nice safe backup. Because I teach database DevOps so much, I have several different pipelines in Azure DevOps Pipelines and AWS Developer Tools that I maintain and run tests on. Because of all this, I’d say the minimum team size to reasonably set up and manage a DevOps process is one (1).

I say this because I see benefits from the DevOps processes in what I do. I have some basic testing in place, so when I fat finger a bit a code, or introduce something new, like when I was first learning how to create stored procedures in PostgreSQL, I quickly find out if what I did is working. Because everything is automated and repeatable, there’s really little I have to do in order to get the tests run on my code. In short, I’m seeing real benefits in having as DevOps process, all by myself.

If we were to add people to what I do, another database developer, some application code, the processes I’ve set up might need some adjustment (I tend not to branch my own code much since I’m the only one touching it). However, overall, the processes I’ve set up that are benefitting me already, will immediately benefit the additional, imaginary, members of my team.

Now, to be fair, while I have set up a QA system, a pre-production system, and a production system and built all the necessary processes across them, they aren’t really the same as an actual production system. However, having done the work, I could easily implement the necessary changes to make everything work that way. Further, having done that work, bringing on teammates wouldn’t add risk to the system. I’ve already got protections in place to make my DevOps-style deployments work well.

So, I’d say pretty simply, that if you have two or more people, you can, and will, benefit from a DevOps-style process and automation. Will you see more benefits when you have 6-8 people on your team, as well as several teams, all working on the code? Yes. But nothing is going to keep any of this from providing protection for smaller teams too. You’ll just do a less work to set up for a team of one than you will for a team of ten.