undefined | Better HN

0 pointsfrenchman993y ago0 comments

> You're waiting for compilation, CI/CD, deploys, because of a bunch of irrelevant stuff.

You could setup your CI to only recompile what's changed, so you wouldn't be waiting for anything else than what you've changed. This usually requires a bit of work upfront, but once you've done it for 1 part of the codebase it is easy and low-maintenance to replicate to the entire codebase. With Gitlab CI (and others), you can import bits of yaml configuration here and there to avoid code duplication for such use cases.

> I'm personally against microservices

In some cases, you need microservices or at least being able to run only a single part of the monolith through configuration. For instance if you want to host parts of the codebase in a separate virtual machine for security or scalability.

I don't think the choice is a matter of opinion but a matter of technical/business requirements.

0 comments

camgunz3y ago

Well, that's my point. The default for pretty much all your tools is "one repo one project". If you don't want tools to work on the entire repo, you've got to configure them specially, if that's even possible, and you have to hope it works well.

You've gotta weigh the trade off of whatever benefit you're getting from monorepos against the irritation of tooling that doesn't really countenance them.

FridgeSeal3y ago

> You could setup your CI to only recompile what's changed, so you wouldn't be waiting for anything else than what you've changed.

What’s it like having CI pipelines that aren’t trash? I’m stuck with the awful choice of CI tool my work has made, and there’s not a lot I can do about that.

j / k navigate · click thread line to collapse