Everything as code: How we manage our company in one monorepo

231–232 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#231

Post by yencabulator » Mon, Jan 05, 2026, 8:58 PM UTC

array_key_first wrote: post #230

yencabulator wrote: post #229

Earlier quoted context omitted.

Monorepo vs not is not the relevant criteria. The difference is simply whether you plan your rollout to have no(/minimal) downtime, or not. Consider SQL schema migration to add a non-NULL column on a system that does continuous inserts.

Again, that's trivial if you use up and down servers. No downtime, and to your users, instant deployment across the entire application. If you have a bajillion services and they're all doing their own thing with their own DB and you have to reconcile version across all of them and you don't have active/passive deployments, yes that will be a huge pain in the ass. So just don't do that. There, problem solved. People n…

Magical thinking about monorepos isn't going to make SQL migrations with backfill instantaneous and occur simultaneously with the downtime you have while you switch software versions. You're just not familiar with the topic, I guess. That's okay. Please just don't claim the problem doesn't exist.

And yes, it's often okay to ignore the problem for small sites that can tolerate the downtime.

Re: Everything as code: How we manage our company in one monorepo

#232

Post by literallyroy » Tue, Jan 13, 2026, 8:41 PM UTC

Denvercoder9 wrote: post #128

literallyroy wrote: post #96

Earlier quoted context omitted.

I’m all ears for a better approach because squashing seems like a good way to preserve only useful information. My history ends up being: - add feature x - linting - add e2e tests - formatting - additional comments for feature - fix broken test (ci caught this) - update README for new feature - linting With a squash it can boil down to just “added feature x” with smaller changes inside the description.

If my change is small enough that it can be treated as one logical unit, that will be reviewed, merged and (hopefully not) reverted as one unit, all these followup commits will be amends into the original commit. There's nothing wrong with small changes containing just one commit; even if the work wasn't written or committed at one time. Where logical commits (also called atomic commits) really shine is when you're m…

Thanks for the reply :]

That seems better as long as you can keep it standard across the team. I don’t usually check each commit when reviewing since frequent iterative commits mean folks change their mind and I’d review already removed logic when looking at early commits.

I’ve been scraping by on basic git usage so didn’t know about fix-up commits, that’s excellent.

Post reply on HN