Hacker News Reader

Comment by danesparza | Hacker News Reader

The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready

View on HN

The problem is you don't have CI

Having CI won't stop the developer of the dependency changing the interface.

Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?

Until your CI pipeline causes churn because something doesn’t work anymore....

We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).

What an awesome compliment for our team. Thank you!

Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This signal should strongly relate to your most recent changes -- and your changes should be small because you commit early and often, right?

Some of us deal with the fact that the people maintaining the CI solution keep breaking our pipelines without any code changes in of our scope of responsibility. This becomes the churn as you push empty commits trying to troubleshoot why your builds don't work and it takes >1 day to get things working again. Most hosted CI solutions are entirely inappropriate for some organization's business goals and requirements, so you end up dealing with it being a B or C tier service in an organization that is changing.

I would suggest that there are definitely some organizations where you can't trust the pipeline to work reliably, and the cost of figuring out what went wrong becomes the churn.

Reply on news.ycombinator.com