Plenty of reasons behind this, but you might want to move away from your <organisation>.visualstudio.com URL and onto the new dev.azure.com/<organisation> URL as a matter of standards.
It is fairly easy to do - straight from the Overview Settings page of the organisation:
If you configured your Build Agents on-premise with a PAT and the old URL you are covered, the configuration will still work, plan for this in advance anyway and make sure you are prepared 👀
It is fairly easy to do - straight from the Overview Settings page of the organisation:
If you configured your Build Agents on-premise with a PAT and the old URL you are covered, the configuration will still work, plan for this in advance anyway and make sure you are prepared 👀
> Plenty of reasons behind this...
ReplyDeleteWhat are some of these reasons? Thanks!
1) Standardising the platform facade for end-users (having *.azure.com can be a requirement). This can stem to:
Delete1a) Network rules
1b) Custom applications/dashboards/etc
1c) Templates - a company relying on Azure services and nothing on-premise might want to create custom templates for intranet forms/naming conventions/etc and having portal.azure.com, dev.azure.com, etc makes life easier for the end user.
2) You haven't got anything relying on the legacy URL so you just want to shed away that small feature flag.
3) Sometimes it's easier to explain you are going to access an Azure service, instead of a Visual Studio (developers! technology! complicated stuff!). Think end users' stuff like dashboards, reports, etc
4) You might want to change the Git repository commands you use right now, instead of a few years down the line (https://dzone.com/articles/vsts-name-change-in-azure-devops-effects-on-git-re)
...
I see plenty of reasons :-)