Posted by “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”
(Source: https://en.wikipedia.org/wiki/Continuous_delivery)
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”
I refused.
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.
Learning is not a spectator sport 
Makes me think of a similar experience of mine. I was at this cable-internet company that implemented a CRM application after a horrible project. At day one that the application was in production the helpdesk sent us an incident: “The database is slow”. What to do? Well, after discussions back and forth for weeks, I decided I wanted to talk to the end-users. My collegue DBA’s thought I was mad. “Yeah, you do that”, was basically their response.
So I arranged a meeting with me, an end-user and a developer. The end-user was member of a call center. I asked him to share his issues. And he explained: “The interface is horrible. It makes it very hard to do my work quickly enough. THAT was the “performance issue”: the interface.
Communication is hard. Sometimes harder that performance tuning.
Great article. Really enjoyed it. I once visited a call centre where users constantly complained about ‘hangs’ and ‘screen lockups’ but the DBA team simply couldn’t find any evidence of locking or the TX enqueue row lock contention wait event. Performance was fine. After all, Quest Spotlight said so. All green and flowing nicely there. As I was only onsite for the day, I talked to an exasperated supervisor, gave him my mobile and told him to ring me every time one of his team got a ‘hang’.
3 hours later, I had visited 27 call centre agents on 5 different floors and deduced it was a problem with IE.
This site is just awesome. I’ve ask these details a
long time and I realised that is professional, easy to understand.
I congratulate you for this article that I’ll tell to the people friends.
I ask you to go to the gpa-calculator.co site where each learner or
learner can calculate results grade point average rating.
Be great!