3 ms·
Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This sign
by danesparza 7y ago
Your CI pipeline should be simple, relatively unchanging and therefore trusted. When shit breaks (and it will) you should get a signal much earlier. This signal should strongly relate to your most recent changes -- and your changes should be small because you commit early and often, right?
- xemdetia 7y agoSome of us deal with the fact that the people maintaining the CI solution keep breaking our pipelines without any code changes in of our scope of responsibility. This becomes the churn as you push empty commits trying to troubleshoot why your builds don't work and it takes >1 day to get things working again. Most hosted CI solutions are entirely inappropriate for some organization's business goals and requirements, so you end up dealing with it being a B or C tier service in an organization that is changing. I would suggest that there are definitely some organizations where you can't trust the pipeline to work reliably, and the cost of figuring out what went wrong becomes the churn.