InnovationQ will be updated on Sunday, Jan. 21, from 9am - 11am ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Rapid validation of developer changes in a component based build

IP.com Disclosure Number: IPCOM000234083D
Publication Date: 2014-Jan-10
Document File: 4 page(s) / 127K

Publishing Venue

The IP.com Prior Art Database


Disclosed is method that enables developers to quickly verify whether changes to a small number of components in a software package will cause the entire build to break. Instead of running a full build of all the components, the method only requires building the changed components and those components that depend (directly or indirectly) on the changed components.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 4

Rapid validation of developer changes in a component based build

As software becomes more complex, component based builds become larger and more complex, and can take longer to run. Developers typically make small code changes in only one or two components to fix defects or add new functionality . A

method is needed that allows developers to verify that delivering those changes will

not break the build.

One approach is to verify that changes work in a development environment before delivering. This approach is common but is error prone because 1) sometimes build and development environments are different, 2) it does not take into account dependent components, and 3) it does not include verification scans that run only in the build (and might indicate problems).

Another approach is to run a personal build, which is a full build based on the

contents of the developer workspace. This is a thorough and effective approach, but requires developers to wait (sometimes hours) for a full build to complete even if only a minor change was made.

Disabling validation tests and scans and running a personal build is also an option . This is much faster than personal builds (since typically more time is spent doing validation than compiling and packaging), but it still can take some time, since everything must be built. In addition, because the validation tests and scans do not run, it is possible that delivering the change could still break the build.

The solution is to more quickly validate developer's changes by, instead of running a full build of all the components in a build, only building the changed components and those components that depend (directly or indirectly) on the changed components; other dependencies can be obtained from the latest production build . Validation

scans such as checking copyrights and scanning translatable content are only needed for the modified components and not the other components in the build .

Figure 1 is an acyclic graph showing the components and component dependencies of a sample "ABC" build. The build produces both a server and a client. The server and client provide pieces of functionality, "A", "B", and "C". Each function has a client-specific piece, as server-specific piece, and a common piece for both client and server. In addition, all of these client, server, and common components not only compile and package the code, but also perform various validations such as unit tests, copyright...