Today, team software development is routine. Software developers, working as part of a team, develop applications ranging from commercial packages to custom applications to web applications. Team software development is a reality because one person cannot develop today’s complex software applications in a timely manner.

One of the greatest challenges of team software development is integrating the changes made by several developers, each completing coding tasks in an isolated environment. Eventually, the developers must integrate their changes so that the code developed by many works as a single software application. Anyone who has worked on a software project of moderate size and complexity knows that frequent integration of small sets of changes is much smoother than infrequent integration of large sets of changes.

What is Incremental Integration?

Incremental integration is the frequent integration of small sets of code changes. The term typically describes the activity that takes place when a team of developers is working on one software release. The integration occurs among developers who are working in the same codeline. (A codeline is the progression, over time, of logical sets of source code file changes.) The developers are combining their changes in an integration environment to produce a build of the software application.

While incremental integration is important for team development of a release, it is even more critical for team development of multiple releases in parallel. The incremental integration that occurs in a parallel development environment is among the codelines that make up the releases. If teams develop each release in a separate codeline, the teams need to integrate the changes completed in one codeline with the code in another.

What is Parallel Development?

Parallel development means a team develops two or more releases of the same software application at the same time. Since each release shares a common code base it is likely that developers modify many of the same source code files for each release.

Parallel development is quickly becoming the norm because of the growing pressure to deliver software releases quicker and more frequently. The most common form of parallel development involves supporting a release in production while developing new functionality for the next release. Parallel development also involves developing two or more releases at the same time. Although the release dates may be staggered, the development phase for two or more releases overlaps.

What is the Challenge of Parallel Development?

Perhaps, the greatest challenge of parallel development is effectively merging the changes from one release to another. Without merging, a defect fixed in a production release would remain a defect in the next release to ship. Without merging, a new feature developed for the next release might not be included in the release after next.

Changes merge forward, not backward. This means a bug fix made to the production release merges to all future releases under development. Likewise, a feature added in the next release merges to all future releases under development.

Branching strategies for effective parallel development provide a means for the controlled merging of changes from one release to another. This controlled propagation means changes merge from one release to the next in small increments.

How does Incremental Integration Apply to Parallel Development?

As stated above, incremental integration in a parallel development environment involves the integration of changes among releases. In the same way that developers working on a release integrate changes from their individual workspaces to an integration codeline, a project team working on multiple releases integrates changes from one release codeline to another.

Task-based development is an ideal way to apply incremental integration to parallel development. When practicing task-based development, every development activity occurs in the context of a task. In other words, the task is the control mechanism that identifies and sequences development activities.

Although tasks typically identify and sequence the work in a single release, they can also track the changes that must merge from one release to another. For example, a project manager could create a task to identify a defect fix in the production release. The project manager could add this task to the next release. By adding the task to the next release, the task acts as a sticky note. It reminds developers working on the next release that they need to merge the defect fix into the next release.

How is Task-Based Development Implemented?

The easiest way to implement task-based development is to use a software configuration management (SCM) tool that offers built-in support for tasks. These tools allow project team members to create tasks to track both new development activities and defect fixes. Additionally, these tools provide for an association between file revisions and tasks. This association occurs at the time of check-in. For development teams that follow the task level commit pattern, identified by Steve Berczuk and Brad Appleton, each check-in satisfies one fine-grained, consistent task.

In addition to tracking changes made in one release, tasks can be use to track the propagation of changes from one release to another. In this way, tasks ensure that merges are identified and scheduled. Any unfinished merge tasks in the SCM tool mean a release cannot be completed until the merge tasks are completed.

What Support Exists for Tasks?

The table below identifies the task feature in several popular SCM tools. This table was populated primarily with the information from Appendix B of Software Configuration Management Patterns: Effective Teamwork,

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment