Three Org Changes to Encourage DevOps

Posted on by Matthew Skelton (@matthewskelton)

[#encouragedevops] In the talks and break-out sessions at DevOpsDays London, in conversations at London Continuous Delivery meetup group, in numerous blog posts and articles talking about introducing a DevOps culture (e.g. http://devopsnet.com/, http://www.stephen-smith.co.uk/), and based on my own experience of organisations I have worked within, it is clear there are three key practical steps which an organisation can take in order to encourage a DevOps culture of collaborative, cross-functional, product-focused working which leads to more effective delivery of software-based services.

(I’ll be blogging about each one of these steps over the next few weeks with the tag #encouragedevops)

Continue reading Three Org Changes to Encourage DevOps

Who Owns My Operability?

Posted on by Matthew Skelton (@matthewskelton)

Includes recommended reading for software operability: SoftwareOperability.com

Matthew Skelton (@matthewskelton)'s avatarSoftware 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

Cloud Deployments – Alex Papadimoulis at QConLondon 2013

Posted on by Matthew Skelton (@matthewskelton)

Alex Papadimoulis (@apapadimoulis) of Inedo (and TheDailyWTF) gave a really useful talk on deployments for cloud-based software systems at QConLondon 2013 recently [slides, PDF, 1.6MB].

He stressed the importance of finding the appropriate deployment (distribution + delivery) model for each application, and to keep deployments as simple as possible. In fact, we can follow the best practices from Continuous Integration and apply them to deployment.

Continue reading Cloud Deployments – Alex Papadimoulis at QConLondon 2013

Comic Relief, @garethr, @LordCope, and CloudFoundry at QConLondon 2013

Posted on by Matthew Skelton (@matthewskelton)

I attended QConLondon 2013 last week; what I took from the first four sessions in the Building for Clouds track was: cloud API and infrastructure automation tools have now solved most of the ‘easy’ cloud problems, but harder challenges (such as automating clusters) remain. The sessions were from Tim Savage (@timjsavage) and Zenon Hannick (@zenonhannick) on Comic Relief’s unique challenges with performance testing, Gareth Rushgrove (@garethr) on how to avoid PaaS lock-in, Stephen Nelson-Smith (@LordCope) on how to use Chef to give you ‘optionality’ with different cloud vendors, and Andrew Crump (@acrmp) and Chris Hedley (@ChristHedley) on the CloudFoundry cloud platform.

Continue reading Comic Relief, @garethr, @LordCope, and CloudFoundry at QConLondon 2013

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?