TL;DR: The author works for a Microsoft competitor and doesn't like MS products.
Strong words. Can you back that up?
I could find no evidence, looks like the guy is an android developer of some sort.
Microsoft’s Azure DevOps: An Unsatisfying Adventure
31–40 of 197 posts
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#32PM 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 without the new branding/UI is the same poorly designed product that doesn't know what it wants to be and is super un-polished. It would be better if you made it really good for one specific user scenario rather than poor for dozens.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#33What I never really understood is why does Microsoft Test Manager only come with Visual Studio Enterprise? Do only enterprises test their software?
> Do only enterprises test their software?
Microsoft also has operating expenses. They need to bring home some income to keep the lights on.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#34We are using the on-premise solution with our own build agents to build iOS. Looking to move actually into Azure Devops to reduce the effort of maintenance on our own build agents. I've been using AppCenter for hobbyist projects and I feel its been a good replacement for BuddyBuild. Seems to be pretty reliable additionally we've thrown a lot of builds at Azure Devops to validate how well those hosted-agents can handle a large project which also worked out well. So all in all, we are excited about the hosted-Mac agents as well as the flexibility to BYO-agent (helps in the transition).
I have seen a lot of these same problems noted in this link as well, just didn't see to prevent from getting our work done as much. So YMMV depending on your product/devops use case.
Personally have been using their APIs with some custom CLI scripts to get around some of these issues.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#35Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#36This 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.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#37wow 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 machine…
I'm interested to hear you have not had the same CI issues I have. One theory I have with no substantiating evidence is that Linux agents are least commonly used. The Linux agents on hosted builds run in a hypervisor but I've seemingly had the same issues running self hosted agents (as I mentioned AWS).
I can't find an actual issue and again as I mentioned in the post, replacing my AWS instance with a new AWS instance also eventually hit the same issue. Maybe it's some perfect storm of problems but that is just more speculation.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#38TL;DR: The author works for a Microsoft competitor and doesn't like MS products.
You got me, I use Linux :)
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#39TL;DR: The author works for a Microsoft competitor and doesn't like MS products.
Strong words. Can you back that up? I could find no evidence, looks like the guy is an android developer of some sort.
You are correct, I'm just an Android dev but the company I work for is a long time user of Microsoft products like Visual Studio and obviously Windows. Over time, if anything, we have become more invested in their products and I don't see that changing in the foreseeable future as they generally work well for our use cases.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#40wow 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 machine…
Regarding caching, with NPM you actually have a couple good options (best together):
1.) Make sure you are using `npm ci` instead of `npm install`. The `ci` install command is often much faster and skips a lot of stuff that `install` does. It's also better at sticking purely to your package-lock.json versions. I suggested on UserVoice at one point that Azure Pipelines should switch to `npm ci` as the npm task default. `npm ci` is a relatively recent npm command and I don't everyone has caught on to it yet.
2.) You can use Azure Artifacts for NPM packages. It acts as an alternate NPM feed and caches packages to your Azure DevOps account. Artifacts only supports NPM and NuGet, so it isn't a general caching solution, but in this specific case it helps. I've noticed the builds I have using Artifacts are a bit faster than going straight to NPM. (I started using Artifacts for private NPM packages, so I'm not using it in every build yet.) The current biggest caveat to using Artifacts as your main NPM feed for a project is that it doesn't support NPM audits currently. (I also made sure to report that on UserVoice.)