Microsoft’s Azure DevOps: An Unsatisfying Adventure • Hacker News Board

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#171

Post by seanjregan » Thu, Jan 24, 2019, 7:54 PM UTC

dustinmoris wrote: post #109

Makes me really appreciate my setup of: - GitHub for source control - AppVeyor for CI - BlazeMeter for Load Testing - Google Cloud for Cloud Hosting - Slack for Team Chat - MyGet for private NuGet feeds - Trello for task management - ELK cloud for log management Yes it is many different services, but as a small team I like that we can pick the best tool for the job instead of trying to find a hammer for all nails whi…

I was just building a presentation on this topic and the power of an open approach.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#172

Post by tracker1 » Fri, Jan 25, 2019, 12:42 AM UTC

elmalto wrote: post #51

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 use Azure DevOps extensively at my work and, after having used GitHub, Gitlab, self hosted solutions, Jenkins, TeamCity... DevOps ranks dead last. It's the entire experience. The UI is terribly clunky everywhere. The worst for me are pull requests. Incredibly tough to work with people on a pull request. I can't even point you to "a" particular problem - for us it's broken everywhere. From the weird file comparison…

One additional point... it would be GREAT if I could have a chat channel in MS Teams with just notifications of @user/group where I am a part of that user/group in VSTS. I get so many emails, I really can't/don't keep up with it. Generally, email for this type of thing sucks, and the email doesn't show the meat of what you need to see.

A dashboard interface for messages/notifications in VSTS would be helpful.

Aside, switching to a GraphQL type interface with something that updates your UI consistently would be nice. Some screens update fine, others just get lost/disconnected and you don't even know where you are at.

Overall, I haven't experienced the agent issues in TFA, but I've had plenty of other issues and continue to use the beast that I know. I do think the issue tracking is decent and the integration is as nice as other products I've tried imho. Sometimes simpler is easier though.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#173

Post by tracker1 » Fri, Jan 25, 2019, 12:47 AM UTC

withinrafael wrote: post #65

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…

Windows Development MVP here. I feel like I must shoulder some of the responsibility here for not being louder about these issues. But must say, I'm disappointed to hear you're "surprised" about the UX issues. I've been telling your folks the UX is dreadful (e.g. as far back as pre-launch) and kept hearing back "we know, we're fixing it". I'll start formalizing the feedback and push it through the pipes, stay tuned.…

To your path issue... most of my own pipelines do an `npm run STEP` and I use JS scripts mostly... this covers me in window, linux and macos for the most part with Node. ymmv here though. That's just my $.02 and it's been relatively easier doing it that way.

