![]()
Preface 1
I first met Qiao Liang in Beijing in 2007 when we worked together on go.cd, the first CI/CD tool to support deployment pipelines. What we learned from building that product was crucial to the development of the material in the Continuous Delivery book.
Over the last ten years, these ideas have gone from being bleeding edge to accepted wisdom. Every serious tech company aspires to the idea of being able to release at any time, on demand, without workers having to spend evenings or weekends doing deployments. Being able to release software quickly, frequently, and safely in turn enables delivering in small batches, which means we can get fast feedback on our ideas. We can build prototypes and test them with real users, and avoid building features that deliver no value to users. This, in turn, means better products, happier customers, and happier employees. These capabilities are important for every organization that uses technology.
But it's hard to get there. Organizations need to evolve an architecture that supports fast, effective testing and rapid deployment, and deploy a culture of experimentation. The cultural element is essential both for successful implementation, and to put in place the product management practices enabled by Continuous Delivery.
Qiao Liang has worked with all kinds of organizations in China to help them implement Continuous Delivery and realize its benefits. I canāt think of anybody better to write a book on how to implement these ideas based on real-life experiences. I wish you every success as you experiment with getting better at software delivery, and using that capability to build better products and services and happier, more productive teams.
Jez Humble
Author of Continuous Delivery, co-founder and CTO of DORA
![]()
Preface 2
We are in the second half of the mobile Internet era. This means that, for the mainstream population, the basic needs of the head may have been met or āsaturatedā, and the future direction may be the subversion of the existing model, or the full satisfaction of the long-tail personalized needs, or better serving the needs of China's ethnically diverse communities. In any case, I believe there is a good chance that the cost of innovation and the likelihood of failed innovation will continue to rise in the future.
In this context, it becomes particularly important to find new opportunities quickly and reduce innovation costs through extreme product development and operation efficiency. Mr. Qiao Liang is a master in the field of software engineering. As an agile consultant of Tencent, he has worked with us for years and experienced the whole process of the development of mobile Internet. Mr. Qiao has a thorough understanding of various problems in the product development and operation system, and he is tireless in the pursuit of efficiency.
āIn this rapidly changing Internet environment, how can software development teams balance quality with speed? How to deliver software to users as quickly as possible so as to get their fastest feedback?ā Mr. Qiao and I had an in-depth discussion on these issues many years ago. āThere is no balance between quality and speed. Only product quality is ensured to certain extent, the pursuit of delivery speed is meaningfulā, said Mr. Qiao sharply. Unlike most consultants who like to say āIt dependsā, Mr. Qiao pointed out an immutable law throughout the product life cycle. Although different product stages have different requirements for product quality, such requirements are almost constant at the same stage. āHow to deliver product value quickly while meeting quality requirements?ā The contents of this book are mainly unfolded to answer this question.
In order to quickly identify new opportunities, the product iteration must be accelerated, but it may increase the fixed costs in each iteration, such as the cost for product quality test and for product release. This transactional cost greatly hinders the iteration rate of product. In this book, Mr. Qiao breaks downs the steps for operating the Value Discovery Loop and Fast Verification Loop in Continuous Delivery. On the one hand, it brings you new dimensions and perspectives to probe into business problems; and on the other hand, it enlightens you to pay attention to the details in daily work to seek for optimization, which helps to reduce the fixed costs in iteration and innovate products more efficiently. At the same time, you will learn how to enhance the overall combat capability of your team.
This book Continuous Delivery 2.0 exhibits the theoretical framework summed up by Mr. Qiao from a large number of practical projects; it is theoretical achievement based on solid realistic foundation. Instead of piling up empty theories, this book introduces plenty of positive and negative examples to support the principles and methodologies in software industry. This book is a pragmatic guide, just like its author who is a low-profile and down-to-earth person. It is especially recommended to the readers, either researchers in software industry or practitioners dedicated to R&D of operation system with efficient software applications. As I believe, in Internet industry, efficiency is the key to success in the future.
Zeng Yu
Vice President of Tencent
![]()
Acknowledgement
The publication of this book is attributed to many people's hard work. First of all, Iād like to thank the editorial team for their strong support, particularly Yang Hailing, Chief Editor of Posts & Telecom Press. Thanks to her encouragement, I finally got up the courage to write down my consulting practices and experiences in software development to share with more people. Though this book is not perfect, it's a retrospect of my yearsā endeavor and a summary of industrial achievements, including theories, methods, and practical tools. Second, Iāll thank my friend Ren Fake for his proofreading of many chapters of this book and for his valuable suggestions. Thirdly, Iād like to thank CRC Press for publishing the English version.
Of course, Iām grateful to my former colleagues at ThoughtWorks, especially the GoCD team and my partner Jez Humble. I learned agile development and lean thinking from them. It was this work experience that made me proficient in Continuous Delivery practices, thereby guiding my clients solve practical problems in recent years. Wang Pengchao, another friend of mine, ushered me into the wonderland of Extreme Programming. He is now working in Facebook responsible for the development of Cassandra.
Finally, I must thank my wife and my son ā the loves of my life. I once intended to giving up writing this book, it was their encouragement and accompany that helped me regain confidence. My wife is the first reader of this book, she helped me streamline and refine the language, and made the book in a more reasonable layout.
![]()
Author's Note
In 2002, I happened to get the book Extreme Programming Explained: Embrace Change written by Kent Beck, and couldnāt help reading it through. The software development methods introduced in the book are utterly different from those in our actual work. The practices, such as test-driven development (TDD), continuous integration, pair programming, and user story, seem novel and unrealistic. I kept wondering how can a team do all of these things? So I tried some of them, but not thorough enough since I was still a little āskepticalā. For example, I skipped over TDD, and only added some unit tests; I left out pair programming, but insisted on code review; and I preferred daily build to continuous integration. Certain effects started to show after a period of time, but not so significant.
Until 2005, a friend of mine showed me how did his team deliver a software project with the agile development method and how did they write code. Each time the code was modified, a series of automation testcases were written and executed; each submission was accompanied with continuous integration. It was a brand-new coding experience to me: developers rarely need to start the program, but detect the problems in the code through single-step debugging. I finally came to believe agile teams at not fictitious, they are real and not far away from me.
I joined ThoughtWorks in 2007, hoping to experience the agile development method. As a requirements analyst and delivery manager, I took part in the development of GoCD ā an advanced CI and release management system. My partner was Jez Humble, product owner of this project and later co-author of the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Many practices described in his book come from our GoCD development process. From bringing forth the product idea to its official launch, I went through a complete product development process where I got access to the agile development method and learned how to do Continuous Delivery.
After 2009, as an external consultant or internal coach, I started to provide consultations on transition to Agile Development and Lean Production to domestic and foreign companies. Among my clients, there are leading PC Internet companies, traditional IT firms, powerful domestic corporations, and fast-growing mobile Internet startups. In the process of working with my clients, Iāve gained an in-depth understanding of āContinuous Deliveryā and greater confidence in helping them realize the value of Continuous Delivery.
Back to 2007, I was believing that many agile development practices including Extreme Programming (XP) were a magic key for fast and high-quality software delivery. After 2010, I came to realize that although practice itself is important, it must be supported by organizational management, and work ideas and concepts. So I got a new pet phrase as āDonāt talk about āAgileā, just solve problems!ā. After 2012, more software development methods and agile genres began to prevail in China, but the core concepts and main working principles behind them have not fundamentally changed. Regardless of the method, we should start from āsolving problemsā, and an important prerequisite for doing so is to ācorrectly define problems and reach a consensusā.
Iām certainly not a supporter of such absurd argument as āthought is uselessā. On the contrary, I believe that thought is essential to everyone's cognition and understanding of things. But yearsā consulting experiences tell me that a correct understanding of things cannot ensure implementation of correct ideas and concepts, nor can it provide direct and substantial assistance to companies. The goal of promoting correct thoughts is to guide project teams or their customers to address difficult problems.
Just like business management, the development process of software engineering is also a process where various methodologies emerge and develop endlessly. After the term āsoftware engineeringā was coined in the 1960s and the waterfall software development model was proposed in the 1970s, the iterative incremental development came out in 1985, Barry Boehm brought forth the Fountain Model in article A Spiral Model of Software Development and Enhancement published in 1986, the Capability Maturity Model Integration (CMMI) and various lightweight software development methods emerged in the 1990s, the Agile Manifesto was officially released in the early 21st century, and then Lean software development method, Kanban method, Continuous Delivery, and the DevOps movement sprang up successively in recent years. All these changes not only reflect the rapid evolution in IT industry but also prove that no single theory or method can solve all the problems in this industry on its own.
I do hope that this book could show a whole picture of āContinuous Deliveryā to readers. When encountering problems related to the effectiveness of IT groups, readers will be able to deal with them reasonably based on background knowledge learned from this book. Or at least they can get inspired from the real cases included in this book so that they can take fewer detours when facing similar problems.
