3 ms·

The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automati

The problem isn't the libraries. The problem is you don't have CI (with a dashboard your team is paying attention to). Check-in -> automatic build -> automatic unit test execution -> signals if the build is ready

Ididntdothis 7y ago
Until your CI pipeline causes churn because something doesn’t work anymore....
- umvi 7y ago
  We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).
  - pritianka 7y ago
    What an awesome compliment for our team. Thank you!
- 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 ago
    Some 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.
tonyedgecombe 7y ago
The problem is you don't have CI Having CI won't stop the developer of the dependency changing the interface.
- mffnbs 7y ago
  Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?

Ididntdothis 7y ago

Until your CI pipeline causes churn because something doesn’t work anymore....

umvi 7y ago
We use GitLab CI, and it's been working maintenance free for 3 years now. We configured the test runners in 2016, and haven't touched them since and they have never randomly broken - even across GitLab updates (of course, YMMV depending on if you like to be on the bleeding edge all the time; we are always 1 cycle behind the bleeding edge).
- pritianka 7y ago
  What an awesome compliment for our team. Thank you!
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 ago
  Some 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.

tonyedgecombe 7y ago

The problem is you don't have CI Having CI won't stop the developer of the dependency changing the interface.

mffnbs 7y ago
Why are developers mindlessly upgrading major versions of dependencies and expecting everything to be okay?