An equally valuable and closely related practice is to integrate early and often. While the build itself is a mechanism for integration, integration should also occur before and after the build. When all developers integrate their code changes prior to check in to the version control system, the build is less likely to fail because of an integration problem. When all developers synchronize their workspaces with the code included in the build, they will always be working with code that has compiled and been smoke tested.

Definitions

Before proceeding, it is important to define common terms related to builds and integration.

A build is the process of compiling source code into one or more executable files.

Integration is the process of combining code created by different software developers, each working in an isolated development environment, on a separate task.

An integration build is a regularly occurring build intended to integrate the code changes made by the developers who are working on the same software development project.

A workspace is the development environment that allows a developer to create or modify code without affecting or being affected by the changes made by other developers.

Check out is the act of copying source code from a version control system to a developer's workspace.

Check in is the act of committing code changes from a developer's workspace to a version control system.

A codeline is the sequence, over time, of the file versions that comprise the software application under development.

A branch is the point at which a line of development diverges from an existing codeline.

A merge is the point at which the changes made in one codeline are integrated into another codeline.

The tip revision is the most recent version of a file checked in to the version control system.

The branch revision is the tip revision of a file that has branched.

Motivation for Integration in a Team Environment

Today, most software development is a team activity. Team sizes can vary from as few as two developers to 100 or more developers. Development can occur in a single location, or at geographically distributed locations.

Team development is a common practice used to create software in the shortest amount of time possible. However, team development is effective only if the members of the team can work in a synchronized manner. To be synchronized, each member of the development team needs to integrate that developer's changes with the changes made by all other developers. Without integration, the changes made in isolation by each developer, are unlikely to work together.

Empirical evidence suggests that the longer a development team waits to integrate the changes made by its members, the more difficult it will be to integrate the changes. Infrequent integration is more difficult than

frequent integration because more changes, and more involved changes, need to be reconciled. Hence, the longer each developer proceeds along a divergent path, the more effort will be required to converge all the paths.

Since delayed integration can be both difficult and time consuming, it is important to integrate code changes early and often in a project's software development lifecyle. To integrate changes properly, it is essential to understand the different types of integration.

Types of Integration

Two types of integration occur on most software development projects: intra-codeline integration and intercodeline integration. The distinction between the two types depends on whether the integration occurs within a codeline or between two codelines.

Intra-codeline integration occurs when developers integrate changes made within a codeline. Integrating the code changes made by developers working on the same software release is an example of intra-codeline integration.

Inter-codeline integration occurs when developers integrate changes made in different codelines. Integrating the code changes made by developers working on one software release with the code changes made by developers working on a different software release is an example of inter-codeline integration. Inter-codeline integration occurs when an organization practices parallel software development, i.e., the organization develops two or more releases of the same software application at the same time. Each parallel release is developed in a separate codeline to keep the changes made for one release isolated from the changes made for other releases.

While integration occurs within a codeline and between two codelines, integration also occurs in a developer's workspace. Integration in a workspace occurs when a developer merges the tip revision of a file with the contents of the workspace. This type of integration is referred to as workspace update or workspace rebase.

Intra-codeline Integration

Below is an example of intra-codeline integration. The example illustrates how two developers, who are working on the same release of a software application, integrate their changes before and after each integration build.

In the example below, Developers A and B are working together to develop release 1 of the Acme software application. Notice how the two developers integrate their changes so that the tip revision of the file foo.java is kept current with the changes made by both developers. Also, notice how both developers integrate changes before and after each integration build.

1. Developer A begins work on task 1.
2. Developer A needs to modify the file foo.java to complete task 1.
3. Developer A checks out the tip revision of foo.java. The tip revision is version 1.0.
4. Developer B begins work on task 2.
5. Developer B needs to modify the file foo.java to complete task 2.
6. Developer B checks out the tip revision of foo.java. The tip revision is version 1.0.
7. Developer A completes task 1.
8. Developer A synchronizes the workspace with the version control system. There are no changes that need to be added to the workspace.
9. Developer A checks in foo.java. The version control system creates version 1.1 of foo.java. The tip revision becomes version 1.1.
10. Developer A initiates an integration build. Release 1 of the Acme software application builds using foo.java version 1.1.
11. Developer B completes task 2.
12. Developer B synchronizes the workspace with the version control system to obtain the changes included in the build. Developer B integrates foo.java version 1.1 with the changes in Developer B's workspace. Following the integration, Developer B's workspace contains the code changes made by Developers A and B.
13. Developer B checks in foo.java. The version control system detects that Developer B last checked out foo.java version 1.0. Since the tip revision of foo.java is now version 1.1, the version control system branches the file to create version 1.0.1.0.
14. Developer B ends the branch by merging version 1.0.1.0 of foo.java into the codeline. When Developer B completes the merge, the version control system creates version 1.2 of foo.java.
15. Developer B initiates an integration build. Release 1 of the Acme software application builds using foo.java version 1.2.

