Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

There were several specific points made by Pete that were interesting for me:

Continue reading

Bridge the Business-DevOps gap with agile practices

Originally posted on Skelton Thatcher Consulting - Blog:

Summary: some organisations are attempting to adopt DevOps without really understanding or adopting agile practices for software product development, and so are missing out on significant opportunities for improved innovation, delivery, and operation of their software systems. This gap between DevOps and ‘product’ or ‘the business’ is best bridged with agile practices.

How understood is agile?

I was recently chatting to the UK head of a medium-sized IT outsourcing company (3000+ people) about DevOps and in particular how agile practices are now effectively mandatory for new public sector software projects in the UK. This seemed to reflect a recent ‘pivot’ away from traditional over-planned software projects, helped by reports from Gartner, Forrester and friends that have identified agile-based software delivery as significantly more effective for most scenarios than traditional ‘waterfall’ methods.

However, are agile practices really understood and used in organisations, especially those adopting DevOps? Based on my recent experience…

View original 746 more words

HP is trying to patent Continuous Delivery – here is how you can help block this madness

Summary: Hewlett-Packard (HP) has filed several patents covering standard Continuous Delivery (CD) practices. You can help to have these patents revoked by providing ‘prior art’ examples on Stack Exchange.

On 1st March 2015 I discovered that in 2012 HP had filed a patent (WO2014027990) with the USPO for ‘Performance tests in a continuous deployment pipeline‘ (the patent was granted published in 2014). The exact search I used was https://www.google.co.uk/webhp?q=performance+testing++in+a+pipeline and the patent grabbed my attention almost immediately as it was around the 5th result (as I write this, it still is):

Search results for performance testing in a pipeline

I immediately tweeted and @-mentioned Jez Humble (@jezhumble) and Dave Farley (@davefarley77), co-authors of the foundational book Continuous Delivery, to alert them (their book was published in 2010, two years before the HP patents were filed).

My friend and colleague Steve Smith (@agilestevesmith) quickly created a ‘prior art’ request on the Ask Patents Stack Exchange site to coordinate the collection of references to prior art, so that we have a coordinated place to document the many existing examples of running performance tests in a deployment pipeline prior to the patent being filed. This will help us to refute this patent (WO2014027990). As of today (6th March 2015) the Ask Patents page and various Twitter threads had contributions from several early proponents of CD including Chris Read, Dan North, Jez Humble, Dave Farley, Pat Kua, Andreas Grabner, Erik Doernenburg, and Martin Fowler (amongst others).

The plot thickens

As the “WTF?!” spread on Twitter, Marco Abis (@capotribu) pointed out that not only were the authors almost literally unknown anywhere else on the internet, but that the same HP authors had filed patents for many more standard CD practices:

Here is a screenshot of the search results as of 6th March:

Patents by Inbar SHANI

For the record, here are the patent reference identifiers for these HP patents covering basic CD practices (alternate references given, and hyperlinks to the Ask Patents pages – I will update this page with links to new Ask Patent pages as they appear):

There may of course be other patents filed by HP covering standard CD practices (see below, Okay, what can I do to help?)

WT-actual-F is HP doing?!

There are two explanations I can think of for what HP is doing here. Either the authors of these patents – collectively Adam SPEKTOR, Inbar SHANI, Yaron Burg, Amichai Nitsan, Sigal MAON, Ilan Shufer, Eli Mordechai, and Lior Manor, all of Hewlett-Packard Development Company, L.P. – have been locked away in a cupboard for the last 10 years and have independently invented terms like ‘deployment pipeline’ and are filing what they believe to be genuine applications for true innovations (in which case, I kind of get it, as I think that deployment pipelines are awesome), or (the more likely explanation in my view) HP is patent trolling in a frankly stupid and disrespectful way.

So what’s the problem?

The ‘inventions’ in the HP patents have been practiced, implemented, and documented by advocates of Continuous Integration and Continuous Delivery for many years prior to 2012, particularly by people at ThoughtWorks but also by people from Atlassian, The Guardian, Dynatrace and many others (details in the Ask Patents page for WO2014027990A1).

For instance, here is extract from an article in Dr. Dobb’s (sadly now moribund) from February 2008 by Steve Haines called Continuous Integration and Performance Testing (examples use the first CI server, CruiseControl):

Now you can add performance tests into the continuous integration process. The most straightforward method is to create a new virtual project in CruiseControl, one that uses the same build script but executes a performance unit-testing target. The following shows the key changes you could make to a copy of Listing One’s project definition:

<project name=”ant-junit-performance-unit-tests”>…<schedule interval=”600″><ant anthome=”apache-ant-1.6.5″buildfile=”projects/${project.name}/build.xml”target=”performance-unit-tests.execute” /></schedule><publishers>

<onsuccess>

<artifactspublisher dest=”artifacts/${project.name}”

dir=”projects/ant-junit/profiling-reports”/>

</onsuccess>

In this case, CruiseControl is configured to check for source updates every five minutes—because performance tests take longer to run, they cannot and should not be run as frequently. In a real-world application, checking hourly is more reasonable.

Not only does the article describe the concept of running performance tests as part of CI, but it also shows how; we are also shown how to collect the results, using JMeter:

