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 (!).
Modern log aggregation & search tools provide significant new capabilities for teams building, testing, and running software systems. By treating logging as a core system component, and using techniques such as unique event IDs, transaction tracing, and structured log output, we gain rich insights into application behaviour and health, especially cross-component visibility. In this article on InfoQ – co-authored with my colleague Manuel Pais – we explain why it is valuable to test aspects of logging and how to do this with modern log aggregation tooling. This approach makes logging a channel or vector to make distributed systems more testable.
InfoQ: Why and How to Test Logging by Matthew Skelton and Manuel Pais
Bonus: check out these slides from a talk I gave at Testing Showcase North in February 2016 on Why and how to test logging
In an environment of rapidly-changing technology and approaches, an internal tech conference can be a powerful and effective way of spreading new ideas and practices and sharing learning & experience. Having organised and run several internal tech conferences (at different organisations), Victoria Morgan-Smith and I decided to write about our experiences in an article for InfoQ: Internal Tech Conferences – How and Why. We also interviewed several other people from various organisations who have also run internal tech conferences in order to give a broader perspective.
Our aim was to inspire and enable other people to develop and run internal tech conferences in their own organisations, building on the experiences of the teams and organisations in the article.
In this article we draw on our personal experience of running internal tech events at companies we’ve worked with, along with reflections and advice from people at Paddy Power Betfair, Callcredit Information Group, ING and others. You’ll find further reading & listening material at the end of the article – there is so much inspirational work happening in so many organisations.
Key points from the article are:
- Software engineering today is as much about people as the technology itself: an internal tech conference can give a huge boost to your organisation’s social capital – that currency by which relationships flourish.
- The format you choose for your internal tech conference depends on what you want to achieve from it: it can be “by the people for the people”, or a showcase to celebrate achievement. You can keep the audience or speakers to just a single department, or invite other divisions, or even invite external speakers and/or audience.
- Making the event a success takes effort: choose your speakers well, and mentor themas they prepare their talks. Work on the logistics – it’s the little things that count.
- Remember to have fun: ‘death by PowerPoint’ will mean people remember the event for the wrong reasons!
- Follow through: for a lasting impact, keep sight of the outcomes you seek and be ready to work with others to keep the momentum going.
We hope that the article is useful for people thinking of running or improving their own internal tech conferences!
Thanks to everyone involved: people we interviewed, the amazing InfoQ team, and to my co-author Victoria Morgan-Smith.