Continuous Delivery with Windows and .NET

Preface

By re-architecting for Continuous Delivery, and using tools like Chef and GoCD in combination with Windows and .NET, we were able to move from infrequent, difficult code deployments to weekly, daily, and even hourly deployments, whilst improving our availability and mean time to recovery.

John Esser, Ancestry.com

Continuous Delivery is a well-defined set of practices and approaches to releasing software in a reliable way. At the heart of Continuous Delivery is the automation of software builds, software testing, and software deployments, including the automated configuration of devices and environments for testing and runtime.

Organizations increasingly rely on software systems to enable and power their services, sales, or operations (or all three), and so frequent, reliable, repeatable, and rapid releases are essential in order to keep pace with demands for change. The practices that form Continuous Delivery are no longer optional for many organizations, but rather central to their very survival.

Today, all core software from Microsoft is PowerShell-scriptable, and teams working with Windows and .NET in 2016 and beyond are able to use a rich set of PowerShell and HTTP REST APIs in software packages and products from Microsoft, third-party vendors, and the open source community. This ability to automate Windows and .NET is a huge enabler for Continuous Delivery.

Many of the technologies and approaches for Continuous Delivery are essentially identical across different operating systems, but some things need special treatment for Windows and .NET. When Jez Humble and Dave Farley published their groundbreaking book, Continuous Delivery [HumbleFarley], in 2010, many of the tools described were either nonexistent on the Windows platform or did not support the rich automation capabilities they do now. Our book acts as an addendum to Jez and Dave’s book to encourage many more teams working with Windows and .NET to adopt Continuous Delivery.

Who Should Read This Book

If you build, release, or operate software systems built on .NET or Windows, then this book is for you. Architects, product managers, and CxOs in your organization should read Chapter 7, The Tricky Bits of Continuous Delivery, and start planning some significant changes.

Product Development Best Practices

While good practices for product development with software, such as User Stories, are beyond the scope of this book, we refer to them occasionally. See the excellent book Implementing Lean Software Development [Poppendieck] for more details.

The Structure of the Book

A successful adoption of Continuous Delivery is built upon solid foundations of technical excellence, which we describe here:

Version control, branching, and merging (Chapter 2)

Everything in Continuous Delivery flows from sound version control.

Continuous Integration done well (Chapter 3)

Without CI for application and infrastructure code, Continuous Delivery is not possible.

Deployment pipelines (Chapter 4)

These are for deployment coordination, sharing information, and continuous improvement.

Infrastructure automation (Chapter 6)

Well-tested, well-structured code that defines servers and environments is needed.

The tricky bits (Chapter 7)

These things are as important as the more technical bits, but often get forgotten.

Many teams working with Windows/.NET have been slow to adopt modern, scriptable tools like NuGet and Chocolatey (package management), DSC/Chef/Puppet/Ansible (configuration management), and Vagrant/Packer/ServerSpec (server testing). We have tried to provide a flavor of the kinds of tools you should expect to use, the challenges you might face, and enough understanding of the principles to go and explore the tools and techniques for yourself.

In summary, enjoy the automation that modern Windows and .NET tools and software offer, but don’t forget the social, architectural, and operational challenges that Continuous Delivery requires. We assure you that the changes will be worth it in the end!

Note

In this book, we use C# (so project files are .csproj) but most of the advice applies equally well to other .NET languages like VB.NET or F#.

We hope you find this book useful. We’d love to receive your feedback—send us an email at [e-mail] or leave a comment on the book’s website: http://cdwithwindows.net/.

Acknowledgments

We’d like to thank several people for their comments and support: first, all the people and organizations featured in the case study examples (Andy Lole at Carnect, Paul Shannon at 7digital, Steve Elliott at LateRooms.com, Peter Mounce at JUST EAT, Owain Perry at JustGiving, and John Esser and Russ Barnet at Ancestry.com). Second, we’d like to thank our technical reviewers for their insights (Josef Sin, John Adams, Colin Beales, and Giles Davies from the Visual Studio UK team, and Kundana Palagiri and colleagues from the Microsoft Azure team). Third, we’re grateful to colleagues and friends who made suggestions, including Matt Richardson, Rob Thatcher, João Lebre, and Suzy Beck. Finally, we’d like to thank Dave Farley for writing the Foreword, and the editorial team at O’Reilly (including Brian Anderson and Kristen Brown) for asking us to write this book in the first place and making it ready for publication.