No software system is perfect. Deep down we all like that because it keeps things interesting, but what do you do when your system is further away from perfection than you’re comfortable with? It may be you are dealing with a legacy monolith or a system that has strange logic, no documentation and hardly any conventions you can recognise. Everything seems to be on fire and you need to stabilise the situation.
We’ll explore some techniques that are useful when working on systems that need a little love. At a high-level, we will go through approaching testing, monitoring, re-architecting and documenting these systems. We will also go through prioritisation when everything is urgent and the non-technical metrics that can help with buy-in for stabilising your system and team.
This talk is an intermediate level talk. The aim is for you to not only learn how to deal with these situations but want to tackle the challenges they present and be excited about the change you can lead.
A post by Jessica White going through Service Level Objective, Agreements and Indicators at a high level.
A post exploring RED, USE and the Four Golden Signals
You’ve been working in an organisation that has seen the light of automated testing. You work in a cross-functional team bringing ops, dev, product, user research, content, testing and many other concerns together in harmony. You have iterated through a model greenfield project, have good test coverage and have obeyed the mantra of the testing pyramid. Just a few months down the line why is it so hard to change things? Why are people questioning the value of your tests? Confidence is dropping. During this talk, we will cover an overview of different levels/types of testing but specifically looking at the value they provide to developers and others maintaining software. We will use this information to challenge some conventional thinking and re-balance how confidence in our software is gained without harming its ongoing maintenance. This talk is suitable for people with exposure to automated testing methods who want to understand a balanced view of creating a sustainable test strategy through to production and beyond.
In their description of microservices James Lewis and Martin Fowler noted that: “The microservice approach to division is different, splitting up into services organized around business capability” But what is a business capability? How do you find them? And why does orienting a microservice around them make a difference.
In this session we will try to shed some light onto the black art of building a business capability map, and how you can use that to define the boundaries of your microservices. We will also look at ideas such as the Inverse Conway Manoeuvre and Products not Projects that enable greater agility and product velocity through the alignment of microservices and capabilities.
Finally, we will look at how some technical concerns, such as integration can be soothed by better understanding how a capability map gives you more effective boundaries.
Develop faster with DevOps DevOps embraces a culture of unifying the creation and distribution of technology in a way that allows for faster release cycles and more resource-efficient product updating. DevOps For Dummies provides a guidebook for those on the development or operations side in need of a primer on this way of working. Inside, DevOps evangelist Emily Freeman provides a roadmap for adopting the management and technology tools, as well as the culture changes, needed to dive head-first into DevOps. Identify your organization’s needs Create a DevOps framework Change your organizational structure Manage projects in the DevOps world DevOps For Dummies is essential reading for developers and operations professionals in the early stages of DevOps adoption