51–60 of 232 posts
Earlier quoted context omitted.
squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess
What about separate, atomic, commits? Are they squashed too? Makes reverting a fix harder without impacting the rest, no?
people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…
Earlier quoted context omitted.
squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess
Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.
I can spend hours OCDing over my git branch commit history.
-or-
I can spend those hours getting actual work done and squash at the end to clean up the disaster of commits I made along the way so I could easily roll back when needed.
I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.
Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.
This is sort of a whole product , but it’s hardly managing the whole company . Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.
How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.
I do it naively. Maintain the backend and frontend separately. Roll out each change in a backwards compatible manner.
Of course, it’s still a pretty rough and dirty way to do it. But it works for small/demo projects.
This is sort of a whole product , but it’s hardly managing the whole company . Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.
maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO."
theres a lot of power i think to have everything in one place. maybe github could add the notion of private folders? but now thats ACLs... probably pushing the tool way too far.
people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…
We have a monorepo, we use automated code generation (openapi-generator) for API clients for each service derived from an OpenAPI.json generated by the server framework. Service client changes cascade instantly. We have a custom CI job that trawls git and figures out which projects changed (including dependencies) as to compute which services need to be rebuilt/redeployed. We may just not be at scale—thank God. We're a small team.
I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.
Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.
The moment you have two production services that talk to each other, you end up with one of them being deployed before the other.
I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.
Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.
Cherry picks are useful for fixing releases or adding changes without having to make an entirely new release. This is especially true for large monorepos which may have all sorts of changes in between. Cherry picks are a much safer way to “patch” releases without having to create an entirely new release, especially if the release process itself is long and you want to use a limited scope “emergency” one.
Atomic changes - assuming this is related to releases as well, it’s because the release process for the various systems might not be in sync. If you make a change where the frontend release that uses a new backend feature is released alongside the backend feature itself, you can get version drift issues unless everything happens in lock-step and you have strong regional isolation. Cherry picks are a way to circumvent this, but it’s better to not make these changes “atomic” in the first place.