Hacker News Reader

Comment by GordonS | Hacker News Reader

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.

View on HN

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

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.

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.

I was completely unaware of `npm ci`, so I'll definitely check that out. We'll stick with hosted agents that do caching though, as the hosted build agents are really slow.

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.

Reply on news.ycombinator.com