This post was written by Jovile Bartkeviciute.
It is that time of the year and we are excited to be at PIPELINE again. Organised by Matthew Skelton, Steve Smith, Chris O’Dell, Beccy Stafford and Inka Howorth, the “unconference” is getting better and better every year!
After a quick opening by Inka Howorth and Chris O’Dell the conference started with the Dan North talking about DevOps, automation, autonomy and… Jane Austen!
Here is a quick summary of the talks that I managed to catch:
Keynote by Dan North – “Ops and Operability”
Key Points:
Ops and Operability
- “Provided without warranty approach” – this is how dev treat ops.
- Automation and Autonomy
- Developers initially got excited with automation – automated tests, environments, etc.., but the other thing that came out of automation is autonomy and autonomy NEEDS accountability.
- How to solve local autonomy and global consistency?
- The Spotify problem.
- Even Spotify says not to copy what they did. You should copy the process they went through to find their infrastructure instead of the end result – the result would be different for every company. What they did was ask “how to get from 300 people team to 3000 people team?”
- Need to keep to two constraints:
- Squads need to be autonomous, needs to know legal, etc)
- Contextual consistency
- Given the same context, and the same constraints, we are likely to make similar decisions. Or, what’s the smallest amount of advice you can give me so I’m unlikely to screw this up?
- The Spotify problem.
Support and Supportability
- How to know if your application is supportable?
- Three magical questions for incident management:
- What happened?
- What is impacted?
- How do we fix it?
- The real question is:
- How could we reduce the impact of this?
- MTTR trumps MTBF
- Three magical questions for incident management:
- Captain’s log – pattern
- You should be able to figure out what is wrong by error messages
Quotes:
- “Go and make friends with release managers”
Slides: https://speakerdeck.com/tastapod/ops-and-operability
Video: https://vimeo.com/209681251
John Clapham – “Team Design for Continuous Delivery”
Key Points:
- Co-dependence and co-evolution of a team are essential for continuous delivery.
- Use continuous delivery to reduce the risk of releases, decrease cycle time, and make it economic to work in small batches.
- Automation is not always the answer – it is possible to over-automate.
- Relationships are hard:
- Regarding groups of people – 3 people – 3 individual relationships, 5 people – 10 relationships, 8 people – 28 relationships. The more people, the more relationships there needs to be – they grow exponentially and it is difficult to keep up!
- Why care about social engagement?
- Engagement drives profit – by the State of DevOps Report 2016, companies with high employee engagement grew revenues 2.5 times faster
- What matters if you wish to have a high performing team:
- Dependability
- Structure & clarity
- Meaning of work
- Impact of work
- Psychological safety
- Things to do tomorrow:
- Follow your work, ask for feedback
- Be curious, welcome questions
- Reward (the right) behaviour
- Ignore your job title
- Think small
- It is better to do 100 things at 1% than one thing at 100%.
Quote:
- “Sharknado is a textbook co-evolution example”
Slides: https://www.slideshare.net/john.clapham/team-design-for-continuous-delivery
Video: https://vimeo.com/209684221
Amy Hughes – “Beyond Continuous Delivery – can your insights keep up?”
Key Points:
- Why you should use AB testing
- When you release a new feature, you cannot be sure if it is the new feature that is driving the traffic to your site, it could be a previous interest in the topic or website
- AB testing – you split your users into two groups – half of them see the new features, the other half do not, this way any difference in user behaviour is down to your feature.
- How you can implement it
- You still cannot be sure it is all not down to luck, that is where statistical analysis comes in.
- Firstly, they have depended on a person to do the AB testing and analyse it manually, but later on automated the process.
- How you choose what to test
- Some tests are quick and easy, thus you do not need AB test for that – for example testing traffic due to different headlines would take 15 minutes to test
- AB test needs high traffic – it would not make sense with low traffic and would take too long, with low traffic you need to use old style approach, i.e. user feedback
- AB tests are for the big decisions that matter and can take some time.
Slides: https://pipelineconf.files.wordpress.com/2017/03/amyhughes-beyondcontinuousdelivery.pdf
Video: https://vimeo.com/210059007
Mike Long – Continuous Delivery of Embedded Maintainable Software
Key Points:
- Industrial embedded software is closer to hardware and thus has different challenges.
- Continuous Delivery challenges for the embedded software:
- Access to production like environments – rare
- Support lifespan – up to 20 years – due to high release costs it is not deployed often.
- Safety critical – often
- Regulated markets – often
- Release cost – high
- Deployment – custom
- Audit trail requirements (full traceability) – often
- Deployment/product matrix – complex
- Development principles:
- Component principles:
- Integration and testing of the latest should be automatic
- All binaries should be fully traceable
- Artifacts should be managed
- Metadata should be build into the binary
- Release principles:
- Release is a manual decision
- Release binaries can only depend on released components.
- Component principles:
- Tales from the trenches – Leif Ove
- Closed source operating system, closed source compilers, closed source libraries, etc. – they are a risk to the systems you are creating, you have to think of decades of lifespan.
- Summary:
- Build the foundations
- Increase safety
- Increase development efficiency
Slides: https://www.slideshare.net/meekrosoft/continuous-delivery-of-maintainable-embedded-software
Gareth Rushgrove – “In Praise of Slow (Continuous Delivery)”
Key Points:
- When people think about Continous Delivery, they focus on “quickly”.
- Enterprise software – the land the internet forgot, but everyone wants to be an enterprise software company.
- Can this be continuous delivery?
- Puppet Enterprise ships every 3 months
- Docker EE ships every 3 months
- vSphere ships about every 6 months
- Why is continuous delivery for the enterprise different?
- Users can choose not to update, thus they can have absolutely any version of your software
- Other people may choose to package your software if it’s open source
- Users control the environment, limiting the environments you support costs you users
- Ideally, in CD you would support one version of your software until you ship the next one. However, for enterprise, that needs to be longer, for example – RHEL support lifecycle – 12 years!
- If you release quarterly, each release supported for a year means 4 supported major versions
- Enterprise user expectations clash with some of the expected implementations of the practices of continuous delivery, but the practices of continuous delivery are still relevant to enterprise software
- Continous delivery is all about speed, but speed is a relative measure that depends on a frame of reference
- Always remember to put your users and your context ahead of any absolute measures
Slides: https://speakerdeck.com/garethr/in-praise-of-slow-continuous-delivery
Video: https://vimeo.com/210052251
Rachel Laycock – “Continuous Delivery at Scale”
Key points:
- How do you scale a new technology?
- Getting a DevOps team usually does not work:
- Who is going to be in this team?
- Most of time companies just get the ops team to do that and rename them the DevOps team
- Now they are responsable for automating all infrastructuve and deployment + previous duties
- Understand the constraints – solve for the real problem.
- Don’t try to scale what you haven’t tried out yet.
- Don’t get excited about tech before you understand your problem.
- Expected landmines:
- Organisational silos
- Beaurocracy
- Politics/fiefdoms
- Communication
- Capability
- How do people do this at scale?
- Choose tools
- Guidelines
- How to’s
- Pre-built pipelines
- use SME’s to create the playbook
- Remember why you are doing this – it is all about value.
Quote:
- “Yesterday’s good practice is tomorrow’s anti-pattern.”
Slides: https://pipelineconf.files.wordpress.com/2017/03/rachellaycock-continuousdeliveryatscale.pdf
Video: https://vimeo.com/210053351
All in all that was a great day with a lot of interesting talks, common themes were autonomy and its pitfalls, making ops teams happy and the importance of testing.
Looking forward to next year!
Skelton Thatcher 