With an ever-increasing array of tools and technologies claiming to 'enable DevOps', how do we know which tools to try or to choose? In-house, open source, or commercial? Ruby or shell? Dedicated or plugins? It transpires that highly collaborative practices such as DevOps and Continuous Delivery require new ways of assessing tools and technologies in order to avoid creating new silos. Matthew Skelton shares his recent experience of helping many different organisations to evaluate and select tools to facilitate DevOps; the recommendations may surprise you.
Slides from Unicom DevOps Summit, 26th June 2014, London
3. Matthew Skelton
•15 years building &
operating software systems
•Cybernetics + Neuroscience
• control engineering
• psychology
• ‘network’ interactions
@matthewpskelton
4. Help orgs to adopt and sustain
good engineering practices
Interim CTO/Head of X, tech strategy,
architecture, workshops, delivery
22. What we did
•Built a walking skeleton pipeline
•Modelled security roles and stages
•Included manual steps (at first)
•Walked people through steps
•Finally: opened firewall so
everyone could see the UI
27. Collaboration
& tool choice
Value collaboration as
a key criterion
Orthogonal to main purpose (?)
“How does [the use of] this tool
help people to collaborate?”
37. Mel Conway, 1968
“organizations which design
systems ... are constrained to
produce designs which are copies
of the communication structures
of these organizations”
http://www.melconway.com/Home/Conways_Law.html
43. Conway & Tool Choice
See the organisation as a system
Separate tools for separate teams
Shared tools for collaborative
teams
http://bit.ly/DevOpsTopologies
46. How to choose tools
for DevOps
Value collaboration aspects
Avoid a learning mountain:
evolve tooling
Avoid Production-only tools
Consider Conway’s Law
(this list is incomplete!)