Continuous Delivery is widely seen as “state of the art” in today’s software development process. There are good reasons for this. Continuous Delivery is grounded in a pragmatic, empirical approach to software development. At its simplest, Continuous Delivery is about optimizing the whole software development process—from having an idea to getting that idea into the hands of our users, in the form of high-quality, working software, as quickly and efficiently as we can. Then we can figure out what our users make of our ideas.
We actively seek feedback loops like this within the development process, and look to optimize them. We encourage the adoption of a genuinely experimental approach to every aspect of software development. In fact, I think that over the past few years, we are seeing signs of the software development process maturing.
I think that what we are seeing is the recognition and establishment of what software engineering should really look like: high quality, iterative, experimental, empirical—in fact, grounded in the scientific method. I am probably biased, but I believe that Continuous Delivery represents an important step forward in the software development process. It works. It makes the organizations that practice it more efficient at creating high-quality software that delights their users.
You will notice that my description did not mention technology at all. That is because the ideas of Continuous Delivery are not tied to any specific technology. You can practice this approach to development for any software tech. However, if our aim is to “create a repeatable, reliable process for software delivery,” then automation plays an important part. After all, human beings are not really very good at being repeatable and reliable! So technology, though not the most important aspect, plays a vital role. On this technology front, the picture across the software industry is complex. There are at least two factions: the world of Windows and .NET, and the Unix-based tribes of the “Open Stack.”
I think it fair to say that some of the initial innovation in the Continuous Delivery space came from the Open Stack community—unit test frameworks, build management systems, sophisticated version control and dependency management systems, and more recently support for ideas like “infrastructure as code” and “deployment pipelines.”
It has never been as simple as “Open Stack has the best tools and Windows plays catch-up.” The first publicly available Continuous Integration (build management) system was CruiseControl, followed quite quickly by a “port” to Windows called CruiseControl.NET, which was significantly better than the original. So over time, both worlds have developed their own collections of technology to support Continuous Delivery and its associated practices. Because many of the people that started the conversation on this new approach came from the Open Stack world (myself included), the language that we used and the tools that we described were not always descriptions or technologies that would resonate with someone from the Windows and .NET world.
It is great to see Matthew and Chris redress the balance. This book is much more than a simple description of Windows native tooling for Continuous Delivery, though that information is provided here. This book explores the ideas of Continuous Delivery and talks about the broad concepts and philosophy, as well as describing some of the specific tooling that works in a Windows-native way. In addition, it also describes some of the tools that are stack-neutral and available to any software developer whatever their toolset.
Chris and Matthew bring real-world experience to their writing, and back up their descriptions with firsthand experience of the technologies described and case studies from many different organizations.
If you are developing software of any kind in the Windows environment, this book is for you. Continuous Delivery is too important an idea to miss the boat. Enjoy the book!