When you have thousands of C++ services and you've just changed a core library, how do you make sure nothing broke? In 2016 we explored what that looks like from the perspective of the engineer changing the library (https://youtu.be/_YzUD9FvQlg). Now we're going to look at that same problem from perspective of an engineer working on developer experience, providing that safety, all the while trying to make sure we don't break the bank in machine costs. We'll notice patterns, including how saving machines nearly always means saving developer time and making build/test signal less flaky and more trustworthy. Better savings, better experience.
Most practically for you: we'll go over what can you do in your codebase to improve your testing workflows, ranging from low commitment concepts to high commitment ones. Also importantly: what anti-patterns can you avoid, so that you don't blockade future work in this area.
Our exploration will take us across topics including build tools, how the compiler/linker fits into the story, caching in unexpected places, deciding what to test (in great depth), batching, patterns/anti-patterns for defining workflows, and more. We will talk about real learnings from metric-driven changes to our core continuous integration experiences.
