Some devops links and resources

At a recent Amsterdam Middleware Meetup I promised I would post some links about the devops movement.   I decided to replicate that post here for easier reference.

Start with the devopsdays.org site created by Patrick Debois, who coined the term 'devops'.

It's not easy to come up with a good definition.  Devops is a movement where system administrators and developers work together to continuously build and maintain a single system including application, infrastructure and process.  It builds on old and recent ideas from software development and lean systems thinking.


Some key concepts and a few links:

Michael Nygard on "Agile Operations in the Enterprise" (InfoQ)

InfoQ has an excellent article on Agile Operations in the Enterprise by Michael Nygard. (posted 2010-05-21)


In the introduction, Nygard defines Agile Operations, and how they are all about the principles, not just tools or procedures.

One paragraph in the intro stands out, as it addresses a major misconception about agile operations (or #devops):

Like agile software development, agile operations emphatically does not equate to cowboy administrators running amok on the systems, without plan or documentation. Quite the opposite, agile operations requires great self-discipline. Operators must commit to putting everything into version control. They must accept nothing less than 100% automation. Manual actions must never be permitted.

The article goes on about typical enterprise issues like Audit and Compliance (SoX), and ITIL.
And the quote above already implies about how Agile Operations deals with these challenges.

Nygard continues with the bigger challenges of History and Culture before concluding with a couple of warnings.

[... ]a team without the agile principles can emulate the practices but will not derive the benefits

Focus on the agile principles and automate everything.

Automated Acceptance Tests are not worth the cost

InfoQ cites Jim Shore (author of The Art of Agile Development), who in has abandoned Automated Acceptance tools because they're not worth the cost, as he reported in February, in response to a question from Gojko Adzic. This was followed up by Jim Shore with a summary of Alternatives to Acceptance Testing, and a twitter debate about Fit recorded and commented on by Eric Lefevre.

So, everyone re-emphasizes that getting business folks together with developers and having them talk through examples is still a must-do, whew. But regarding automating these examples, Shore, Rainsberger, and Marick say no. Others argue yes. -- An interesting debate indeed. What say you? -- InfoQ

So, I'm not in application development, I've only recently arrived at Agile via the #devops movement, and I've been gathering many references to things I learned about in Gent.

What strikes me is that Jim Shore does not say no to automated testing. Number one in his list of alternatives is still his 'defect-elimination workhorse' of Test-Driven Development (TDD).

And that number one actually consists of three seperate practices: unit test, focused integration tests, and end-to-end integration tests.

Those are all part of the Continuous Integration paradigm: ship early, ship often. And all of these tests are essential for such practices as refactoring. (Or we will never be able to fulfill one primary requirement for the latter: unchanged behaviour).

Automated builds and automated testing are all about keeping the feedback loop short.

Acceptance tests come down to one simple thing, or just one single word...