The Psychology of Continuous Integration

Operations people, we love to automate. In the case of continuous integration we want to be able to deploy to production, every day, multiple times a day. Our commits trigger building, testing and deploying through a pipeline untouched by human hands. Or, so the theory goes…

More commonly, we have part automation, where we manually intervene is heavily dependent on the impact of any errors.

Automatically to dev… yes!

Automatically to staging ermmm…

Automatically to production… eeek!!

I want to automate more, I want continuous delivery, I don’t want manual steps for anything!

In order to try and move towards this dream I thought I’d do something crazy, actually ask the project teams about their continuous integration pipeline. Listening to what they really say, do, and want, made me think differently… a bit.

No surprise here, every project was on a fairly close variation of,

Automated: Pull Request -> Build -> Run Tests -> Deploy to Dev

Manual: Manual testing -> Deploy to Staging -> Manual Testing -> Deploy to Production

The density of automated testing and the amount of manual verification before deploying to staging or production varied but the process was the same.

First surprise was, everyone was happy, that’s rare! The common feeling was, why would I automate any more than this.

Testing was always considered to be strong and complete, when something was missed in testing it was rapidly added to the tests cases. Even still, no-one wanted to let go of their manual verification, even when it covered exactly the same things as their automated tests, only human beings were believed to be trustworthy.

With continuous integration we get rid of all the roadblocks, we can deploy multiple times a day, features don’t arrive in large release blocks, they are constantly dropping into production and enriching our applications with new things and new fixes. That’s a good thing right?

Actually, as a team and an individual, we want the big red button, the moment when all that hard work arrives in production as a shiny new feature. We gather together the team and we celebrate. Continuous approaches remove all this.

The development process is a black box to those not directly involved. Sometimes manual stages and verification is the only way for team members who aren’t coding the feature to get their hands dirty. You want to see what happened since that user research, since that prototype. Seeing it in production can make you feel like you aren’t part of the team.

We want heavily tested quality code, going through all our testing stages, until we don’t. Then we want to short-circuit all those guarantees because we are both,

(a) In a rush to deploy our important changes

(b) Totally sure that they can’t break anything, they’re just trivial, what could possibly go wrong!

We need to automate, there are more things and they move more quickly. But the beliefs raised above are real, there not something to dismiss lightly. The technical solution is automation, but applications are’t just technical, they’re the bringing together people and process. If the people are unhappy, or the process isn’t working, then development will fail.