Recently, there is a post by Google on Venture Beat regarding causes for build failures. If there is one thing about Google I give credit for is the hunger and drive beyond the current standard. They want perfection, or at least as much as possible. Anyways, the article break down the causes and one of which for Java and C++ is libray dependency. So, that should not shock anyone working with Java and C++ long enough. You forgot to include a file and kaboom! A compiler failure five minute later and back to typing one line, and recompile everything again... (@__@)
However, one idea just popped up in my head few minutes ago. Another big reason for a major breakage is library upgrade. If you ever work on any software project, you will realized that libraries get updated consistently due to additional features, fixed bugs, or security issues (like HeartBleed). So, how can you make sure that dependencies upgrade will not break anything? Smoke tests and unit tests, of course!
If those builds have tests in-place, then it should detect the unexpcted anomalies. However, current build systems (ex: Jenkins) do not know anything about dependencies. This is a drawback and a big deterrent to updating to a new library. It goes against "Do not fix something that did not break" philosophy. The reason is not because upgrading is bad, but upgrading takes work! A lot of tedious and no appreciation work.
My proposal would be to have a build system that can recognize each project's dependencies. It could be a link to some folder and a script to parse the version number. It could be manually entered URL, like GitHub. It could anything really. If the build system can understand each build's dependencies, then it can be expanded further to do mini-jobs like... find new builds, auto test each new dependency with the current source code, back-port a dependency library to an older version (useful for security fixes, and detect which older versions can be updated to the latest library), report version numbers of each dependency library, test if a specific version is compatible with the latest libraries. Once these jobs are created, library update/upgrade would be a simple problem.
Obviously, this is an ideal situation. Most project in most company still does not have a unit test, let alone a smoke test or a validation test. Again it takes effort and support from management to really do this. But once it is done, the team can achieve a speedy development with fewer maintenance!!
