(Cat? OR feline) AND NOT dog?
Cat? W/5 behavior
(Cat? OR feline) AND traits
Cat AND charact*

This guide provides a more detailed description of the syntax that is supported along with examples.

This search box also supports the look-up of an IP.com Digital Signature (also referred to as Fingerprint); enter the 72-, 48-, or 32-character code to retrieve details of the associated file or submission.

Concept Search - What can I type?

For a concept search, you can enter phrases, sentences, or full paragraphs in English. For example, copy and paste the abstract of a patent application or paragraphs from an article.

Concept search eliminates the need for complex Boolean syntax to inform retrieval. Our Semantic Gist engine uses advanced cognitive semantic analysis to extract the meaning of data. This reduces the chances of missing valuable information, that may result from traditional keyword searching.

Rapid validation of developer changes in a component based build

Publishing Venue

The IP.com Prior Art Database

Abstract

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.

Country

Undisclosed

Language

English (United States)

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...