[taneq]

> we've had entire days where the team was unable to deploy because the CI workers did not run (even though we host the workers)

I find it boggling that a commercial team chooses to accept this kind of external dependency. What do they offer which makes it worth the extra risk?

[mikekchar]

It reduces the complexity of your ops environment. Not the OP, but we do the same thing (though not with GL). When you only have a couple of developers, it makes sense to keep everything in house because your cost is essentially a couple of hours keeping things up and running as well as having an extra development machine somewhere. When you are a large organisation it also makes sense because you have a whole bunch of ops people keeping things running. Somewhere in between there is an awkward point where you've got enough complexity that you'll need to hire an ops person to handle it, but you don't have the organisational infrastructure to deal with that hire. Outsourcing is actually less risky because you're essentially piggy backing on somebody else's large organisation. A single bad hire isn't going to sink you, for example.

[raziel2p]

What's the alternative? Writing your own CI/CD system from scratch? You're going to be relying on some external dependency for important things anyway, you just have to pick one that is dependable.

[taneq]

I'd think a happy medium would be using an open source CI system and testing new versions on a test server before deploying them to prod.

Then again, I come from a largely non-web background where external dependencies aren't just accepted as inescapable. I guess if your entire business is producing an add-on for some other company's web service (not saying yours is but many out there seem to be) then what's one more on the pile?

[Heliosmaster]

that's exactly what their CI is. An open source CI system that you can deploy on your own server (and plug to either gitlab.com or your self-hosted instance of Gitlab).