In this post I want to cover potential issues if renaming your main GIT branch in Azure DevOps. Because I have encountered a few issues doing this myself.
Of course, there has been a lot of discussions about whether you should start renaming your master branch to main recently. Personally, I have decided to do it so that what I do is inclusive for everybody.
However, I have experienced a few issues when doing this for repositories within Azure DevOps. I want to make sure others are aware of these.
Branch policies
In reality, in Azure DevOps you will probably create a new branch called main and set it to be default. Afterwards, you will then delete your master branch.
However, if you are using Branch policies in Azure DevOps you will probably get an error if you try and do this.
Now you have two options to resolve this issue.
First option is to just simply remove your branch policies and then do it. Which is fine if it’s your own test environment. However, if it’s a branch policy that’s part of a production pipeline it’s probably there for compliancy reasons and some questions will get asked if you turn it off.
Secondly, you can just treat it the same as any other change to your repository and then submit a pull request afterwards. Which is probably the best option if you need to keep an audit trail.
Pipeline changes
Now there’s a couple of things to keep into consideration once you have created your new branch.
First of all, if your pipeline is using yaml you will have to change your yaml file to use the main branch instead of the master branch.
By the way, if you are still using classic GUI based pipelines, you will still have to change your references. However, I also strongly recommend you convert your classic pipelines over to yaml as well.
Second issue which I’ve encountered whilst doing this was an interesting one. Because was something very unexpected and could well be due to something completely unrelated. However, this was the only change done before this issue appeared.
Basically, I have been dealing with a pipeline which deploys a SQL Server database to two containers with SQL Server installed. One having SQL Server 2017 installed and the other having SQL Server 2019 installed.
After changing the branch to main I got a really strange issue where the pipeline could not connect to the SQL Server 2017 instance. Now, I tried various things to resolve this but to no avail.
So, I cloned the repository to another Azure DevOps project. From there, I created a new pipeline using exactly the same yaml file and it worked first time.
With this in mind, I went back to the project that had the issue. From there, I created a new pipeline referencing the original yaml file. Sure enough, that worked first time.
Now, I have no explanation for this yet. However, if you encounter an issue after creating a new main branch I recommend recreating the pipeline using the same yaml file and then running it.
SQL Saturday Iowa
If you want to listen to me and Sander Stad talk about Azure DevOps a bit more we’ll be co-presenting our ‘Azure DevOps Duet’ session at SQL Saturday Iowa this weekend.
In fact, if you pay attention to our session you’ll see a recently renamed main branch for yourself. Of course, there are also other good sessions taking place there.
You can see the schedule for yourself here.
Final word
I hope this post about potential issues if renaming your main GIT branch in Azure DevOps is useful. Because my main intention is to help others avoid these issues, or at least resolve them quickly.
By the way, I’ve started using a different font size for my post. I’d love to hear feedback from others if you prefer this to the larger font size I usually use.
Of course, if you have any views about anything in this post feel free to leave a comment.
[…] In addition, if you watch the session you will noticed we’ve renamed our main branch. Which I discussed doing in my last post and you can read it in detail here. […]
[…] As I discussed in a previous post I have already renamed my main branches for my sessions. Because I think a little bit of effort goes a long way to show respect for attendees. Which you can read in detail here. […]