In my mind a simple unit test should have caught this. Mock out the call to the service that sends the message and verify that it’s been called with the correct message, and cover the possible failure scenarios. That said I hate loosely typed languages lol.

This isn’t the languages fault, it’s the developers.

Well yeah strictly you don’t, but the idea of having a single machine under someone’s desk as a build server managed by one person where you have multiple dev teams fills me with horror! If that one person is off and the build server is down you’re potentially dead in the water for a long time. Fine for small businesses that only have a handful of devs but problematic where you’ve multiple teams.

Bottom line for most business though: As long as the cost makes sense, why bother self-hosting anything. That’s really what it comes down to. A bonus too, as most companies like being able to blame other companies for their problems. Microsoft knows that, and profited greatly with Windows Server/Office/etc. for that very reason.

Yup, exactly this. Why waste resources internally when you can free up your own resources to do more productive work. There’s also going to be some kind of SLA on an enterprise plan where you can get compensation if there’s a service outage that lasts a long time. Can’t really do that if it’s self managed.

I’m talking about in a professional environment. You basically need a team to manage them and have a backlog of updates and fixes and requests from multiple dev teams. If you offload that to something cloud based that pretty much evaporates, apart from providing some shared workflows. And it’s just generally a better experience as a dev team, at least in my experience it has been.

It’s not like internal build servers are 100% reliable, scaleable and cheap though. Personally I’ve found cloud based build tools to be just a better experience as a dev.

“Ok, so what you can see in the logs?”

“Sweetcorn.”