3 ms·

that doesnt seem like a problem with monorepos (or otherwise). youd just need to tag your releases, right?

aranchelk 5y ago
I don't think it's a problem, rather I'm challenging a touted benefit. In large monorepos the supposition is you've got a class of compatible apps and services bundled together. Version dependencies are somewhat implicit: the correct version for each project to interoperate is whatever was checked-in together in your commit. I don't know how it works in practice at different orgs, but there's certainly an idea I've heard repeated that you can essentially test, build, and deploy your monorepo atomically, but the reality in my experience is you can't escape the need to think about compatibility across multiple versions of services once you use techniques like canary testing or targeted upgrades.
- staticassertion 5y ago
  You still have to think about compatibility across versions - that does not go away in a monorepo, and you should use protocols that enforce compatible changes. The monorepo just tells you that all tests pass across your entire codebase given a change you made to some other part.
  - eximius 5y ago
    thats fair. you require reasonable deployment intervals and may need to wait to merge based on deployment. Workflow actions that can check whether a commit is deployed in a given environment are invaluable
    - jeffbee 5y ago
      > may need to wait to merge based on deployment Again, this fundamentally misunderstands the purpose of the source code repo and how it relates to the build artifacts deployed in production. If you are waiting for something to happen in production before landing some change, that tells me right there you have committed some kind of serious error.
      - joshuamorton 5y ago
        I'd caveat this with code change. Its very common to need to wait for some version of a binary to be live before updating some associated configuration to enable a feature in that binary (since the dynamic configuration isn't usually versioned with the binary). It's possible that some systems exist that fail quiet, with a non-existent configuration option being silently ignored, but the ones I know of don't do that.
      - eximius 5y ago
        I'm not sure I agree? If I'm waiting on an update in a 3rd party library... you have to wait for the 3rd party library to ship. Different binaries are effectively that. So, yea, I could also feature flag everything, flip the flag when the conditions are right, but sometimes its easier /simpler to just wait to merge.
- sroussey 5y ago
  This is still true, but to a matter of degree. Even in the feature flagged deploys mixed with canary the permutations are all evident, and ideally tested. Also, you wouldn’t expect a schema change to occur with code that requires it. Those will need to happen earlier. Real systems are complex. A monorepo is one attempt at capping the complexity to known permutations. For smaller teams, it might collapse to a single one.

I don't think it's a problem, rather I'm challenging a touted benefit. In large monorepos the supposition is you've got a class of compatible apps and services bundled together. Version dependencies are somewhat implicit: the correct version for each project to interoperate is whatever was checked-in together in your commit. I don't know how it works in practice at different orgs, but there's certainly an idea I've heard repeated that you can essentially test, build, and deploy your monorepo atomically, but the reality in my experience is you can't escape the need to think about compatibility across multiple versions of services once you use techniques like canary testing or targeted upgrades.

staticassertion 5y ago
You still have to think about compatibility across versions - that does not go away in a monorepo, and you should use protocols that enforce compatible changes. The monorepo just tells you that all tests pass across your entire codebase given a change you made to some other part.
- eximius 5y ago
  thats fair. you require reasonable deployment intervals and may need to wait to merge based on deployment. Workflow actions that can check whether a commit is deployed in a given environment are invaluable
  - jeffbee 5y ago
    > may need to wait to merge based on deployment Again, this fundamentally misunderstands the purpose of the source code repo and how it relates to the build artifacts deployed in production. If you are waiting for something to happen in production before landing some change, that tells me right there you have committed some kind of serious error.
    - joshuamorton 5y ago
      I'd caveat this with code change. Its very common to need to wait for some version of a binary to be live before updating some associated configuration to enable a feature in that binary (since the dynamic configuration isn't usually versioned with the binary). It's possible that some systems exist that fail quiet, with a non-existent configuration option being silently ignored, but the ones I know of don't do that.
    - eximius 5y ago
      I'm not sure I agree? If I'm waiting on an update in a 3rd party library... you have to wait for the 3rd party library to ship. Different binaries are effectively that. So, yea, I could also feature flag everything, flip the flag when the conditions are right, but sometimes its easier /simpler to just wait to merge.
sroussey 5y ago
This is still true, but to a matter of degree. Even in the feature flagged deploys mixed with canary the permutations are all evident, and ideally tested. Also, you wouldn’t expect a schema change to occur with code that requires it. Those will need to happen earlier. Real systems are complex. A monorepo is one attempt at capping the complexity to known permutations. For smaller teams, it might collapse to a single one.