[Reading time: 1 minutes 34 seconds]
Yesterday, we talked about the first step of introducing DevOps. But we’re just getting started on this journey.
You’ve got your pipeline set up, code is racing through it. Yay?
Not quite. “But Luca”, I hear you say, “how does this help us?” Good point, it’s quite nice already, but somehow it doesn’t feel like you’re where you’d like to be, right?
Like… you can pretty much already smell all the feedback just waiting for you.
Congratulations, you’ve come across what Gene Kim calls the Second Way: Feedback Loops.
Luckily you’ve got the forward direction already set up by following the first way: you’ve got an automated, robust delivery pipeline cranking away.
Even without anything else, that pipeline gives you feedback: does the product even build?
But now is the right time to set up a CI system, automate the building of your product based on triggers, and have a conveyor belt on which to place all the other feedback tasks you want to introduce.
Once you’ve set it up, you’re in an excellent position to hang other functions into your pipeline. Tests at various levels, linting, you name it.
And of course make the information flow backwards, against the stream of your pipeline, so that any defects or new observations can immediately be consumed by the people upstream.
This also means creating enough visibility, clarity, and just plain channels for this information to reach the appropriate humans’ brains. Whatever works: feedback in the IDE, emails, dashboards, CI-controlled traffic lights in the corner. Whatever helps.
This is the second step I’d take in moving towards DevOps: now you have information flowing both downstream and back upstream – an excellent basis for building good, powerful, robust products.