3 min read

Unstable Builds - Good or the Source of All Evil?

TLDR; I’m going to try and discourage you from using build warnings / unstable status - those you see in CI platforms like Jenkins.

A few months ago, I started working on a project, and we choose CircleCI for the CI platform. As the work went along, our client asked us to set a “warning” status for the build in some use cases.

They wanted it for the duration of the transition to the new CI, but as we all know, once we add it, it’s here to stay.

After working with Jenkins for many years, I assumed it would be trivial, but it turns out that CircleCI doesn’t have this feature.

Huh, I thought. How can CircleCI be missing such an essential feature (And even if they did, and I’m sure one of you will correct me)? It got me thinking.

I started to think back at all the times I’ve seen these yellow “unstable” builds in Jenkins.

You see, what usually happens, is that unstable builds are just a form of failed builds but with less perceived urgency. People tend to ignore unstable builds and pile more issues onto them until someone wakes up and sees that everything is broken.

By the time that happens, it’s like we went back in time to the days before DevOps. Everyone discovers that nothing works when it’s time to release, and the deadline wooshes by.

I think that part of it is that once you get used to seeing something in a warning mode, especially if it’s colored a certain way, your mind just tags it as noise and moves on.

Developers stop testing their work, assuming that their changes are ok and that it’s the usual build nonsense.

And that is creating bad habits.

Back to the client project, the reason they wanted the warning mode was to allow them to pass pull requests but still “know” that a few things were failing and need to be addressed at one point. It may sound reasonable at first but then think about all those TODOs you still have in your code.

The task should either fail the build and require immediate action or become a task in one of the sprints (or whatever you are using). Anything other than that is just noise and will get the opposite results.

This also ties into something else I’ve been thinking about - The power of visual dashboards and routine.

When you get used to seeing a certain pattern regularly, outliers tend to just pop up and grab your attention.

And that’s what the brain does, right? It learns to react to things that break the pattern. That’s how we can drive and without dying on every ride.

So when you look at the CI dashboard every day and see that everything is super green, you just ignore it. Red means wait. Something is not right. When you have a “Yellow” warning that goes on for days, your mind just blocks after a while, and you will not be motivated to handle it.

Want to learn more about DevOps?

An email that dives deep into subjects that are all DevOps

    We won't send you spam. Unsubscribe at any time.
    Powered By ConvertKit