Category Archives: Conferences

linux.conf.au in Auckland

Happy New Year.

I’m speaking about Graphs and Neo4j at linux.conf.au next Friday.  Don’t think I’m the star attraction though, I think that’s Linus.

BCS Configuration Management 2012 Conference – Call for Papers

I recently joined the British Computer Society I also joined the BCS Configuration Management Group, and I’m now on the committee.

To me it’s important to understand the place of CM on your project, especially as the landscape is changing so rapidly.

That’s why I’m telling you about the call for papers for the conference in London, on May 29. I’d love to see some submissions from people who are addressing CM as part of DevOps (and not just system configuration management).

Link.


Everything I know about Continuous Integration, I learned from Systems Administration

I was honoured to give a talk at DevOpsDays Gothenburg on Saturday. Much love to Patrick Debois for encouraging me to submit the talk, and huge props to my erstwhile colleague Tom Sulston for agreeing to co-present. The whole thing was a blast.


Tagged

Conference Appearances, Q4 2011

Where the hell did 2011 go? Here’s where to find me for the rest of the year:

  • LondonCI, 18th of October: Tom Duckering will be talking about scaling CI – register at skillsmatter to get in the door. [meetup] [skillsmatter]
  • DevOpsDays Gothenburg, 14 October: It’s my pleasure to return to both Sweden and DevOpsDays for a talk on CI and Systems Administration. [link]
  • BCS, 1st November: Chris Read and I will be doing our Agile 2011 talk on Continuous Integration as special guests at the British Computer Society [link].
  • CITCON, November 12: I haven’t missed this conference in 5 years, so I’ll be showing up here at some stage. [link]
  • LondonCI, November: I’m strongly tempted to make it a pre-xmas drink, as they are selling mince pies in the shops already. Venue will be a pub that has decent ale on tap.
  • Yow! Australia, 1-6 December: I’m talking about Puppet, Chef and infrastructure as code in Melbourne and Brisbane. [link]

It looks like a lot when you write it down.


CITCON London 2011 – November 11-12

Ad we’re back. If you do Continuous Integration or testing in the UK, this is your conference. In addition to an awesome open space conference, you get to go to the pub with some of the smartest CI/Testing/DevOps minds in Europe.

11-12 November 2011, at the Skills Matter Exchange, London.


DevOps – what the hell is it?

The guys at Urbancode[1], Accurev and Rally kindly asked me to do a talk on DevOps for their Agile Comes to You seminar. It felt like it needed to be a little different from usual. So I broke it up into 5 minute chunks and launched into each topic.

I covered 3 conflicting ideas about DevOps:

  • Devops is Systems Administration, but better
  • ‘Devop’ is a new role
  • DevOps is all about collaboration.

I was particularly happy with the slides.


The iterative approach to presenting worked quite well. We demonstrated this with my daughter breaking her collarbone the evening before the talk. Pro tip: a Paediatric Accident and Emergency department is no place to work on your presentations, unless you’re OK with the sound of screaming children). The next day I was a wreck and I think I would have fluffed it if it wasn’t for the chance to pause and take a one-minute break for questions after each ‘iteration’.

[1] They sponsor this blog.


Patterns without Developers: Spa conference workshop

I did a workshop at the fantastic Spa conferencee this year. The purpose was to try and gather patterns in the software development process that didn’t come out of the GoF book or PoEAA.

This is the output from those sessions, so late that I will at least do time in purgatory, if not someplace else. The session went OK. The slides didn’t match the handouts and I managed to invite some heckling, but I was quite pleased to see everyone get down to work and start making patterns. The paper forms I got back didn’t really get as much detail as my shepherd and I anticipated; and I’m giving some names and embellishing where appropriate. Comments below each one.

Name: Embedded Test Team

Definition: Separate teams mean handovers which always impede progress. Instead, embed testers with development team.

Big teams encourage silos and specialisation. Specialists are important but in this pattern you put them right where they are needed.


Name: Blue-green deployments

Definition: On deployment, delay to the slave server of a master/slave pair and then switch traffic routing

Intent: Keep production live at all times. No downtime on release.

