eBook: Continuous Delivery with Windows and .Net

Matthew Skelton and I have co-authored a short eBook focussing on Continuous Delivery with Windows and .Net.  This eBook is available for free from O’Reilly.cdwithwindows-cover

It contains some empirical advice around the practice of Continuous Delivery, an overview of tooling suitable for use in a Windows/.net environment and case studies from a variety of companies employing many of the techniques.  Take a look at the full Table of Contents on the book’s microsite.

Matthew and I spoke at the London Continuous Delivery meetup group on 23rd February 2016, using some case studies from the book and some person experience to show how Continuous Delivery is very much possible in 2016 and beyond.




Download the book for free and let us know if you have any feedback – we’d really appreciate it.

Continuous Delivery at 7digital

It began with an off-hand comment on the ACCU General mailing list that at 7digital we release on average 50 times per week, across all of our products.  I thought nothing of it, virtually all of our products are web-based, which makes it relatively easy to deploy on a regular basis, but it seemed that others were interested in how we do it and so I was cajoled into giving my first presentation.

I began by explaining what we understand as Continuous Delivery – a set of repeatable, reliable steps which a change must go through before being released.  In our case most of these steps are automated.

I described where we came from and how we approached the change, in both a technical and business manner, and where we would like to see ourselves going.  I then included a flowchart of  A Day in the Life of a Change at 7digital, which Prezi allows me to ‘bounce’ around as we hit different stages in the pipeline.

I answered many questions clarifying how we handle rolling back a bad release (we actually ‘roll-forward’ with artifacts of the previous ‘good’ release), whether our QA team are comfortable with the process (yes, they help write the criteria),  and how large pieces of work are tackled (we try to break them down into deployable pieces no bigger than a day).

Here are the slides: