5 ms·

So, I picked up a pretty easy process I've used for the last 10 years (at decade old small company with plenty of legacy code, Microsoft, & now a startup using

• pavel_lishin 3y ago
  Across how many repos? My team owns a dozen.
  • vlovich123 3y ago
    Sounds like you might be understaffed.
    • pavel_lishin 3y ago
      It's microservice land! Most of those services are no longer in active development, and nearly all of them support a single actual product. In my opinion, we split them to aggressively at the start - expecting some of them to be used by other people in the company, as a service type of situation - but that never happened. I argued for combining several of them - they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. But it was never particularly urgent.
      • vlovich123 3y ago
        Yup. Those “no longer actively developed” services should probably be rethought. Your carrying too much dead weight for the team size if updating the dependencies is “too much”. You’re just papering over the issue if you’re relying on automated tools to do basic book keeping for you.
      • zer00eyz 3y ago
        >> they don't share any paths for API calls, so it could literally be as simple as recursively copying various folders, and adding more route definitions to whichever service becomes the host. Make that step 4 or 5. Mono repo them first! Yes you will have to build some tooling to do this but it gives you a way to test the concept. The moment that you have to change 2 of them with any degree of coordination you will get a 10x pay back.
      • devjab 3y ago
        Why wouldn’t you just bundle your shared dependencies in libraries so you would only have to update them in one location anyway? We put all our shared utilities into service libraries which are injected into our microservices when they are build. Since the APIs they consume are build to be non-breaking on changes, any external packages that get updated will only need to have their breaking changes solved in one location. 95% of our changes are done by renovate. We rarely have to deal with breaking changes on anything backend related, though the frontend is a different story. But our frontends aren’t exactly “microservices” anyway, and they are always very much in active development. I build a couple of services which collects a gazillion tonnes of solar inverter data from various plants over the world, and then does some fancy ML magic to figure out which solar cells need cleaning, and it has run for years with automated dependency updates with nothing breaking because of how it was build from the start. I get that if your microservices are really just a bunch of tiny monoliths then it’s hell, but then you should probably prioritise your suggestion of merging it together somehow.
  • __s 3y ago
    Monorepos definitely make it easier. There's a use for dependency bots, especially when collected into one PR so that it can be treated like a newsletter. Was wanting to point out that good habits can go far, but if you're hitting limits then automation is a boon Ideally if there's multiple repos maintenance can be divided amongst those repo's owners, & once you've divided work between multiple people it becomes more valuable to have a tool help maintain process. These tools need buy in, I've found sometimes they'll go ignored & then the list of PRs becomes mixed up with random dependency PRs
    • occz 3y ago
      Renovate creates an issue which lists the status of all dependencies in the repository, which it keeps updated. It then creates PRs for each dependency update, which can then have CI run individually to give an indication of any issues with the update. It's downright excellent.
• oweiler 3y ago
  With Dependabot this takes me less than 10 min a week across 20 repos. Because we have lots of integration tests, we automerge patch updates automatically.