And you are here why?

“ Are you deployments predictable? ” The answer to the above really,   really   depends on the context. After all if all you want to do is spin the latest build up on AWS, then nothing could be simpler right? Unless, of course, by “ predictable ” you mean “ It takes Alice 7 minutes to spin up the build ”, and Alice is on vacation. Or your pipeline is automated   once you log in , and your laptop crashed. Or hey, your laptop is just fine, but you ran up against an AWS limit (“ too many EC2 instances ”). And that presupposes that the build actually exists. After all, where did   that come from? And is it a unitary thing, or does “ build ” involve some kind of complex orchestration, involving getting artifacts from   here , doing a docker thing   there , and so forth. Is   that   process predictable? Or are you also at the vagaries of Alice, laptops, DockerHub, and whatnot? The point behind all this is that you need to   know   th...

We’ve all had to deal with  flaky tests  — tests that don’t consistently pass or fail, but are, instead,  nondeterministic . They’re deeply annoying, end up being a huge time-suck, and inevitably end up occupying the bulk of your “productive” time. There are many,  many  reasons for flakiness, but in my experience, the vast majority of them can be boiled down to some combination of the following 1. External Components : When the code relies on something that isn’t under it’s control, and makes assumptions about it. I’ve seen people validate internet access by retrieving  http://google.com  (“ because Google is always up ”, conveniently ignoring the path from the test environment to Google), assume that there is a GPU present (“ because it’s Bob’s code, and he always runs it on his desktop ”), and so forth. The thing is, these assumptions get made even after stubbing — our assumptions about the environment we’re in can frequently lead us to places wh...