Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft’s Azure DevOps: An Unsatisfying Adventure

toxicbakery.github.io

Post reply on HN
Print view View original

41–50 of 197 posts

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#41

Post by chrisrpatterson »

toxicbakery wrote: post #36
smadurange wrote: post #18

This article is nonsense. Azure DevOps is a delight to work with. PR system is probably the best I've worked with so far. Build pipeline can improve but it's a far cry from a "horrifically broken". IMHO, Microsoft has been getting a lot of things right lately. Keep up the good work.

Horrifically broken was an exaggeration, you are correct. Much of this was written after a stressful day compounded by dealing with our CI failing to do the thing it is supposed to do. I also agree with you that Microsoft has been making great strides in the direction of "getting a lot of things right lately" as you said.

We really hate to hear you are having such a bad experience. The engineering manager has reached out on Twitter and included me. I would love to see what I can do to help

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#42

Post by toxicbakery »

FlorianRappl wrote: post #9

We use Azure DevOps for a fairly large project and so far its working good (i.e., not great, but better than okay-ish). The point with the lost communication is something we also experienced more often than I would wish for, however, on a standard day I do not see the issue appearing at all. Yes, the mobile page could be optimized (but this is not a deal breaker) and yes some pages do not subscribe for notifications,…

The majority of the product indeed does work pretty well. We make heavy use of their Boards and Test Plan features and outside of specific but minor UI/UX complaints, it is a competent tool.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#43

Post by zoeysaurusrex »

Someone1234 wrote: post #32
ethomson wrote: post #12

PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…

> We've been investing heavily in our user experience and our CI/CD experience I'm on the "new" UI and I'm not seeing it. You've just re-skinned the same buggy and broken cruft that was there before. It reminds me of the Visual Studio 2019 blog posts about new icons, themes, and fonts as their big new features while ignoring the massive performance problems people have been asking about for years. DevOps with or with…

Honestly, while your criticisms are mostly fair, your approach is really unprofessional here. Yes, Microsoft is a massive company, but human beings are making this and I’ll guarantee you none of them are happy with where the product is. Please consider showing some compassion.

I’d also add that I use 2017 and 2019 daily, and build by build, I see massive improvements for performance.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#45

Post by titanix2 »

ethomson wrote: post #12

PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…

I spend a few hours recently in Pipelines and the whole UI is confusing. One of the offender being the edit button being literally at the other side of the screen. Outlook.com UI was also recently destroyed so it is hard to trust Microsoft services, even if good, will stay usable in the future.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#46

Post by zeeshanejaz »

We migrated from TeamCity and OctopusDeploy a couple of months ago and we are already regretting it. The reliability of this system is just horrendous. The documentation is pretty much outdated, and quite a few plugins do not work. I have to write a bunch of powershell script to get it to work the way I want. And today, all hell broke loose.

Since this morning, we are stuck with an error message "TF400893: Unable to contact the server. This is most likely caused by a network error. Please check your connection and try again.". This has cause a couple of release pipelines to be get stuck, with cancel option not working either. The paid "parallel jobs" are being consume in this stuck pipeline and no other project from my organisation can be built or deployed because of it.

Pretty much regretting having spent so much time configuring the pipelines. We might switch it doesn't get resolved soon or if it happens even one more time.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#47

Post by ianceicys »

At my company we use a mixture of Azure DevOps, Jenkins, CircleCI, Github, Jira, Artifactory, and a host of AWS and Azure, and my view is that Azure DevOps (formerly VSTS, formerly VSO, formerly TFService, formerly TFS, formerly VSS---i kid i kid) is a semi-strong product that just can't get out of its own way.

The New UI is a clear step backward...and the Github integration leaves a lot to be desired. If you have Github Enterprise...why use Azure Repos...why are MSFT teams moving from Azure Repos to Github...and others moving from Github to Azure Repos. The SCM platform and strategy obviously hasn't settled yet...so Gitlab is just as viable an offering that's growing more compelling by the day.

The Azure DevOps hosted build system hasn't been viable in my opinion since it launched, so on-prem agents are a much better option. Take a look at CloudBees offerings, they set the poll position.

The key thing that continues to be a pain point is the reporting and project organization data structure limitations with Azure DevOps: is it 1 TPC per business unit, 1 TPC for the whole company, 1 team project for the whole company. What happens when you have 2...how do you consolidate...what's the path forward if you have to move things around. The answer for the last 8 years has been silence.

The request for a clean solution has been asked for since 2011. Yes 2011, look at the link below. 8 long years...and basically silence...and "it's a hard problem"...and multiple updates saying "We will provide an update once we start planning for the second half of 20XX."

https://visualstudio.uservoice.com/forums/330519-azure-devop...

Eventually, the promises just ring hollow, the proof is in shipped code, and in the meantime other platforms and competitors stacks keep building out better enterprise stories for migrating from Azure DevOps (here's to look at Github, Gitlab, Atlassian's platforms, Jenkins/CircleCI, TeamCity, Artifactory, Xebia Labs etc).

Honestly, the world is a MUCH more competitive place with lots of best in class point solutions that aren't that hard to stitch together and get better performance/features.

Hope springs eternal...that with the new vertical offerings the DevOps team can deliver rapid value...but 8 years is a long time to only hear crickets.

If you're starting out and you need a one-size fits all solution and you're a SMB company with two doze devs...go hog wild with Azure DevOps...that's not to say it doesn't work for large companies like Shell and Microsoft itself...but talk with teams about the limitations they run into and make your own decision on your DevOps transformation adventure...oh and never create more than 1 team project in Azure Devops...seriously...if you do, game over.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#48

Post by taspeotis »

Someone1234 wrote: post #32
ethomson wrote: post #12

PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…

> We've been investing heavily in our user experience and our CI/CD experience I'm on the "new" UI and I'm not seeing it. You've just re-skinned the same buggy and broken cruft that was there before. It reminds me of the Visual Studio 2019 blog posts about new icons, themes, and fonts as their big new features while ignoring the massive performance problems people have been asking about for years. DevOps with or with…

Generally the whole area gets a continuous stream of small and big features. You can click through the release notes [1] and see the changes they've made. Over the past twelve or so months they've jettisoned XAML-based builds and added YAML builds.

As someone who's used it through VSO/VSTS/ADO days it's got foibles but yes, it's improving continuously.

[1] https://docs.microsoft.com/en-us/azure/devops/release-notes/

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#49

Post by taspeotis »

avinium wrote: post #21
markcubed wrote: post #2

While I certainly have had a few annoying issues myself, full credit to the team behind DevOps (nee VSTS) for doing an amazing job over the last >12 months to overhaul and improve the product. I have been impressed at the pace things are improving. I have not had the same issues with build machines disappearing into the ether (we use Windows hosts however) but definitely agree that the (lack of) caching is maddening.…

Yeah, this has been my experience. I haven't had a build agent disappear, but lack of build caching is very frustrating. The hosted build agents are slow to begin with, let alone needing 5 minutes for every build to restore packages. AFAIK there's no way to "only run changed tests" too. EDIT: Forgot to add that, despite the above, I'm pretty happy with it. The whole VSTS experience (Wiki/code/PRs/etc) is pretty great…

> AFAIK there's no way to "only run changed tests" too.

https://docs.microsoft.com/en-us/azure/devops/pipelines/test...

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#50

Post by windexh8er »

ethomson wrote: post #12

PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…

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.

Post reply on HN