You can tell a lot about how much someone has embraced continuous delivery by how they react when either a build or an automated deployment fails.

I have worked with quite a few teams who are at different levels of working with continuous delivery, but irrespective of whether they familiar with the practice or not, you can tell how adaptive a team member is when something goes wrong, like a failed build or deployment.

And so here is my categorisation of how people react when something goes wrong -

Avoiders

These people are not your friend! These types only see their role as their sole responsibility; developing or testing. Anything outside of that is out of their scope. In fact they’re the type of person who use the phrase “dev complete” or “test complete” and move on to the next task on their board.

Delegators

They are aware that there is a problem , but instead of getting familiar with the deployment process and digging into where the problem is, which should be routine, they toddle off to find someone who can help them. Some delegators may be unfamiliar with a process and wish to have it explained to them, less they make a change that breaks something. And that’s fine. That’s how delegators evolve to the next category. But the worst type of delegators are those whose philosophy that “ignorance is bliss” - they don’t care what the problem is, they just want someone to find out what it is and fix it for them, and be on hand the next time it fails. These are the types who won’t work with you, but expect you to work for them. There’s a key difference.

Investigators

Investigators are the types who see failed process, open up the errors, figure out where the problem is, or work with people to figure out where the problem is if it is not apparent, and try to resolve.

How To Help Avoiders and Delegators Become Investigators

Fire them, and replace them with better people.

In the real world, this is probably not a very likely outcome. If people don’t want to change, there’s not a lot you can do about it. But it doesn’t mean you shouldn’t try.

Shaming people when they break something is a very negative way to motivate team members into fixing problems. It works, but produces a toxic and unhappy workplace - I used to work for a team where the motto was “cakes for mistakes” - if you broke a build, or a deployment failed, you have to buy the entire team cakes. It was introduced by an individual who had picked it up form another company. After we found this out, we probably should’ve thought more about why he was so fat when he joined us…

It’s important to focus on not who broke the process, but what is broken and how it can be rectified. The whole point of having builds and deployments prior to going live is because it’s a form of software testing, and what a failed build/deployment is is catching a bug earlier in the process, where it’s quicker, cheaper and less disruptive to fix.

How I Learned To Stop Worrying And Love The Build Log

If I was to categorise myself, I’d say I was an Investigator. And I’ve worked with plenty of people who are in the other, less helpful categories. And also there was a time where I was definitely a delegator, who wanted to learn. And the way in which I learned was being thrown in at the deep end - I once worked for a company that laid off 2/3rds of the staff, and because I had mentioned that I was interested in learning TFS, I was suddenly TFS Administrator. And that meant working with the builds. Back in the day, the builds where .proj files with over 1,000+ lines of MSBuild, and plenty of imported target files. And because the build produced deploy artefacts, I was responsible for the deployments. With the team in need I dived head first, and made a lot of mistakes, but I learned quickly. Admittedly this method only worked because I really wanted to get away from testing.

Part of the challenge usually is that build/deploy processes create a huge amount of logging, some of which is spat out by the build/deploy tool itself (Team City/Octopus), and then also the tool in question (ie Visual Studio for builds, DacFX for deploying databases etc). This can generate a lot of noise and make it hard to find the pertinent fact. But it’s a skill that is learned over time, and to familiarise yourself to looking at logs until it becomes as routine as your deployment process is crucial.

The DevOps Bloke In The Corner

Some teams also make the mistake that Continuous Delivery means “DevOps” and that DevOps is a role with tools, as opposed to a method of working. This is wrong on both fronts. Tools help facilitate Continuous Delivery, and DevOps is a process in removing people out of their professional silos and getting people working collaboratively on delivering a good product. If you’re not careful, DevOps becomes “some bloke in the corner”. And that version of DevOps quickly becomes the new DBA - a person to throw stuff over the wall to to disentangle the mess that teams deliver tasks as “done” before it’s even seen an automated deployment.

There’s no shame in not having a profound understanding of every deployment process that runs in any one organisation. But there certainly is in seeing a broken deployment process and not doing anything positive about it.