I gave a talk at Continuous Delivery Amsterdam meetup group on 08 Feb 2017:
Using Rancher for highly available deployment services with GoCD and TeamCity
Tools like GoCD and TeamCity are excellent components of advanced Continuous Delivery deployment systems. They help us focus on deployment pipelines and the flow of changes, rather than “builds” or “environments”. We can further enhance these tools by using frameworks like Rancher to manage GoCD and TeamCity as highly available, always-on deployment services. In this talk, we’ll see how to use Rancher to run deployment pipeline tooling like GoCD and TeamCity, and how this lets us focus on the important parts of Continuous Delivery: getting changes to Production safely and rapidly.
The slides are here:
(Thanks to my colleague Rich B for his sterling work on Rancher+AWS)
The other talk (from Wouter Lagerweij) on testing in a CD world was really excellent – the slides are here: http://www.slideshare.net/wouterla/testing-in-a-continuous-delivery-world-continuous-delivery-amsterdam-meetup
I gave a talk at DevOpsCon Munich on How and why to design your teams for modern software systems – here are the slides:
In the talk, I covered various angles including:
- Conway’s Law
- Cognitive Load for teams
- Team Topologies
- Guidelines for team design
I will be giving a full-day workshop on Organisation Design for Modern Software Systems at Jax DevOps London 2017 (3-6 April) and DevOpsCon Berlin 2017 (June 12-15). Booking is open now for both events.
I gave a talk at Velocity Conference Europe 2016 called How to break apart a monolithic system safely without destroying your team based on work we have done at Skelton Thatcher Consulting over the past few years with various organisations.
The slides are on Slideshare at http://www.slideshare.net/SkeltonThatcher/teams-and-monoliths-matthew-skelton-velocity-eu-2016 and the video of the talk will be online soon.
The main take-aways from the talk are:
- Recognise that by starting with the needs of the team, we can avoid cognitive overload, thereby making future development more sustainable
- Understand the type of monolith you are dealing with (there are many kinds of monolith)
- Consider using Code Forensics (see Your Code as a Crime Scene)
- Find the natural ‘fracture planes’ in your code and work with these
- Instrument the monolith before splitting it up
- Understand data flows and fault responses
- Split off one segment of code at a time, considering the cognitive load for the team
There is quite a bit more in the talk itself, including the effect of Conway’s Law, the benefits of monoliths, and real-world examples from client engagements.
A big thanks from me to the organisers of VelocityConf for their hard work, to the audience in my talk for some excellent questions, and to the speaker selection panel for choosing my talk (!).
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:
Update: the video of Pete’s talk is here on Vimeo:
There were several specific points made by Pete that were interesting for me:
Continue reading Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)
I have recently read (and re-read) several books on Chef in order that I can recommend books to clients who are starting with infrastructure automation (and to remind myself of the more obscure uses of knife, encrypted databags, and so on). In this post I comment on these books:
- Chef Infrastructure Automation Cookbook by Matthias Marschall
- Managing Windows Servers with Chef by John Ewart
- Test-Driven Infrastructure with Chef (2nd Edition) by Stephen Nelson-Smith
- Automation Through Chef Opscode by Navin Sabharwal and Manak Wadhwa
Summary: read Chef Infrastructure Automation Cookbook for a good introduction to Chef on both Linux and Windows; read Managing Windows Servers with Chef if you manage many Windows machines; but most of all read Test-Driven Infrastructure with Chef because without a test-driven approach your infrastructure code will rapidly become tangled, unsupported, and obsolete.
Continue reading Using Chef for infrastructure automation – reading list