Happy New Year.
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).
Where the hell did 2011 go? Here’s where to find me for the rest of the year:
It looks like a lot when you write it down.
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.
The guys at Urbancode, 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:
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’.
 They sponsor this blog.
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" *]
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.
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.
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!)
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.
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
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.
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, 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.