It’s time to stop thinking of quality as something that can only be achieved before your code is released.
Join SmartBear, Ministry of Testing, and Charity Majors as we discuss the need for testing in production and the importance of observability.
6:00 - 6:30 --- Networking, Pizza & Drinks
6:30 - 7:15 --- Testing in Production: Yes You Can (And You Should), Charity Majors, Honeycomb.io
7:15 - 8:00 --- Westworld, Delos & The Perils of Ignoring Quality & Observability, Saoirse Hinksmon, SmartBear
For those who can’t make it in person, this event will be live streamed starting at 6:30 PM ET at https://www.youtube.com/smartbear . Please do not RSVP to this event if you will not be attending in person.
Testing in Production: Yes You Can (And You Should)
Charity's Twitter: https://twitter.com/mipsytipsy
Charity's Blog: https://www.honeycomb.io/blog/
Free eBook on Observability: https://www.honeycomb.io/resources/guide-achieving-observability/
Testing in production — it's gotten a bad rap. But here's the truth: you do it, I do it, everybody does it, and that's not a bad thing. You don't actually have a choice, since every deploy to production is an irreducibly unique combination of that artifact + deploy process + environment + point-in-time infrastructure. In other words, a test.
So you already test in prod, like it or not ... but you probably haven't invested in enough tooling, so you probably do a shit job of it. Let's talk about how to test in production like a grownup — with guard rails and proper best practices, like canarying, feature flags, instrumentation and observability, human best practices and workflows, etc. Stop flushing senseless hours down the black hole for engineering time that is staging. Take back some of those precious hours and invest them in your production tooling instead.
Why? Because production is the only environment that matters (besides your laptop). Most interesting problems are only going to manifest under real workloads, on real data, with real users doing unpredictable things under real concurrency and resource constraints. Replica environments are not valuable for helping us build up our instincts — secondary environments actually train us to expect faulty assumptions and take dangerous shortcuts. You should force people to develop and test in prod as much as possible; engineers should interact with production every day. This isn't even scary — and works for regulated environments too. Promise.
Westworld, Delos, & The Perils of Ignoring Quality & Observability
Even though our lives are a bit more challenging than those of the characters in the popular TV series “Westworld,” the show still offers a few great lessons in the importance of quality and observability in your software development lifecycle, including the consequences of ignoring these two factors.
Teams all over the world are feeling the pressure to move faster, increase performance, and continuously innovate, all without sacrificing the standard of quality that we as consumers have grown to demand. With the rise of Agile and DevOps, software development teams are learning to adapt to speed, take on new responsibilities, and continuously iterate on the processes they have in place.
In this talk, we’ll dissect the successes and failures of the Delos team and how modern teams can learn from their mistakes to cultivate a culture of quality and observability within their own teams. We’ll cover team how transforming culture, workflows, and tooling that supports your need for visibility and continuous feedback can ultimately help you release quality code confidently and, of course, continuously.