“Continuous Delivery (CD) is a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time”
Perhaps a simpler definition is “CD is the currently the cool thing to do”
Sarcasm aside, there’s a lot of common sense in being able to rapidly push out software changes in a safe manner.
Many years ago, I was a developer at a company that was drowning in bureaucracy, and I was tasked with trying to solve a suite of performance problems with part of the core business application. The first thing I did (and I’d recommend this to anyone trying to assist in solving performance problems) was to visit the end-users who actually use the software. (It’s too easy to jump in and start tracing SQL statements etc…but the pain points you are trying to solve are the customer’s pain points, not the servers)
She sat down and ran me through the litany of performance problems she was having. I tried to set some realistic expectations for her about when we could solve them, but I also asked:
“If there is one thing that is absolutely top of the list, what would it be, and I’ll focus on that”
Interestingly, when phrased that way, she pondered for a moment and told me it was not a performance issue. Although the performance was terrible, she (embarrassingly for our IT dept) had re-structured her daily activities to accommodate the slow parts of the system. (“I run the daily report whilst I’m at morning tea, and its usually done by time I get back”). No, she had a much simpler request:
“We have smaller screens in the field office, so you have to scroll the screen every time to get to the ‘Submit’ button. Can you move it to the top of screen?”
“Leave it with me!” I exclaimed. “This is simple, and we’ll get it to you asap”
So I was feeling pretty good about myself – I’d identified the important performance issues, bought myself some time to work on them, and had a simple fix to appease the customer in the interim. I got back to the office, checked out the source code, move the button a few inches higher and voila! I’m done.
….Or so I thought.
I wont share the gory details, but it took over 6 months to get that change through all of the processes, environments, approvals, release cycles, etc and finally deliver it into Production. I was so ashamed that I’d let this customer down so badly. And it strips away at your job satisfaction as a developer – nothing makes you feel more foolish than sitting in front of a “Change Approval Committee” meeting, and you’re justifying the business benefit of a change you coded 6 months ago, where a button was moved. A total waste of everyone’s time. But … after all that red tape, it had finally gone in.
My manager called me into the office after deployment:
“Well, your change is in! You should phone the customer, tell her we’ve done her changes, and make sure she’s happy with it”
Can you imagine it ? “Hi, remember me, its been six months…that button is 2 inches higher. Are you impressed ?”
Anyway…enough back story, this sets the scene for my next blog post…An simple example of CD in the database.