[windexh8er]

The whole pipeline debacle is confusing. I recently did a demo at a Microsoft DevDays showing Microsoft hosted Ubuntu 16.04 agents in my build and then a self-hosted vsts-agent container (provided by Microsoft which still has the old name, why?) and part of the point was to show how slow not having caching is, even for a simple Python build pipeline. On top of that Microsoft has some odd pricing in that they limit your self hosted pipeline concurrency to 1 unless you pay them. That seems like a bad decision because most people would probably go through the effort of spinning some VMs natively in Azure which would increase overall OpEx. But instead, like the OP of the article, people will self-host on prem or in another/cheaper cloud. Microsoft gives no incentives to use native build agents (they are unreliable and slow) and almost force users to go self hosted but also charge for concurrency.

I've also had very odd issues where agent pools will have an idle worker but the pipeline will sit saying there are no agents, waiting. Eventually it goes, but... It's just a bad impression when you're showing it and it's not consistent.

Also, the UI. Tis horrible. Take a nod from AWS guys and get rid of the widgety attempt at entertaining some exec who doesn't use Azure. AWS interfaces load consistently for the most part and do a much better job in being not annoying, comparatively.

Another bad user experience is if you write a pipeline, by hand, without the GUI and try to run your pipeline - well, good luck. Authorization for certain components of your pipeline will fail, even if they follow the pipeline documentation to the T. Why? Because the pipeline web GUI workflow does linking of authorization between components on first run and if you only kick your build off using, say a code check-in, the pipeline will just fail. And it will give you a non-descript authorization error until you pull all your hair out and randomly do a commit from the Repository GUI of which it will pop up a message asking you to authorize the thing that had been failing for the last hour. Either document this better or give users a descript error of the actual problem. This, again, is oft where I find Azure lacking.

[vijayma]

I am from the engineering team in Azure Pipelines. We agree that the resource authorization experience needs improvement. We have been working on it. We would like to make sure that you can only include the reference to a resource (secure file, service connection, variable group, agent pool, etc) in your YAML file if you have permissions to access that resource. And, it becomes particularly hard to auto-validate this if you are pushing your YAML change directly to GitHub or another repository since we do not understand the identity of that user. If we are not sure, then the build fails with a resource auth error. You can do two things to rectify this - (a) with a recent change we rolled out, you can allow all pipelines to use a resource. This is a toggle that you will see on the resource (b) You can get someone with permissions to open the pipeline in the Pipelines hub of Azure Pipelines, and queue a build. You will get an option to correct the resource auth problem. We also made a recent change so that new resources that you create default to "usable in all pipelines". We are taking steps to improve this experience without compromising on the security of these resources for those that need that capability. More is planned in this area over the next couple of months. Thanks for understanding. I will also update the docs on this topic with all the updates that have been rolled out this week.

[windexh8er]

Thank you for the great explanation on changes you've made and will continue to make in this area! What is the best way to inform persons such as yourself about UX issues? Appreciate the thoughtful response.

[matthewisabel]

I work on the UX side and you can email me at firstname.lastname @ microsoft.com (it's my username and in my profile).