I kind of wish $bash (git for window's bash version) was available as a shell option as that might make things easier as well.

Another issue is searching is painful... "TFS" vs "VSTS" vs "Azure DevOps" and half the time, the results are dated.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#174

Post by tracker1 » Fri, Jan 25, 2019, 12:53 AM UTC

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…

I kind of wish they'd promote whoever is the UX lead for MS teams to cover other products... it's by far my favorite windows app, second to VS Code.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#175

Post by tracker1 » Fri, Jan 25, 2019, 1:01 AM UTC

Someone1234 wrote: post #30

We use paid Azure DevOps for Source Control (although we're watching GitHub closely). We tried to also use Azure Boards (Work Items, Boards, Backlogs, etc). Ouch. It is a complete UI mess of disjointed ideas. Instead of implementing one thing well, they implemented two dozen things terribly. We actually migrated from Azure Boards to Office 365's Planner (KanBan) just because the UI wasn't so horrible. It is simple an…

I don't even use VS if I can avoid it... web dev is so much smoother in VS Code, and the laginess of VS is unbearable to me. I do have a couple .Net Core projects I mostly use in VS Code and one MS SQL DB project that I have to use VS for.

May want to checkout GitLab as an option as well.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#176

Post by tracker1 » Fri, Jan 25, 2019, 1:04 AM UTC

fastbeef wrote: post #100

Look, developer tooling is always going to be hugely dividing. Some will love it, some will hate it, some will hate it because it's not like the Thing They Loved At Their Previous Job. Now, can we talk about the real WTF, which is the name. "Azure Devops", really? Two extremely potent keywords each on their own? You didn't like people being able to google answers to their questions about your product?

TFS, VSTS, "Azure DevOps" and often the results are outdated... "ADO" won't work either. They probably should have stuck with VSTS and just kept the abbreviation or made it "Azure VSTS" where vsts would at least continue to be searchable.

Another nicety would be to pay StackExchange to add an Azure DevOps subsite, assuming there isn't already one.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#177

Post by throw_away2 » Fri, Jan 25, 2019, 1:57 AM UTC

skriticos2 wrote: post #105

throw_away2 wrote: post #72

Earlier quoted context omitted.

This mimics the mac vs windows argument I had with my brother-in-law where it boiled down to the fact that you could run windows on something cheaper than a macbook. Even though in order to remap caps lock to something reasonable you have to edit the registry. In 2019. The best answer I think involves windows server 2003 resource kit and its UI, which is so old it could get a driver's license. You save money but what…

It's not even about the price. I have no problem tweaking my Linux desktop to use an international Dvorak layout (useful for those European languages with ä's and é's) and switching the caps and ctrl keys. Say what you want about Gnome 3, but this works just fine. On Windows.. I get a US only bare bone Dvorak layout and few ways to remap the caps/ctrl keys. Messing with the registry is at best annoying on my gaming (…

I would love to find an .xinitrc in some dark corner of windows 10 where there are a bunch of options commented out and you have to pick the right ones or else your monitor explodes.

This would be an upgrade as at least I would kinda trust that a file I found on my own system from the vendor can probably be trusted. I trust the options would be at least mostly self documenting (more self documenting than a random list of hex digits). And, if I'm going to use software written in the 90s, I'm going to go with good old vim.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#178

Post by achievingApathy » Fri, Jan 25, 2019, 3:45 AM UTC

darkcha0s wrote: post #113

achievingApathy wrote: post #86

Earlier quoted context omitted.

It just strikes me as an odd thing to put on a luxury tier like that. Reiterates that quality and testing is often an afterthought rather than something everyone should include. If MS wanted the revenue they would put something the most senior higher paid developers wanted rather than the testing team.

You have plenty of alternatives...

True, but I thought the goal of Azure DevOps was to be a complete package solution. And so while all the pipelines and code and work items are stored there, it would be a pain to keep test cases in something else. And why no integration with Excel?

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#179

Post by dtrailin » Fri, Jan 25, 2019, 4:46 AM UTC

stevenacreman wrote: post #122

raxxorrax wrote: post #106

Interesting post. I feel for him using this tool. Had my own experience with team foundation server on premise. Although a different tool, many of the problems seem quite similar. A little rant: To the cloud infrastructure of MS: I don't know if anyone uses it for anything serious and doesn't complain about severe performance issues not only related to builds, but everything. From administrative sites to hosted envir…

This is true of all of the services I've tried across Azure, AWS and Google cloud. Microsoft are always last place in terms of performance and reliability. For Kubernetes I actually keep track of exactly how bad they are with an automated testing tool. Results of the last test are here: https://kubedex.com/is-azure-kubernetes-aks-any-less-terribl... I've complained about UX before in the context of the Azure portal b…

You should do an updated test comparing AWS as well. I feel like there should be more continuous benchmarking efforts of cloud vendors. This is the last one I remember in this genre (https://www.azurefromthetrenches.com/azure-functions-signifi...). I wonder if someone could make a business doing that.

Also, I've found in terms of UX GCP > Azure > AWS personally.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#180

Post by bananadonkey » Fri, Jan 25, 2019, 11:11 AM UTC

CuriousSkeptic wrote: post #168

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’m considering migrating an appveyor setup to devops. The main driver is to get a pipeline setup with more parallelism and a more complex graph with resumable steps without fiddling with environment parameters, or really jumping around in a clunky ui maintaining a hundred “projects” Haven’t looked to deeply what devops has to offer yet, but things I’d be looking for before migrating. - I want to be able to develop,…

I can recommend https://concourse-ci.org/ for pipelines that are difficult to reason about or orchestrate in, e.g. GitLab and other CI tools, due to external actors or lifecycles beyond a single codebase/repo.

Builds are 100% stateless within the CI cluster and rely on tracking/publishing just about anything you can imagine or plug as a resource; out-of-the-box inclusions being docker images (registry), S3 (e.g. minio, AWS) and git.

It's a bit strange to reason about in the beginning but I have yet to try anything that comes remotely close to Concourse when it comes to orchestrating across multiple sources of input/output and non-linear pipelines.