Browse Prior Art Database

Predictive caching for continuous integration Disclosure Number: IPCOM000242210D
Publication Date: 2015-Jun-26
Document File: 6 page(s) / 84K

Publishing Venue

The Prior Art Database


Disclosed is a system to improve the processes within multi-team continuous integration in the context of teams building software, or any interdependent teams that practice continuous integration. With this solution, a client build team continuously runs a process to carry out the initial tasks of said team’s build; specifically, the tasks based solely on the build's suppliers.

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

Page 01 of 6

Predictive caching for continuous integration

Large-scale continuous integration efforts comprise many interdependent teams . The results of one team's efforts provide part of the input to another team's efforts. For example, in the smallest such case, team A produces a result that team B uses. In this sense, team B depends on team A. For software development teams, such dependencies are manifested by the teams' builds. That is, the build of team A produces a set of files that team B then uses as input for a build . Similarly, the build of team C may depend on the results of the builds of both team A and team B . Team B directly depends on team A. Because the build of team C uses team A's build result as input, team C also directly depends on team A. However, because team C also directly depends on team B, which depends on team A, team C also indirectly depends on team A.

Team A supplies input to teams B and C; therefore, team A is referred to as a supplier of teams B and C. Conversely, teams B and C are clients of team A.

Build results have unique, totally ordered version numbers. Each team's build team produces a result that has a version number. The version number must be unique to distinguish it from other build results. In addition, the new development depends on being able to determine the most recent build. Thus, the version numbers must be totally ordered as opposed to an unordered version number, such as a hash code. Such version numbers are typically based on the time and date of the build, but this is not necessarily the case. For purposes of this disclosure, assume that teams A, B, and C each have version numbers that are based on integers that increase sequentially starting from number one (1). Thus, for example, team A has builds A1, A2, A3, etc.

Teams have independent build schedules. Although the teams depend on each other, the associated build schedules may be independent. Team A may produce builds team B does not adopt. Alternatively, team B might have more than one build that uses the same version of team A's build results.

Some changes require changes in clients. Each team is constantly making changes that potentially affect the clients. For example, team A may modify an interface in a manner that requires changes by team B . The process of a client making such changes is called adoption.

To practice continuous integration, each team's build uses the most recent successful supplier versions of the builds on which it directly depends. For example, when team B runs a build, it uses the most recent version of team A's build.

In addition, supplier versions must be aligned. The teams' development, build, and adoption schedules may not be coordinated.


Page 02 of 6

When team C adopts a new build from team B , however, it must adopt the matching version of team A's build. This is due to the possibility of changes in team A that might require changes in teams B and C to adopt. Such an adoption may be impossible if th...