My T-SQL contribution for this month is about when I started automating SQL Server updates using Azure DevOps. Because it brought me many advantages.
This month’s T-SQL Tuesday is hosted by Elizabeth Noble. Elizabeth invites us all to talk about what something we have automated to make our lives easier. Which automating SQL Server updates using Azure DevOps definitely did.
You can read more about the invite in detail by clicking on the T-SQL Tuesday logo above.
Benefits
In reality, the main reason I was looking into this was for similar reasons as Elizabeth. Which was to make SQL Server deployments faster and easier.
However, looking into doing this initially gave me some really good benefits. Of course, it gave me a really good idea of what Azure DevOps was capable of. In addition, what it had to offer.
In addition to this it allowed me to get a better idea of how to implement it for a client. From there a vision formed in how to start implementing it for them.
After some discussions we were able to go ahead and do a proof of concept. Which we then delivered a presentation for.
From there things progressed a lot. Both for that particular project and myself personally. Because since then I’ve become a Microsoft Certified DevOps Engineer Expert.
Advice
A few times now I have been asked for some advice about building an initial pipeline in Azure DevOps. A very common question from people in the Data Platform community is where to start.
In reality, a lot of people talk about building their first pipeline for a while. Often they are planning how they think they will achieve it. Sometimes they look to see what they will need to put in place as starting blocks.
However, you can fall into a trap here by over planning things or discussing the pipeline for longer than required. Especially if you try to replicate exactly what you have in place at the moment. Because you miss the chance of taking advantage of newer functionality.
In the meantime, your original idea may be superseded by something else or your pipeline simply delayed.
With this in mind, if you have been planning for a while and still unsure where to start my advice is to simply build a test pipeline for what you are trying to achieve.
For example, if you are trying to create a pipeline for SQL Server updates, build a test one in your own Azure DevOps organization. You can read how to create your own Azure DevOps organization in detail here.
It doesn’t have to be perfect, or even how you finally intend to use it. However, building the pipeline will get you more familiar with the concepts. In addition, it will give you the confidence it will be done.
Final word
I hope my T-SQL Tuesday contribution about automating SQL Server updates using Azure DevOps helps some of you. Because my main intention of this post is to give you advice that will help.
It’s like when you first go to ride a bike. You can look at it all you want and watch others do it. However, you don’t learn to ride until you get on it yourself.
This is a good way to motivate people to just go ahead and try something new rather than overthinking it and never doing it. Thanks!
[…] lives easier. Kevin shares information about the first steps you can make in creating your first Azure DevOps pipelines. I really like how Kevin reassures us all to not get stuck in perfectionism paralysis. Kevin lets […]
[…] 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 […]