Read on Twitter
i mean, i think i've tweeted this list a few times too. but ok :)
* smaller diffs, faster reviews
* app versions backwards/forwards compatible with data migrations
* holding engineers accountable for watching their code go out
* and instrumenting their code for observability https://twitter.com/VeryCoolGuyNico/status/1343680258176933890
* smaller diffs, faster reviews
* app versions backwards/forwards compatible with data migrations
* holding engineers accountable for watching their code go out
* and instrumenting their code for observability https://twitter.com/VeryCoolGuyNico/status/1343680258176933890
* swift deploys let you ship a single changeset by a single dev at a time
* making it easy to isolate the owner of any problem
* preventing the blast radius from expanding
* and making it easy to fix while the intended effects of the code are fresh in their mind
* making it easy to isolate the owner of any problem
* preventing the blast radius from expanding
* and making it easy to fix while the intended effects of the code are fresh in their mind
if your deploys take a long time, or have to be manually initiated, the first pathological symptom you see is that deploys are never manually kicked off upon each merge.
so you end up bunching together multiple changes, by multiple devs.
so you end up bunching together multiple changes, by multiple devs.
the second pathological symptom is that it is not a predictable interval from when you merge to when you see your code, but a variable interval. possibly hours, possibly days -- who knows?
it's enough to break the virtuous muscle memory of "merge, then watch for your changes"
it's enough to break the virtuous muscle memory of "merge, then watch for your changes"
it gets worse.. but with just those two alone, you're already in a state where you cannot hold engineers responsible for owning the lifecycle of their code.
if the deploy breaks, it might be their change or half a dozen other people's changes. "eh, ops will tell me if it's mine"
if the deploy breaks, it might be their change or half a dozen other people's changes. "eh, ops will tell me if it's mine"
when a deploy fails, and it has changesets from six different devs spanning two days.. none of them are on high alert. none of them consider it "theirs".
but when something breaks, *all* of them end up needing to be interrupted and context switch. this gets costly af.
but when something breaks, *all* of them end up needing to be interrupted and context switch. this gets costly af.
