Implementing first database deployment pipeline as a team

Reading Time: 4 minutes

In this post I want to cover implementing your first database deployment pipeline as a team. Because I was asked about this the other day.

Now this post applies to whether you are building a database deployment pipeline for the first time ever or migrating to a new service which offers this.

Of course, this post applies mostly to people who currently work in teams as opposed to people who work alone. In addition, even though this is based on SQL Server database deployments this could also apply for any deployment pipeline in any service.

For example, Azure SQL Database deployments using Azure DevOps or Kubernetes deployments using GitHub Actions.

Now there are various reasons why you are looking to build your first deployment pipeline somewhere. For example, the direction of the business or the fact your manager has asked for it to happen.

I believe that implementing your first database deployment pipeline for a business should very much be a team effort. It’s very important to remember this fact for various reasons. Most important reason being that without their buy in whatever you attempt will likely fail.

To get the time allocated to do this you need buy in from your peers. In addition, you also may need buy in from other stakeholders as well.

Colleagues in team

You will need to get buy in from your colleagues in your team first. Because if your team is already using an Agile related framework like Scrum you need to have the time to develop this.

If you have experience with this already that’s great. Because it means you can show them the advantages of this. If you do have the experience already it’s important to remember that it’s about bringing the whole team up to a certain level to implement this not doing it all yourself.

It also brings other advantages as well. For example, you can show your colleagues where they can learn more about building deployment pipelines.

However, if not I recommend you do build at least one deployment pipeline that using the proposed method first. Like I discussed in a previous post here it does not have to exactly match the final outcome. Just close enough to gain the experience.

Because if the team agrees they want to build their first pipeline somebody has to come up with the initial work items for them to do. If you have the knowledge already you can come up with the initial plan for them. From there, they can add more items as they learn more.

In addition, building a deployment pipeline a new way yourself means you can confidently answer any questions your colleagues have.

Deployment pipeline buy in from stakeholders

Like I said before you may also need buy in from other stakeholders. Especially if they are waiting for work from your team. Of course, your management are probably the first stakeholders to approach.

If your team is split between developers and operations team members you have to get buy in from everybody in the team if you wish to continue doing this. My advice is to get them together and propose to give the engineers time to do a proof of concept.

If you do get the team to agree, make sure you get input from them first. Listen to their views instead of telling them what you are going to do.

Database deployment pipeline Proof of concept

Once you get the go ahead for a proof of concept make sure both yourself and your colleagues are as prepared as possible. Like I said before it’s a team effort and not about yourself.

With this in mind, do as much to help your colleagues before the proof of concept is due to start. Share with them where you got your knowledge from.

Another thing you can do to help them prepare is make sure they have the right tooling. For example, if you intend to do something that is only possible in Visual Studio Professional make sure they have the right licenses beforehand.

If you are proposing to manage SQL Server Database projects in Azure Data Studio instead, make sure they have it installed. I talked about using the extension to do this in a previous post about creating Database Projects in Azure Data Studio. It is now available in the stable build.

Preparing the whole team better will reap benefits. I can assure you of this fact.

During your proof of concept make sure you mimic the environments you intend to deploy to in the long run as much as possible. In addition, have a good idea of how you intend to report the outcome of these deployments. Because you will get asked questions about these kinds of things.

Database deployment pipeline presentation

Once done you can show your proof of concept to other team members or stakeholders. Personally, I recommend that you make this an interactive presentation. Ask them what scenarios they want to see and get them involved in approving deployments on their own laptops.

Go through various scenarios with them, including roll-back and roll-forward. Because in the real world both can happen.

If you do this there is a bigger chance everybody will be on board. From there you can look to implement whatever deployment pipeline you have in mind.

Final word

I wrote this post because I think implementing your first database deployment pipeline as a team is an important thing to do. Especially if there are amazing engineers in your team.

Thinking about everybody in the team before even putting the first proof of concept or initial pipeline can have massive benefits. Of course, learning as much as you can beforehand to share with your colleagues is just as powerful.