Once integrated, you define a JMeter Ant task by adding the following to the Ant script:

 <taskdef name=”jmeter”classname=”org.programmerplanet.ant.taskdefs.jmeter.JMeterTask”/>

This is a clear example of prior art. For nearly 40 years Dr. Dobb’s Journal was one of the foremost software magazines in the world (I remember in the late 1990s tentatively reading my first Dr. Dobb’s articles on sorting algorithms and mutexes, and realising how relevant Dr. Dobb’s seemed). There is no excuse for the HP people for missing this kind of prior art when it was so readily available.

To me the patents filed by HP feel like a ‘land grab’ by a company that is struggling to be relevant in the world of Continuous Delivery, with old-skool application release automation (ARA) tools simply rebranded as ‘Continuous Delivery’ (incidentally, may the gods help anyone who pays for these soul-destroying HP tools).

Okay, so what can I do to help?

For each of the patents above we need examples of prior art before 2012: articles, blog posts, conference talks, book chapters, etc. If a patent does not have an Ask Patent page, please create an Ask Patents page (the easiest way to do this is via Google – search for the patent code). Then post the relevant details on the Ask Patents page for the specific patent.

You can also search for other patents from HP relating to CD – perhaps using a different author name (the patents above all relate to Inbar Shani only).

Together let us get the patents overturned through decent prior art details and stop this madness. From the start Continuous Delivery has been a practitioner- and community-led endeavour (with generous guidance from ThoughtWorks). CD is not the place for large behemoth corporations like HP to muscle in and take ownership. As Dan North puts it:

“Identification of a failed code change” in a build pipeline. As a patent. Really @HP? #getoffmylawn

Footnote

Thanks to everyone who helped to spread the word about this, in particular Steve Smith, Dan North, Marco Abis, Pushpak Singh, and all who have added prior art details to the Ask Patents page and contributed to the Twitter WTF stream.

Updates

  1. Corrected ‘granted’ to ‘published’ in first main paragraph. (2015-03-08)

Continuous Delivery: Tools, Collaboration, and Conway’s Law – slides from QCon London

Originally posted on Skelton Thatcher Consulting - Blog:

We were asked to speak in the DevOps & Continuous Delivery track at QCon London this year, and on 5th March our co-founder Matthew Skelton gave a talk on ‘Continuous Delivery: Tools, Collaboration, and Conway’s Law‘. Here are the slides and some photos from the talk:

Photo of Matthew Skelton at QCon London 2015

The recent CA DevOps Perspectives 2 report contains an article based on the themes in our QCon talk:

DevOps Perspectives II cover

Download the CA DevOps Perspectives 2 report now.

View original

Continuous Delivery for databases: microservices, team structures, and Conway’s Law

The way we think about data and databases must adapt to fit with dynamic cloud infrastructure and Continuous Delivery. The need for rapid deployments and feedback from software changes combined with an increase in complexity of modern distributed systems and powerful new tooling are together driving significant changes to the way we design, build, and operate software systems. These changes require new ways of writing code, new team structures, and new ownership models for software systems, all of which in turn have implications for data and databases.

Read the full article on Simple Talk: Continuous Delivery for Databases: Microservices, Team Structures, and Conway’s Law.

(These slides were presented in a talk I gave at develop:BBC 2014 conference on 13th November in London)

Using ball flow exercises to highlight bottlenecks in software delivery

Originally posted on Experience DevOps:

One of the exercises we do during the Experience DevOps workshop is a ball flow scenario inspired by the Ball Point game. We set up different combinations and topologies of Dev teams and Ops teams, and then see how many balls the teams can pass in (say) 60 seconds.

Experience-DevOps-ball-flow-exercise

When we ran the workshop recently in Bangalore, we had a large number of participants, which enabled some interesting experimentation with the topology of the teams. In the exercise, the ‘Dev’ team takes balls from the ‘backlog’, and eventually passes the balls to the ‘Ops’ team, who must ‘make the features live’ under some constraints designed to simulate real-world physical constraints.

Experience-DevOps-in-Bangalore

With the large group of participants in Bangalore, we experimented with multiple value streams (or products). After ‘warm-up’ runs using a single ‘product’ (value stream) and therefore a single Dev team and a single Ops team, we split people into two separate…

View original 256 more words

Continuous Delivery eBook from Zend – views from 29 authors

I was recently asked to contribute to an eBook from Zend about moving to Continuous Delivery (CD). The 29 authors in the book share a wide range of experience with CD, and there is plenty of useful advice;  the contributions from Mathias Meyer (@roidrage), Kate Matsudaira (@katemats), and Jamie Ingilby (@jamiei) are particularly worth reading, I think.

In my section of the book I explain how using ThoughtWorks GO to model the testing and release steps (effectively part of the value stream) we won trust from several different people and teams during a move to CD. Using a prototype also helped us to validate the activities undertaken:

We tried to empathize with their situation and, using role-based security in the deployment pipeline, uncovered enough information to give them a sense of visibility and control.

Without being able to visualise and communicate easily the activities we were automating, progress would have been slow or even blocked.

Get a free copy of the eBook here: http://bit.ly/ZendCDbook

Zend eBook CD