Continuous Deployment - more than a toolchain

A while ago, a prospective client approached me, "We've purchased a Continuous Deployment Toolchain, now we need someone to do the training." I was invited to meet the Head of Administration and an Admin team lead. 

Story Time.

Paying for vaporware

"Here is the toolchain we bought. We paid a six-figure amount for the strategy and a five-digit sum for the implementation. Now we need someone to train our Admins so that we can roll out the new process for all of our 500+ projects in the next Quarter."

I glanced at the Powerpoint slide.

If you think this is worth $100k, well ... I have a bridge to sell.

It's about culture!

I started asking: "Why the Admins? Wouldn't you much rather want to train the developers?"
I learned that this project was spearheaded by the Head of Administration and they didn't want the Head of Development to take credit for their idea. Plus, the introduction of Continuous Deployment (CD) was mainly supposed to relieve the efforts of the Admins.
Taking note, I asked: "So how did you come about this project in the first place?" In painstaking detail, the Admin team lead explained that the process of getting a release through the door often took months - and CD, automating the entire ordeal, would cut it down to minutes and free their time for much more important things.
Nodding, I probed: "So, the developers will check the code into git?" - "At the moment, they either send us the code via email or put it onto a Shared Folder." Remember - this was a good decade into the 21st century! "And then?" - "We manually compile the sources. In some cases, we've created some scripts to ease the job, but those scripts are brittle and fail with every new release." - "Have you considered giving the job of creating maven builds to the developers?" - "That's not their responsibility. We can't guarantee for the correct installation of the software any more if we let them do it."

Next icon. "What's Sonar supposed to do in this construct?" - "Check the code quality." - "Do you have code conventions or unit tests?" - "Neither." - "And who is going to do that job?" - "That would be the Offshore Testing Department."

This was getting more intriguing by the minute. "Are the Developers trained in the use of Ansible and Docker?" Shaking heads, "We will provide standard scripts and containers for others to use." Probing deeper, "How do you know which Ansible Configurations and Docker Images will be needed?" - "We will just create those which replicate our current environments." - "Are your Admins trained with either tool?". A smile, they figured that finally, I was coming to understand them: "That's why we need you."

"Just one last question, how are the tests going to execute?" - "If you look closely, after a Docker Container is created, it will automatically be deployed to the Test Stage for Manual Testing."


This was going to be an interesting ordeal.

Get ready for Continuous Deployment!

I devised a strategy and proposed the following approach:

1. Basic Leadership training for beginning agile transformations
2. Process Redesign Workshop to reconsider the current build process and responsibilities
3. Start a Cross-Functional Team from across all departments to integrate the CD pipeline on one project in the next quarter.
4. Coach this team in fundamental Software Craftsmanship - including Pairing, Test Automation and CI.
5. Use the pilot team to set up meaningful quality metrics and create a working build pipeline.
6. Involve others in the learning and gradually move towards cross-functional teams with e2e responsibility.

I was informed that my offer was probably a misunderstanding. I replied, politely, "If you ever choose to look deeper into this offer, feel free to reach out." They never did.

tl;dr:
The toolchain is irrelevant until you have the culture and structure in place. CD isn't something that a single department in a silo organization can do all by themselves. Instead of architecting the entire pipeline upfront, experiment, discover what works - what helps - and what is actually being used!

If you seriously intend to move towards CD, the long journey and steep learning curve really pay off once the peak is climbed.
One disclaimer, though: There's no guarantee that you can keep any of your current processes, structures and mindset.