The London Continuous Delivery meetup group had its first session of 2013 on 17 Jan. We were fortunate to be able to use the offices of [my employer] thetrainline.com in central London, and doubly fortunate to be joined by Andy Hawkins from Opscode, who ran what turned out to be a brave demo showing how Chef can work with CI tools to provision EC2 instances.
Continue reading London Continuous Delivery meetup with Opscode Chef
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.
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!
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:
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. |
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).
This article first appeared in Software Development Practice, Issue 1, published by IAP (ISSN 2050-1455)
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
The last few months in London have seen a surge in interest in Continuous Delivery by companies wanting to speed up delivery of their web-based software systems. See below for a summary of the events I have been fortunate to be involved with (I know there are many more); if you’re interested in Continuous Delivery and you’re in or close to London, then join the London Continuous Delivery meetup group (#londoncd) and let’s share our experience.
(logo by @DaveNolan!)
James Betteley gave a useful talk at BCS on how he used Maven in a Continuous Delivery context alongside Artifactory, Nexus and Sonar. James blogged about using Maven for Continuous Delivery back in February 2012: well worth a read, even if you’re not using the Java+Maven stack.
In July, Christopher Marsh of AKQA talked about his company’s success with Continuous Delivery on a London-based project for a large client organisation. They used GO from ThoughtWorks Studios for implementing the deployment pipeline.
I went to the London offices 7digital for a Devs In The ‘Ditch session last week, where Chris O’Dell explained how they have moved from painful, irregular releases with tightly-coupled code to frequent small releases and a service-oriented approach. The transformation took two years, and they now restrict deployable units to about a day’s worth of work to make deployment easier. GOOS co-author Steve Freeman also gave a useful talk on full-system testing, which is crucial to get right in a Continuous Delivery context.
The ThoughtWorks Studios product team have changed the pricing model with the 12.3 version of their agile release management tool GO: the free Community edition how has feature parity with the pay-for editions, including previously enterprise-y only features such as LDAP and Environments. This means that small teams can make full use of the excellent deployment pipeline features of GO without the price tag. I was always a bit reluctant to recommend using GO before now because the free version was feature-limited, but with all features now available in all editions, I have to say that for modelling and implementing deployment pipelines, there is other no tool which comes close to GO.
I was fortunate to be able to present at WebPerfDays EU 2012 on how build and deployment shapes software architecture at thetrainline.com [slides] along with Andie and Oddur from CCPGames. Three of the many really excellent discussions that came up were:
In the end, we had to be ‘evicted’ from the room; we could have gone on discussing for another hour! Apparently, one major UK publisher had nearly 10 staff in the session, and rated it the best session in WebPerfDays. It was so great to be among such brilliant minds and conversions, which led me to…
Based on conversations and discussions at At WebPerfDays it was clear that a London-based meetup group centered on Continuous Delivery would be interesting for quite a few people and organisations.
A few of us agreed to get things off the ground, and we’re now on Meetup.com at London Continuous Delivery (http://www.meetup.com/London-Continuous-Delivery/) and on Twitter with #londoncd. Any help, donations, perks, etc. are very welcome.
Matthew Skelton 