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

1–10 of 197 posts

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#2

Post by markcubed »

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. Our apps are not huge but the NuGet & npm restore times now account for 25-30% of our build time.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#5

Post by GordonS »

Havoc wrote: post #3

wow that sounds pretty seriously broken. Has anybody else here actually used it & can comment?

I've been using Azure DevOps for around 2 years, and TFS for several. Most of what this article says, I simply don't see in (almost) every day usage.

The single issue I agree with is the lack of caching - installing NPM packages can take up to 15 minutes in the worst case. MS have known about this for years, so I honestly don't understand why they haven't done something about it.

I also think the hosted build machines are underpowered, despite their claims of Xeon CPUs - build on even an Azure B1ms VM (a low-powered, burstable SKU) are up to 3 times faster. In fact this is how we solve the NPM caching and performance issues - by running the VSTS Build Agent (it's OSS!) on relatively cheap Azure VMs.

Aside from these niggles though, I actually think the Azure DevOps product is fantastic.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#6

Post by codereflection »

Tangential: Reading this _really_ makes me appreciate the extremely stable system my team has build internally with GitLab and TeamCity. Azure DevOps sounds extremely frustrating (besides the point that I cannot stand the name they gave this product, and GitLab made that same mistake with the Auto DevOps feature name).

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#8

Post by taspeotis »

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.…

I exchanged an email with the Product Manager of some Azure DevOps component that comprises the build pipelines. They’re well aware of the need for caching. Hopefully it comes soon!

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#9

Post by FlorianRappl »

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, but usually all these things are not in the hot path.

TL;DR: Lots of improvements in the recent year and many things to come - it may not be perfect but it certainly is usable and provides value to our team.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#10

Post by sytse »

codereflection wrote: post #6

Tangential: Reading this _really_ makes me appreciate the extremely stable system my team has build internally with GitLab and TeamCity. Azure DevOps sounds extremely frustrating (besides the point that I cannot stand the name they gave this product, and GitLab made that same mistake with the Auto DevOps feature name).

Thanks for using GitLab!

We're open to a better name for Auto DevOps https://docs.gitlab.com/ee/topics/autodevops/ but we haven't been able to find one. Suggestions are very welcome.

BTW We're planning to add per per minute for the CI runners and add shared MacOS and Windows runners so people that don't want to manage their own no longer need to.

Post reply on HN