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

161–170 of 197 posts

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#161

Post by sandGorgon »

giaour wrote: post #134
sandGorgon wrote: post #104

Earlier quoted context omitted.

Same here. Azure has a killer feature in India that neither AWS or Google have - multiple data centres. Because of Indian data residency guidelines, that becomes critical for business continuity planning. But the Azure UI is so bad that people are willing to forego stuff like that just to avoid being on Azure. The Azure product teams have asked for feedback from startup multiple times with consistent answers on UI -…

AWS has a full region based in Mumbai (ap-south-1) with multiple availability zones, each of which consists of multiple data centers.

umm.. yes we are all aware of this.

Its a single geographic region. Its not allowed according to financial or healthcare data regulations in India.

P.S. i personally am working with the "Big 4" consulting guys to get a white paper to work with this. But big missed opportunity for Azure. All because of bad UI.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#162

Post by [deleted] »

matthewisabel wrote: post #28
Novashi wrote: post #16

Earlier quoted context omitted.

I dunno if you guys have gotten feedback on this, but the difference between build artifacts, artifact feeds, and the output of some pipelines' tasks in terms of artifacts is really confusing. I know it's probably getting translated to yaml from the old way which was a bunch of forms with build options, but we had some trouble with this. At the time, yaml releases were also still in development/preview mode. One thin…

Azure Pipelines PM here. Definitely hear you on the current YAML experience. We're working on updates to the editor now to allow you to quickly browse and insert task snippets. It's going to be a big improvement.

[deleted]

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#163

Post by Annatar »

patrickg_zill wrote: post #139
Annatar wrote: post #88

I'm genuinely curious: what exactly is so hard about installing and system administering one's own servers inhouse that so many people would put up with these complications?

There isn't any true difficulty; people are running multiple sites that could all fit into 1 dedicated 64gb RAM server from Hetzner on a different infrastructure that allows them to develop their resume...

Are you saying that it's simply a case of resume inflation at employer's expense?

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#164

Post by patrickg_zill »

Annatar wrote: post #163
patrickg_zill wrote: post #139

Earlier quoted context omitted.

There isn't any true difficulty; people are running multiple sites that could all fit into 1 dedicated 64gb RAM server from Hetzner on a different infrastructure that allows them to develop their resume...

Are you saying that it's simply a case of resume inflation at employer's expense?

Sometimes yes. It's not just DevOps but CVops :-)

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#165

Post by sl1ck731 »

chupasaurus wrote: post #129
sl1ck731 wrote: post #94

Earlier quoted context omitted.

For us its: availability outside of VPN and avoiding the run around of making a public site with security, integration with active directory, has repos + a wiki + boards all in one place. No configuring 3 different OSS products to integrate with AD. We use the other stuff more than the CI, but will probably begin using it for some more smaller projects soon. It'll be in the same place which is great and no need to ti…

If you have problem with configuring service users in AD, I guess you have problems with security or group policies on a regular basis.

Or AD isn't our responsibility and we can just use the tool (Azure devops) that is already done before we even launch it and provides all the features we need?

I guess you don't have more important things to be doing than screwing with ancillary tools.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#166

Post by WorldMaker »

stonogo wrote: post #62
WorldMaker wrote: post #40

Earlier quoted context omitted.

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…

Why on earth would you use a different deployment stack in CI than you would in production? This seems to miss (at least) half the point of integration testing. Making this decision is bad enough, but making it because you've chosen a bad CI/CD stack is even worse. Use the tools that work, instead of breaking things to match.

I'm not sure to what you are referring.

Are you talking about Azure Artifacts? Like I said, I'm using Azure Artifacts as a Private NPM repository for proprietary packages. It also providing caching benefits was a pleasant surprise.

For my projects using Artifacts as their NPM repository, they use an .npmrc at the repository top level to only use that feed (and its pass through capability to the public feed), so for those projects it is the same stack from dev through to production. As I said, the one caveat is that if I need to `npm audit` (which is generally a good idea) I currently have to redirect to the main public NPM feed. Other than that it is a solid replacement NPM feed.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#167

Post by WorldMaker »

Yuioup wrote: post #85
WorldMaker wrote: post #40

Earlier quoted context omitted.

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…

I find it weird that in order to fix a problem Microsoft has created (slow builds due to lack of caching) is to give Microsoft more money. Artifacts isn't free.

Sorry, it's easy to forget what the commodity prices of some of the Azure DevOps tools are given that various combinations of MSDN licenses and Office 365 plans cover them. It's great that you can pick and choose now, though.

Like I said, caching is only a useful side effect of Artifacts for npm and NuGet users (that have access to Artifacts). I would believe/hope that Microsoft may still have interest in adding proper caching to Azure Pipelines directly.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#168

Post by CuriousSkeptic »

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, run and debug most, or all, of the steps in the graph on my development machine without roundtripping through long chains of triggers and pushing to code repos and pull requests

- I want to run as much as possible in parallel, preferably agnostic of wether it’s on the same machine or several

- I need to build and assemble many components from same repository (monorepo setup)

- only impacted components should build

- Sub-components may depend on different build tools (service fabric services with both webpack and msbuild based packages)

- Some steps may depend on configurations and secrets with a different lifecycle than the code branch being built

I imagine something clever could be built on docker to support both running things locally as well as customize build nodes.

I don’t care to much for scripting in yaml. In fact I spent the day converting some yaml (and cake) scripting to Invoke-Build. Invoke-Build is quite nice actually, the only thing I miss is the option to orchestrate tasks in parallel onto several build nodes. That plus something like ncrunch build/test engine for csharp projects

(really the entire vs/msbuild things needs to be replace with something truly distributed, incremental and repeatable)

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#169

Post by raxxorrax »

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…

This is very interesting data, thank you for that. Maybe MS has improved a bit although I haven't felt any improvements yet. But the changes might not be rolled out completely. Performance wise it can only get better in my opinion.

Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure

#170

Post by ethomson »

ToFab123 wrote: post #141
ethomson wrote: post #120

Earlier quoted context omitted.

Sorry, I don't understand what you're seeing here - you're creating a new project in Azure DevOps? When you do this, you get the choice between Git (hosted in Azure Repos) or centralized version control (TFVC hosted in Azure Repos). We don't have an option to do anything with GitHub here. So I think that I'm not understanding what you're creating, or where. Can you drop me an email with a screenshot? It's my HN usern…

I will clarify. if you go to portal.azure.com --> Create a resource --> DevOps project --> Bring your own code --> In code repository you can choose between "GitHub" or "External Git". What I expected was that I could point it at VisualStudio.com - unless vsts has become the external git? ps: happy azure devops / azure user here ;)

Aha, through the Azure Portal. I'm not sure what that works that way. I'll look into it, thanks for the explanation.
Post reply on HN