141–150 of 232 posts
I look forward to when we see the article about breaking the monorepo nightmare.
Earlier quoted context omitted.
Do you take down all of your projects and then bring them back up at the new version? If not, then you have times at which the change is only partially complete.
People that Blue Green are doing that, aren't they? Canary/Incremental, not so much
Earlier quoted context omitted.
it's also very easy to rewrite commit history in a few seconds.
If I'm rewriting history ... why not just squash? But also, rewriting history only works if you haven't pushed code and are working as a solo developer. It doesn't work when the team is working on a feature in a branch and we need to be pushing to run and test deployment via pipelines.
Weird, works fine in our team. Force with lease allows me to push again and the most common type of branch is per-dev and short lived.
Earlier quoted context omitted.
I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.
What is JJ?
Good Christ. Imagine having decided that your price structures should be a JSON file instead of persisted in a database and then thinking that any decision made by that person/team is a good idea. I look forward to when we see the article about breaking the monorepo nightmare.
Earlier quoted context omitted.
Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common
Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat
I think it’s better to always ask your devs to be concerned about backwards compatibility, and sometimes forwards compatibility, and to add test suites if possible to monitor for unexpected incompatible changes.
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.
Good Christ. Imagine having decided that your price structures should be a JSON file instead of persisted in a database and then thinking that any decision made by that person/team is a good idea. I look forward to when we see the article about breaking the monorepo nightmare.
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…
The alternative of every service being on their own version of libraries and never updating is worse.
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.
It's worth noting with a few clicks from the linked article, you can find that this company is (at least according to LinkedIn) a single person. Which explains how the whole company can fit into a repo. But also makes you question how valuable the "insights" here are, like obviously a single-person project should be using a monorepo...