The name of this pattern comes from Continuous Delivery [ Get the eBook *]
. It really depends on patterns like Encapsulate Table With View, or a NoSQL database to ensure that you can deploy two application versions at once without causing one to throw database related errors. The most successful use of this was on a project where the client insisted that we use stored procedures to access the database. While it was a big productivity hit for the developers, there were seconds of downtime when we released a new version. [more patterns in Refactoring Databases (eBook)<img border=0 width=1 height=1 src="http://ad.linksynergy.com/fs-bin/show?id=hdK31Ny9YPU&bids=145238.1639474&type=2&subid=0&quot; *]


Name: Cookie Cutter Servers

Definition: Deploy servers as images or automatically built machines, rather than manual or evolved installations.

Intent: Keep consistency between different servers both in production and in test.

If you look for deployment related technical jobs, many of them would have you trying to enforce consistency on different environments, all of which are maintained by hand. This is nuts. Automation is your friend.


Name: Simplicator (Freeman / Pryce)

Definition: Define your own API that can be implemented by a stub for testing or by an adapter,

Intent: Decouple service consumers from providors to make testing more deteministic.

This is published in Growing Object-Oriented Software, Guided By Tests [eBook*]


Name: A/B Deployment

Definition: Continuous deployment to a limited subset.

Intent: Gauge whether new version is an improvement on the old before committing all users.

Applicability: Requires ability to operatemultiple versions in parallel. (Interface versioning!)

Timothy Fitz covered this, but I’m stealing the name from Split Testing until I find a better candidate.


Name: Virtualisation

Definition: Combine VMs to simulate systems in the operational environment

Intent: Create a scale model of the production environment for functional testing.

Motivation: An operational test environment is needed for end-to-end testing with all external systems that the software has to interface to,

Applicability: Operational procedures, testing of response to various events.

I know quite a few people who work as developers at banks. It takes six months to get a server approved and delivered to the point that you can use it, but a mere matter of weeks to get a virtual machine done. That’s reason enough to do it. Let alone the ability to manage change and develop against realistic hardware. This becomes more compelling if you run Linux on server and desktop and can deliver virtualised nodes without the added hoops of licensing. You might get a VM in days if you carry on like that.


Name: Time Slicing

Definition: Bring down test environments when their testing time-slot is past.

Intent: Reuse test hardware for maximum utilisation of the investment

Applicability: Testing reqirements are sporadic and can be resource-levelled over time

Usage: Relies on virtualisation.

The group that made this and the previous pattern were on fire. Another benefit of virtualisation is stopping the horrid project delays because someone has booked out a test environment for months. You’d think that a major constraint like that would be part of the project planning process, but I find that most organisations prefer to have projects managers duke it out, fight-club style.


Name: Stubs

Definition: Ensure a system is tested againststubs and other systems in the environment before it is tested in a full pseudo-production environment.

Stubbing out external services can rock. It’s all about feedback. If your code fails talking to the stubbed services, it’s not ready for primetime. Why wait until you manage to get your app deployed (a battle in it’s own right in big environments).


Name: Atomic deployment

Definition: Ensure that your deployment is transactional: either everything gets deployed, or nothing.

Intent: Ensure that everything that needs to be deployed is deployed or nothing.

Harder than you’d think to get going (can you really roll back that database change? what’s the risk of doing that?) but worth the effort. Artifacts of a failed deployment can cause things to break in ways that are difficult to diagnose.


Name: Configuration Repository

Definition: Eliminate embedded service identifiers, addresses, sizings.

Intent: Abstract parameters out to a configuration service so that:
– It’s easier to manage
– the identical software can be deployed to every environment without adapting.

This pattern has been talked about for a very long time but not often done. Chris and Tom had a go with Escape, and you could probably do a decent job with couchdb. Not having to deploy configuration to each node: priceless.


Name: Synchronised release schedules

Definition: not given

I’m not sure what this was in aid of. If you have dependencies between different applications then you should be managing releases at the programme level. Sadly, many people don’t do that.


Name: I know what you did last deployment

Definition:

Intent: -Get into a known state
-Automate what you do = consistency
-Version control is the key! Both deployed app and deployment script.

Pattern: 1. Mirror production
2. Automate deploy AND rollback
3. Tests against deployment automated

The group that did this struggled with trying to fit many patterns into one, I think. The key takeaways for me are the use of automation and version control. Which shouldn’t surprise anyone – I think they were trying to address the disparity between the way we treat business code and the way we deploy it. Only recently have we seen anything like Joel Tests for this kind of thing.

* If you buy the ebooks via these links (and frankly in the year of the iPad, who’s buying dead tree media?), then commissions go to my Kaffiene and Taylor Street Baristas habit. That’s right, you’re financing my drug dependency.

Tagged ,

Autumn Conference Fun

  • San Francisco, October 7-8: Puppet Camp. Gutted that I can’t make that one. Though won’t miss the jet lag.
  • Hamburg, October 15-16: DevOpsDays Europe. The first time was great. High expectations for the second, as well.
  • London, November 5-6: Citcon Europe 2010. Prague didn’t give us a warm welcome, but London always does.

Also, I’ll show up at the Agile Comes to You seminar in London, organised by this blogs sponsors, Urbancode.

Do tell if you have any other conferences of note.

Silos are for Farmers: now online

Silos are for Farmers, my QCon London talk is online.

The conference season this year managed to dovetail nicely with the birth of The Build Doctor Limited. This was nice in that I was doing a conference talk at the same time that I started my own company; evil in that I didn’t rehearse as much as I might have. It turned out okay despite my nerves at the start. It was a gamble asking the audience to participate, but that seemed to pay off: there was a kind of dialogue, which I find more engaging.

Thanks to everyone for speaking up – especially my heckler (you didn’t come to the pub!), Kirk and Sam. Thanks to Chris for organising a great new conference track.

Silos are for Farmers