Applying the Four Principles of Continuous Delivery to Avoid Late‑Night Releases

The article introduces the "four 持 principles" described in the book Continuous Delivery 2.0 , which are: (1) "持" – do less, (2) continuous decomposition, (3) persistent feedback, and (4) continuous improvement. By embedding these principles into everyday work, teams can avoid being trapped by "trivial matters" and reduce the need for late‑night deployments.

It illustrates a typical scenario in a software development team where release schedules are announced repeatedly during morning meetings, leading to frequent requests to shift release times earlier in the day to avoid working late. The narrative shows how asking the right questions and applying the four principles can break this cycle.

The piece emphasizes that asking questions is a key learning method; without questioning, improvement cannot happen. It stresses that continuous improvement is only the first step, and that micro‑feedback loops are essential for maximizing developer efficiency.

Real‑world project data is referenced, linking to two previous articles that detail risks discovered through cumulative flow diagrams and challenges faced by new teams adopting continuous delivery practices.

Despite following the "continuous decomposition" principle—splitting requirements into small, two‑week iterations—the project struggled with the "persistent feedback" principle. Issues cited include lack of dedicated development test environments, insufficient automated functional and unit testing, and shared test environments causing inter‑team dependencies.

The article lists several root causes for delayed releases, such as developers using the test environment for debugging, limited automated testing, and shared resources. It argues that feedback should occur at every action (micro‑feedback) rather than only at hand‑off points.

Finally, the article references a Forrester report on DevOps, noting that organizations often overestimate their progress, especially senior leaders. Accurate measurement of DevOps capabilities is necessary to inform leadership decisions and drive genuine technical improvement.