Coverity Build Analysis provides build managers and release managers with visibility into the software build, its file structure, and its interdependencies to identify build bottlenecks or inefficiencies, understand the build structure and file relationships to assess the impact of making a change to the build, and enforce standards by flagging build policy violations that could introduce quality and security issues.
“Coverity Build Analysis uncovered errors in our build that we wouldn’t have found otherwise.”- Reid Madsen Principal Engineer, Tektronix
Brittle and unstable builds cost organizations countless hours of developer and QA productivity. Coverity Build Analysis provides visibility into the build so you can better understand and optimize the composition of each individual build. This means faster build times for your software, and faster time to market for your products. Coverity Build Analysis helps determine the root cause of slow or failed builds by answering the following questions:
Today’s large, complex code bases are especially susceptible to the hazards of constant change. A minor fix injected into any one code component can have major ramifications to the entire code base.
Coverity Build Analysis provides visibility to reduce the risk of a build change by creating a visual dependency map of all files and processes that are executed during the build along with their interrelationships and dependencies, including the files that are affected by a specific file and why, the files that affect a specific file and why, and the libraries and objects that are integrated into a file. This increases developer efficiency by automating change impact analysis on the build’s dependent libraries and executables, as well as identifying the exact components that the executables are built from.
Development teams must often adhere to strict rules for verification and validation of their code, whether it’s internal standards or external regulations, requiring proof that all the code in a delivered application is the code that was actually tested. A Source Code Management (SCM) system can produce an auditable list of files that comprise a build, but how can teams show that the files that have been checked out are actually the files contained in a specific build? Or that the list itself is complete for a specific build?
Coverity Build Analysis helps to enforce internal and external standards by providing an audit trail to verify the build, and all of the files which comprise the build, have been tested. Coverity Build Analysis can also be used to set rules to ensure proper compilation, enforce inclusion or exclusion of directories and libraries that should not be in the build, and flag any violations to established build rules and processes.
