We can always set all the versions to the "latest" and let it break when it does, but at scale that's not affordable.
Every module must be versioned and upgraded with care; Separate epic, Separate PR, code review and proper testing on different environment. This is basically why keeping the lights on is costy and some companies just rather to cope with old versions.
Then in an environment with lots of microservices, it's inevitable to avoid shared codes; So companies tend to hire lots of engineers just to take ownership of some services to keep the lights on.
I'd like to see the shell script that updates my deprecated node pipelines from 16 to 20, and updates deprecated fields after reading the changelogs of the vendor!
> I built this because I was tired of creating pull requests in 20 repositories just to change a single line of workflow job version.
sounds like an X Y problem
At work I learned "Slow is fast, Fast is slow".
We can always set all the versions to the "latest" and let it break when it does, but at scale that's not affordable.
Every module must be versioned and upgraded with care; Separate epic, Separate PR, code review and proper testing on different environment. This is basically why keeping the lights on is costy and some companies just rather to cope with old versions.
Then in an environment with lots of microservices, it's inevitable to avoid shared codes; So companies tend to hire lots of engineers just to take ownership of some services to keep the lights on.
> sounds like an X Y problem
Sounds like someone forgot how to write shell one-liners, as well...
I'd like to see the shell script that updates my deprecated node pipelines from 16 to 20, and updates deprecated fields after reading the changelogs of the vendor!
Based on the title, I was hoping this would be a new subclass of tower defence. Vibe coded, naturlich.
Outage as a service? Neat ;)
Thanks for the laugh lol