𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 (𝑻𝒓𝒖𝒆 𝑵𝒐𝒓𝒕𝒉): 𝐘𝐨𝐮𝐫 𝐰𝐚𝐲 𝐭𝐨 𝐚 𝐡𝐚𝐩𝐩𝐲 𝐝𝐞𝐥𝐢𝐯𝐞𝐫𝐲

Think of your self as a hiker in a desert and you want to head to north, no matter where you are now you can stop anytime and look on your compass (𝐘𝐨𝐮𝐫 𝐓𝐫𝐮𝐞 𝐍𝐨𝐫𝐭𝐡) and correct your course, The same strategy could serve in software engineering.

Devops, Agile, Lean, Kanban, Scrum... all great things, all exciting buzz words, each the subject of many conferences, blogs and courses. But, not a single one of those amazing concepts or methodologies will make a real difference until we allow them to change how we think about the value we deliver to our customers

Continuous Delivery doesn't replace anything, but rather it enhances everything.

𝐖𝐡𝐚𝐭 𝐢𝐬 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 ⁉ 🤔

In simple and short words it's an engineering practice in which teams produce and release value in short cycles, It's more about your approach to work rather than the work itself.

Even you are working in agile environment, doing all the job right, moving forward in your functions making progress every day some times your client may be unhappy !? But Why !? 😕

Client may be unhappy even they knew there is ongoing progress, but they couldn't feel forward motion, they haven't seen new value in a while.

Continuous Delivery pushes you to deliver valuable working software more frequently in a simple way to the client as a working features one by one in period of small days may be one or two days to make the client able to test and feel some value achieved and keep him happy in the development cycle.

8 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬 𝐨𝐟 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐟𝐫𝐨𝐦 𝐂𝐨𝐧𝐭𝐢𝐧𝐮𝐨𝐮𝐬 𝐃𝐞𝐥𝐢𝐯𝐞𝐫𝐲 𝐁𝐨𝐨𝐤 𝐛𝐲 𝐃𝐚𝐯𝐢𝐝 𝐅𝐚𝐫𝐥𝐞𝐲 𝐚𝐧𝐝 𝐉𝐞𝐳 𝐇𝐮𝐦𝐛𝐥𝐞

1. 𝐑𝐞𝐩𝐞𝐚𝐭𝐚𝐛𝐥𝐞 𝐑𝐞𝐥𝐢𝐚𝐛𝐥𝐞 𝐏𝐫𝐨𝐜𝐞𝐬𝐬: Use the same release process in all environments. If a feature or enhancement has to work through one process on its way into the integration environment, and another process into QA, issues find a way of popping up.

2. 𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐞 𝐄𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠: Automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results.

3. 𝐕𝐞𝐫𝐬𝐢𝐨𝐧 𝐂𝐨𝐧𝐭𝐫𝐨𝐥 𝐄𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠

Code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon.

4. 𝐁𝐫𝐢𝐧𝐠 𝐭𝐡𝐞 𝐏𝐚𝐢𝐧 𝐅𝐨𝐫𝐰𝐚𝐫𝐝

If something is painful or difficult, do that thing more often so that we force ourselves to improve it.

5. Build-in Quality 

Built-In Quality practices and metrics ensure that each Solution element at every increment meets appropriate quality standards throughout development.

6. “Done” Means Released

done means released, nothing more to do to get it into production.

This principle drives development teams to share the responsibility to complete features all the way to production instead of washing their hands of a feature when it passes their stage.

7. Everyone is Responsible 

Everyone shares the responsibility to keep the product moving to release.

No silos or one man deployment shows, no more tossing a feature over the wall to QA when we know full well it's not good enough for real users.

Certainly no more staying silent during backlog refinement meetings when we know we haven't fully comprehended what the client wants.

Everything we do needs to contribute to the goal of releasing and everyone is responsible.

8. Continuous Improvement

Consider everything in an experiment with the potential to make the whole process better.

Focus on a true north or common goal, That way, you can call every step a positive improvement, just a tiny step in the direction of perfection.

Be intentional with small daily improvements.