New eBook on Continuous Delivery with Windows and .NET

Back in 2010 when Jez Humble and Dave Farley wrote their ground-breaking book Continuous Delivery, the Windows and .NET platforms lagged behind the Linux/Mac world in terms of automation capability. That is no longer the case – every core feature in Windows and .NET now has a PowerShell API and all the core tooling needed for Continuous Delivery – package management, artifact repositories, build servers, deployment pipelines tools, infrastructure automation, monitoring,and logging – are all now available natively on Windows/.NET.

Chris O’Dell (@ChrisAnnODell) and I decided we should explain how to make Continuous Delivery work with Windows and .NET, and thanks to the great editorial team at O’Reilly, we’ve published a short eBook:

CD with Windows - cover

The dedicated book website is at CDwithWindows.net and O’Reilly have published the first chapter of the book online as an article: Introduction to Continuous Delivery with Windows. We’d love your feedback: book@cdwithwindows.net

UPDATE: we’ll be at both PIPELINE Conference (March 23 2016) and WinOps Conference (May 24 2016) with printed copies of the book.

Note: we began writing the book in August 2015, and it’s astonishing (and exciting!) how much has changed in the 8 months since then, with Windows Nano, Azure and Windows support for Docker and containers, .NET Core, SQL Server on Linux, and even SSH for Windows. These and more recent developments do not feature in the book – perhaps we’ll do an updated version soon. 

Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

Update: the video of Pete’s talk is here on Vimeo:

Pete Mounce video frame

There were several specific points made by Pete that were interesting for me:

Continue reading Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Roundup: Patterns for Performance and Operability

Patterns for Performance and OperabilityI recently posted a review of Patterns for Performance and Operability by Ford et al on the SoftwareOperability website. I think that this book is exceptionally useful in its treatment of both performance and operability, and anyone who cares about how well software works in Production should buy and read a copy (there are paper and eBook editions).

Two other reviews might be useful too: my colleague Anant East (Head of Architecture and Infrastructure, thetrainline.com) wrote up a detailed review of Patterns for Performance and Operability on the tech blog at thetrainline.com, and I posted a short review on Amazon.

Who Owns My Operability?

Includes recommended reading for software operability: SoftwareOperability.com

Software Operability

Operability is not something which can be ‘bolted on’ or retrofitted to software after it goes live; we need to design and build our software with operability as a first-class concern. You don’t build a bridge, then try to add load-bearing capabilities at the end of the project — but most software projects try to do exactly that, typically with costly results.

Ultimately, the product owner should be responsible for ensuring that operational requirements are prioritized alongside end-user features. If you are responsible for the software product or service, there is only one answer to the question

Who Owns My Operability?

Who Owns My Operability?

Update: the site now shows selected recommended reading on each page load.

(With a nod to whoownsmyavailability.com)

View original post

Festive Graphite Line Art for the Masses

You have an installation of Graphite, a desire to learn more Ruby, and some festive spirit – what emerges?

An xmas tree drawn using proper metrics via the Ruby graphite gem, of course!

Xmas tree plotted using Graphite

The magic happens with the Graphite::Logger class, because we can log metrics at specific points in time:

logger.log(when,{"Branches1" => 3})

I calculated the points to plot on paper, and found decent Graphite rendering settings by experimentation:

Planning the Graphite Xmas tree

The code is on Github here: https://github.com/matthewskelton/GraphiteGreetings – fork away!

require 'Graphite'
require 'Logger'
# Change these as needed for your environment
server = "my.graphite.server.url"
log = Logger.new(STDOUT)
prefix = "Test.Me.XmasTree."
# Create the logger to send stats to Graphite with specific timings
logger = Graphite::Logger.new(server,log)
# Define the offsets
#
# Use Now as a starting point,
# or set a specific time e.g. Time.utc(2012,12,22,19,10,30)
# We need a 20-minute window to plot
t = Time.now
t0 = Time.at(t.to_i - (20 * 60)) # 20 mins ago
t1 = Time.at(t0.to_i + (60 * 1)) # Left base of tree
t2 = Time.at(t0.to_i + (60 * 3)) # Lower tinsel2
# etc.
# Inject the stats - the order is determined by the default Graphite colours
logger.log(t21,{prefix + "Tinsel1" => 3})
logger.log(t18,{prefix + "Tinsel1" => 6})
# etc.
view raw gistfile1.rb hosted with ❤ by GitHub

I’d love to hear or see any suggestions for improvements to the script. Candles? Snowflakes? Reindeer?! Also, as my Ruby-fu is limited, if there are better ways of interacting with Graphite, I’d love the hear about them (I tried and failed to get activesupport to work on my machine, for example).