Comment by cestith

I hear you about rigging those repos together artificially.

I used to work somewhere that had several different systems written as monoliths that eventually needed to interact more closely with each other. There was an in-house ticket system (since made a support service wrapped around ZenDesk, but ZD wouldn’t replicate all its functionality). There was an in-house employee management system. There was a first-party CRM. There was a homegrown e-commerce store. They’d built their own licensing servers for their software. Eventually the CRM was managing large customer licenses, the ticket system linked to the store to sell priority support, and the store was selling licenses to smaller customers.

So instead of making these things all support APIs that supported the other applications, people started copying libraries around from service to service. Then to make sure those libraries didn’t fall out of date, the (at the time rsync) deployment process for each of those apps was changed to require a pull from every one of those repos, then a push from that staging server to the production servers. Then security did a PCI-DSS internal audit, and the developers couldn’t just get onto a staging server and make direct changes to production.

So I, as the lead SRE at the time, wrote a builder web app that takes a config file per project. It holds the data on the repos and the default tag to pull from each. The web app allows the developer to update to a different commit or tag for any particular repo involved. Then a single button pulls everything and serially takes production servers out of rotation, updates them, and puts them back into production. It’s something that could have been avoided many different ways including using a monorepo for those systems.