Did I break you? Reverse dependency verification
Different from an open source project, in which dependent projects are unknown, within the SoundCloud organization, we can draw a transparent view on all callers to JVMKit's APIs to see which apps are lagging behind and which are on the straight cutting edge. We then ask ourselves: How exactly can we make sure the entire company follows JVMKit's release cycle? As a platform team and developers of JVMKit, we want to minimize the disruptions to each team's roadmap, onboarding into new APIs, replacement of deprecated calls, etc. With these tools at hand, we can now start thinking about how we can automatically verify whether a change in JVMKit will integrate smoothly with other projects. We can generalize this idea and run the algorithm for each and every repository we previously identified as reverse dependencies of JVMKit - if all of them succeed, the new JVMKit version is good to go! What happens if we were planning to release a JVMKit version and coincidentally on that day, the main branch of likes was broken? We shouldn't consider it the fault of that JVMKit version's bump. As mentioned earlier, at SoundCloud, we have hundreds of projects that rely on JVMKit, which makes compiling and running their tests a time-consuming task. Every day, we can have a view on how our projects will behave when moving forward, and when failures occur, it's also easy to pinpoint reasons: If a single project failed due to an API change, we can dive into possible shortcomings of its implementations or uses of JVMKit's APIs that weren't originally intended.