4 ms·

I've found companies typically use monolithic development because they don't get all of the benefits of modular development. e.g. they don't re-use code cause t

by JDDunn9 11y ago

I've found companies typically use monolithic development because they don't get all of the benefits of modular development. e.g. they don't re-use code cause they only have 1 website (and don't care about open sourcing). I'll stick with modular all the way. :)

Negitivefrags 11y ago
Most of the arguments in the article were in cases where you do reuse code though. If you didn't reuse code (across repos) then you wouldn't have any of the problems that a monolithic repo solves.
- hvidgaard 11y ago
  I just cannot imagine trying to make sense of the history of a giant monorepo. What I don't get is the example from Twitter. If I need a fellow developer to fix projectB and projectC for me to fix projectA, I ask him to fix it. As soon as he has committed it to their respective repos, the buildserver would pick it up, and I can expect the next time it builds projectA, it pulls the lastest version of projectB and C and use them.
  - pjc50 11y ago
    If you want to make a backwards-incompatible API change, it's very convenient if you can change both sides in the same commit.
    - viraptor 11y ago
      But if you do versioning properly, then you can change "both sides" in one commit by including the change of the dependency version.
      - Cthulhu_ 11y ago
        Exactly - an extra step in the development process, you need to do an official release of both libraries / projects - do your work (same as in a monolithic repo), bump version x2, update dependencies x2, make tag x2, and hope others haven't changed anything in between and made a release so you'd have to do it again. That goes against "move fast and break things", or at least the move fast bit.
        hvidgaard 11y ago
        Taking NuGet as an example - you make a change, bump the version number, commit and push it. The buildserver automatically push it to your internal NuGet server. Now your IDE will notify you that there is an update to a package you use and you can update and make your own bugfix, and commit it. The alternative with monorepo is - you make a change, bump the version number, commit and push it. You watch for the commit you need (in a monorepo this might be harder than it have to be, alternatively the developer can send you an IM) and hopefully there isn't any merge conflicts when it's done. You pull the commit, make your fix and commit it. It's largely a matter of poor tooling.
  - michaelmior 11y ago
    If you always pull the latest version of other projects, you have no way to have a consistent snapshot of a working system. If you use a monorepo, it means that you always know which versions of every file in every project are in use at a particular commit. This of course is also true if you use separate projects and pin their dependencies. But if you use separate projects and always grab the latest version of each subproject, there's no way to ensure you have compatible versions of different projects in use.
    - hvidgaard 11y ago
      At least in TeamCity, I can tell it what version of an artifact I want, it's even possible from within the VCS with some powershell magic. So a non breaking change like a bugfix, will update the buildnumber, but not the rest. If the fix includes breaking changes, I want to adapt my code anyway, and then update the reference to the newest version anyway. For our .net projects, I've set up an internal NuGet repo to handle internal dependencies. This honestly sounds more like the best workaround because the tooling isn't good.
    - theCodeStig 11y ago
      You don't need a monorepo to solve this problem. The dependent projects would depend on a specific version of an artifact, rather than a 'latest' pointer. Example: Project 1 depends on version 1.2.3 of Library A, and Library A builds are hosted in an artifact repo. Project 2 needs an update to Library A, and those updates are built and released as version 1.3.0. Project 1 continues to use version 1.2.3, until it's updated to work with the new 1.3.0 API.
      - michaelmior 11y ago
        Of course you don't need a monorepo to solve the dependency problem. My point was that just using the latest version of all projects in different repos is not necessarily an acceptable solution.
- lmm 11y ago
  If you're willing to "move fast and break things" then doing an API change in one go across all your projects is great. But in the kind of industry where downtime is unacceptable, if project A and project B both use library C, when you make a change to library C you want to be able to release and test project A and B separately, according to their own project lifecycles. So you need the ability to release and tag library C on its own, and it makes sense for it to be in a separate repository.

by JDDunn9 11y ago

Negitivefrags 11y ago

Most of the arguments in the article were in cases where you do reuse code though. If you didn't reuse code (across repos) then you wouldn't have any of the problems that a monolithic repo solves.

hvidgaard 11y ago
I just cannot imagine trying to make sense of the history of a giant monorepo. What I don't get is the example from Twitter. If I need a fellow developer to fix projectB and projectC for me to fix projectA, I ask him to fix it. As soon as he has committed it to their respective repos, the buildserver would pick it up, and I can expect the next time it builds projectA, it pulls the lastest version of projectB and C and use them.
- pjc50 11y ago
  If you want to make a backwards-incompatible API change, it's very convenient if you can change both sides in the same commit.
  - viraptor 11y ago
    But if you do versioning properly, then you can change "both sides" in one commit by including the change of the dependency version.
    - Cthulhu_ 11y ago
      Exactly - an extra step in the development process, you need to do an official release of both libraries / projects - do your work (same as in a monolithic repo), bump version x2, update dependencies x2, make tag x2, and hope others haven't changed anything in between and made a release so you'd have to do it again. That goes against "move fast and break things", or at least the move fast bit.
      - hvidgaard 11y ago
        Taking NuGet as an example - you make a change, bump the version number, commit and push it. The buildserver automatically push it to your internal NuGet server. Now your IDE will notify you that there is an update to a package you use and you can update and make your own bugfix, and commit it. The alternative with monorepo is - you make a change, bump the version number, commit and push it. You watch for the commit you need (in a monorepo this might be harder than it have to be, alternatively the developer can send you an IM) and hopefully there isn't any merge conflicts when it's done. You pull the commit, make your fix and commit it. It's largely a matter of poor tooling.
- michaelmior 11y ago
  If you always pull the latest version of other projects, you have no way to have a consistent snapshot of a working system. If you use a monorepo, it means that you always know which versions of every file in every project are in use at a particular commit. This of course is also true if you use separate projects and pin their dependencies. But if you use separate projects and always grab the latest version of each subproject, there's no way to ensure you have compatible versions of different projects in use.
  - hvidgaard 11y ago
    At least in TeamCity, I can tell it what version of an artifact I want, it's even possible from within the VCS with some powershell magic. So a non breaking change like a bugfix, will update the buildnumber, but not the rest. If the fix includes breaking changes, I want to adapt my code anyway, and then update the reference to the newest version anyway. For our .net projects, I've set up an internal NuGet repo to handle internal dependencies. This honestly sounds more like the best workaround because the tooling isn't good.
  - theCodeStig 11y ago
    You don't need a monorepo to solve this problem. The dependent projects would depend on a specific version of an artifact, rather than a 'latest' pointer. Example: Project 1 depends on version 1.2.3 of Library A, and Library A builds are hosted in an artifact repo. Project 2 needs an update to Library A, and those updates are built and released as version 1.3.0. Project 1 continues to use version 1.2.3, until it's updated to work with the new 1.3.0 API.
    - michaelmior 11y ago
      Of course you don't need a monorepo to solve the dependency problem. My point was that just using the latest version of all projects in different repos is not necessarily an acceptable solution.
lmm 11y ago
If you're willing to "move fast and break things" then doing an API change in one go across all your projects is great. But in the kind of industry where downtime is unacceptable, if project A and project B both use library C, when you make a change to library C you want to be able to release and test project A and B separately, according to their own project lifecycles. So you need the ability to release and tag library C on its own, and it makes sense for it to be in a separate repository.