Welcome, bold adventurer! Are you ready to work with me to explore the multiple paths of deployment, activation, and feature flags? The audience drives the talk by choosing different deployment and activation options in real time and we’ll see how the story ends.

We’ll use this format to explore how feature flags can work with CI/CD or other rapid deployment models, and how we can work to make deployments safer and faster incrementally.

Audiences will get a fun, fast-paced exploration of forking deployments. They’ll walk away with an understanding of how to reduce the risk of major changes, how to follow multiple streams of deployment, and how to evaluate the best way to speed deployment in their environments.

This really is a dynamic, audience driven presentation. They'll select branching options, and I'll create the talk on the fly based on pre-determined options. As such, it's going to be hard to show you the outline. Topics I intend to cover include feature flags, scaled deployments, and kill switches.

We never change the amount of work or technical debt, we just shift it, and with it, we change how it emerges and appears.

Our systems don’t have to be perfect to be operational - planes, networks, and elite athletes all function at extremely high levels even though they are not operating at 100%.

The audience will leave with some concrete ideas about how to add resiliency to their system by learning to trust but mitigate their reliance on perfect performance of their underlying tools.

As an industry, we have moved the locus of control from hardware to operating system to virtual machine, to container, to orchestration, and now we are approaching serverless. None of that has reduced the amount of work that must happen, it just makes it possible to re-use and conceptually compress the work of others. Since we are making the work in our tools less visible, we also have less control over how they work. We end up assuming that the promises that have been true will continue to be true, but that is not in our control.

How do we handle this level of uncertainty? By adding in error budgets, layered access, and other accommodations for failure and for designing our systems for function over form or purity.

Hoarding is only really painful when we run out of space. In a world with very cheap data storage, it never occurs to us that we should be getting rid of data instead of just storing it in giant silos. I'll explain why we are storing increasingly dangerous poison in our databases, and why we ought to care about automated de-acquisition and deletion.

This talk is not about data in the abstract, it's about ergot poisoning and hoarding and konmari and bitrot. When and why to kill your precious data, why data is a double-edged sword.

No one tells developers and project managers to throw things away. We assume that because it's cheap to keep it around, the emotional comfort is worth the tradeoff. But we're not thinking about how vulnerable we make ourselves by not having an automated and tested way of getting rid of things that we don't need anymore.

I want to problematize keeping deprecated codebases around, and emphasize that mindless retention of data and code just increases our threat surfaces for attack and data corruption. Attackers in the future may be motivated by both ideology and money, and we are responsible for that.

Lots of us aren’t developing tidy, discrete features that are easy to manage. How do you plan to move from a tangle of interconnected features to something that you can test and deploy each part of? How do you manage the combinatorial complexity of individual feature testing? Join us for an overview on the conceptual basis of designing for feature management.

It sounds simple to say that we will build one feature at a time, give it an API interface and allow it to connect with other features and microservices. The implementation is anything but simple. This talk explores how you can start migrating your existing features and services to a more modular, testable, and resilient system.

Since containers are not state-aware, how do you make changes to their presentation without needing to rebuild them entirely? With feature flags, your container can be stable and your presentation dynamic. How can you test a distributed architecture on your laptop? How can you simulate partial outages? This talk is going to touch on some of the best practices that you can use to bring new life to your brown fields.