What Makes an Effective Build and Deployment Radiator Screen?

Posted on by Matthew Skelton (@matthewskelton)

Build screens (or build monitors, or information radiators) are an important tool in helping to achieve Continuous Integration and in trapping errors early. When the number of build jobs becomes large, it can be tempting to hide ‘successful’ jobs to save space, but we found this to cause problems. I realised that people need to know the context for the red jobs if they are to take prompt action to fix failing builds, so it’s important to represent the full state of all builds by showing green jobs too.

Continue reading What Makes an Effective Build and Deployment Radiator Screen?

2012 in review – blog.matthewskelton.net

Posted on by Matthew Skelton (@matthewskelton)

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 10,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 17 years to get that many views.

Click here to see the complete report.

Festive Graphite Line Art for the Masses

Posted on by Matthew Skelton (@matthewskelton)

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).

Tune logging levels in Production without recompiling code

Posted on by Matthew Skelton (@matthewskelton)
IAP Software Development Practice JournalThis article first appeared in Software Development Practice, Issue 1, published by IAP (ISSN 2050-1455) 

Abstract

When raising log events in code it can be difficult to choose a severity level (such as Error, Warning, etc.) which will be appropriate for Production; moreover, the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environments (Development (Dev), User Acceptance Testing (UAT), Non-Functional Testing (NFT), Production, etc.) may also require different severity levels for testing purposes. We do not want to recompile an application just to change log severity levels; therefore, the severity level of all events should be configurable for each application or component, and be decoupled from event-raising code, allowing us to tune the severity without recompiling the code.

A simple way to achieve this power and flexibility is to define a set of known event IDs by using a sparse enumeration (enum in C#, Java, and C++), combined with event-ID-to-severity mappings contained in application configuration, allowing the event to be logged with the appropriate configured severity, and for the severity to be changed easily after deployment.

Continue reading Tune logging levels in Production without recompiling code

GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well

Posted on by Matthew Skelton (@matthewskelton)

I recently went to a Devs in the ‘Ditch meetup at 7digital to hear Chris O’Dell (@ChrisAnnODell) explain 7digital’s journey to Continuous Delivery and Steve Freeman (@sf105) speak on GOOS and system testing. We had some useful discussions on dependency injection and how to use logging well, and Steve’s perspectives on ‘code shapes’ and the purpose of tests were revealing.

Continue reading GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well