This is a fictional story, but it deals with very real problems. So, it’s about how one company, through its leading management personnel, tries to save itself. The “Phoenix Project” is a product of this company that can no longer continue in the usual way. Competitors are rolling out new features quickly, while the current team takes a very long time to release their versions. After such releases, the product’s functionality often fails for many users due to poor quality and weak integration testing.
Understanding the core problem, the company’s managers try every possible way to fix the situation, but at first, nothing works, and things only get worse. There is a heavy dependence on a few key engineers, whose absence makes project maintenance and releasing new versions difficult. Another significant issue is the technical debt, which keeps growing over time.
Over time, the team begins to adopt new approaches to development, especially testing and deployment, and this leads to positive results. Now they have no technical debt, and releases can be done daily if needed. To avoid giving away too many spoilers, I’ll keep this summary very brief and instead focus on some other messages from the book.
The technology of implementing DevOps with full CI/CD solutions is great by itself. However, just introducing the tools often doesn’t bring much benefit to the project. Yes, it allows for faster code development, testing, and delivery to users. But for the product to be in demand and the entire development cycle to be as efficient as possible, it’s necessary to fundamentally change the approaches to communication and process improvement between departments. This issue is always subtly (and sometimes openly) raised throughout the book. The whole construction of DevOps processes is discussed together with motivation, bureaucracy, and other nuances. Some of these nuances are extremely undesirable and destructive. Throughout the book, you can also observe how, alongside building development and delivery processes, the inter-team relationships change as well.
Overall, it’s an interesting book and an easy read. It will be useful for those who want to take a break from work but not stray too far from IT topics. Moreover, many managers and executives would find it helpful to see what problems can arise from the wrong approach and poor organization of processes, and how all this can and should be changed.