The diagram below shows the progression of foo.java during intra-codeline integration. Each arrow shows the sources of input into the resulting file version.

foo.java

1.0.1.0

Inter-codeline Integration

Below is an example of inter-codeline integration. The example illustrates how four developers, who are working on two different releases of a software application, integrate their changes. This example below extends the example of intra-codeline integration.

Developers A and B are working together to develop release 1 of the Acme software application. At the same time, Developers C and D are working together to develop release 2 of the Acme software application. Notice how the developers integrate their changes so that both the tip revision and branch revision of the file foo.java are kept current with the changes made by the developers. Since the branch revision is for a later release, it contains the changes from the tip revision. Since the tip revision is for the earlier release, it does not contain the changes from the branch revision.

1. Developers A and B completed tasks 1 and 2. They begin work on tasks 3 and 4 of release 1.
2. Developer A needs to modify foo.java to complete task 3.
3. Developer A checks out the tip revision of foo.java. The tip revision is version 1.2.
4. Developer C begins work on task 5. This task will be delivered with release 2 of the Acme software application.
5. Developer C needs to modify foo.java to complete task 5.
6. Developer C checks out the tip revision of foo.java. The tip revision is version 1.2.
7. Developer A completes task 3.
8. Developer A synchronizes the workspace with the version control system. There are no changes that need to be added to the workspace.
9. Developer A checks in foo.java. The version control system creates version 1.3 of foo.java. The tip revision becomes version 1.3.
10. Developer A initiates an integration build. Release 1 of the Acme software application builds using foo.java version 1.3.
11. Developer C completes task 5.
12. Developer C synchronizes the workspace with the version control system. The changes made by Developer C need to be integrated with the changes made by Developer A.
13. Developer C completes the integration.
14. Developer C checks in foo.java. The version control system detects that Developer C is not working the tip revision of the file. The version control system branches the file to create version 1.2.1.0.
15. Developer C observes that the tip revision of foo.java is now version 1.3 and the branch revision is now version 1.2.1.0.
16. Developer C integrates foo.java version 1.3 with foo.java version 1.2.1.0. Following the integration, Developer C's workspace contains the code changes made by Developers A and C.
17. Developer C checks in foo.java. The version control system creates version 1.2.1.1 of foo.java. The branch revision becomes version 1.2.1.1.
18. Developer C cannot end the branch because the code changes made to complete task 5 are for release 2 only. Developers C and D must continue to work in the branch so that the changes that they make for release 2 are not accidentally added to the code that will be deployed for release 1.
19. Developer C initiates an integration build. Release 2 of the Acme software application builds using the branch revision foo.java, which is version 1.2.1.1. This build contains the code changes made by Developers A and C.
20. Developer B needs to modify foo.java to complete task 4.
21. Developer B checks out the tip revision of foo.java. The tip revision is version 1.3.
22. Developer B synchronizes the workspace with the version control system. There are no changes that need to be added to the workspace.
23. Developer B checks in foo.java. The version control system creates version 1.4 of foo.java. The tip revision becomes version 1.4.
24. Developer B initiates an integration build. Release 1 of the Acme software application builds using foo.java version 1.4.
25. Developer D begins work on task 6. This task will be delivered with release 2 of the Acme software application.
26. Developer D needs to modify foo.java to complete task .
27. Developer D checks out the branch revision of foo.java. The branch revision is version 1.2.1.1.
28. Developer D will modify version 1.2.1.1 of foo.java then check in the changes. The version control system will create version 1.2.1.2 of foo.java. The branch revision becomes version 1.2.1.2.
29. Eventually, Developer D will need to integrate the changes made in the tip revision of foo.java, version 1.4, into the branch revision of foo.java.

The diagram below shows the progression of foo.java during intra-codeline integration and inter-codeline integration. Each arrow shows the sources of input into the resulting file version.

Conclusion

Integrating early and often in the development lifecycle is a smart practice. To integrate properly, it is necessary to understand the distinction between intra-codeline integration and inter-codeline integration. Not all projects will need to use both types of integration. Software development projects with many concurrent tasks in the same codeline will need to integrate within a codeline. Software development projects that practice parallel development will need to integration between codelines.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment