Managing parallel development with Rational Team Concert

A strategy for software integration and release

By using streams for stages of development, IBM® Rational Team Concert™ can provide a complete parallel development and release structure for a software development team. This article covers the delivery of units of work from one stream to another and the management of releases and emergency fixes, as well as how to control who can deliver changes to specific streams. It will help you if you are new to Rational Team Concert or want to improve your approach to parallel development.

Mark Roberts (markroberts@uk.ibm.com), Technical Consultant, IBM

Author1 photoMark has more than 20 years experience in software development and management of IT systems and configuration management environments. He has written software in Fortran, C, assembler, Java, and PERL and has extensive experience in deployment of IBM Rational ClearCase, Rational ClearQuest, and Rational Team Concert. Currently, Mark is a member of the UK Technical Professionals team that focuses on helping customers improve the configuration and change management aspects of their development process.



30 August 2011

Also available in Russian

Orientation to terms and concepts in this article

When developing in a collaborative team environment, it is often necessary to segregate different development activities into separate streams of work. This might be feature-based (for example, a set of security enhancements isolated from graphical user interface changes) or it might be a set of defects that need to be isolated from new development work so that a defect patch release can be quickly delivered to customers. There are many reasons for creating such a separation of work, and in many version management systems, this is delivered using a series of parallel branches.

In IBM® Rational Team Concert™ parallel development is supported by the use of several different streams. Work completed by developers flows to a specific stream and is integrated with the work of other developers who are working on the same stream. By using multiple streams, the efforts of different sub-teams of developers are separated until a specific activity is performed to integrate the work from multiple streams.

Simply put, streams enable the team to automatically integrate the work of those who are working in a highly collaborative way with the work of others when the time is right.

The purpose of this article is to define a process for parallel development using Rational Team Concert features through describing a scenario and the steps to create that scenario. The pattern shown includes many facets of development that typical teams require, but the process can be modified to support the specific requirements of any organization and any development process.

Is it "agile"?

One of the key principles of agile development is the frequent integration of the changes produced by each developer and the continual build of newly integrated application code. As a result some agile purists may consider a formally segregated process to be outside the scope of agile development. However the scale of some development efforts means that a single co-located team may not be possible. Additionally, the scale and complexity of change may be truly daunting resulting in the need for segregation. The principles of IBM® agility@scale™ encourage the partitioning of the team and, hence, assigning the work to different teams.

As a result of the physical segregation of teams or the sheer complexity of the undertaking, it might make sense to introduce a degree of separation and controlled integration into an agile development team. This could manifest itself in a stream according to location or a stream for a specific release. Rational Team Concert can support agile teams as they break down the work to be done into, for example, a series of feature streams that are integrated by using a shared Integration stream.

It is true that many agile teams use freeware or low-cost development tools that offer limited support for segregated development. Such tools often put developers off of a segregated approach due to functional limitations and the high overhead of integration within such tools. Rational Team Concert is a mechanism for many agile teams to raise their game and take their development capability to the next level in terms of efficiency, flexibility, and the creativity that can be engineered into their development processes.

Rational Team Concert can support development efforts from small co-located agile teams to large distributed teams that comprise many smaller sub-units of agile development activity. Some of the key characteristics of agile teams and the Disciplined Agile Delivery approach are described by Scott Ambler in his blog post (see the Resources section).

Evolutionary
"Agile strategies are both iterative and incremental in nature," says Ambler. Stream structure must be allowed to evolve to support the current needs of the project. Having a team that understands streams, integration and build processes will ensure that the software configuration management tool can support the activities of the team at any point in time. The entire parallel development structure of the project does not necessarily have to be designed before the project starts to write code, but some principles should be understood by all. These should include the management of cross-stream integration, the control of Release streams and security and the management of work that is not completed during a sprint and is left "pending" in a stream or workspace.
 
Highly collaborative
The mechanisms used to share work and maintain high visibility of developer activity can turn an average agile team into a high efficiency agile team. Educating users in the mechanisms of sharing content and gathering an understanding what other developers are doing is key to avoiding wasted time and ineffectual development.
 
Self-organization within an appropriate governance framework
Configuration management is an area where many process documents have been written (including by this author) but few are ever read. Having the right level of governance framework is a key to getting developers to see value from the things we ask them to do specific to the configuration management area. Setting a process framework that enables teams to understand what they need to provide in order to release an application into production, but leaving them to their own process for how they get there is a great way to enable teams to be creative and self organized. Such self-organized teams will often gravitate to the most appropriate approach for them based on the type of development they are doing, the skills of the team and the automation technology available. See the link in Resources for further information on process templates and automation frameworks.
 

An introduction to Rational Team Concert

It is assumed that the reader has a basic understanding of Rational Team Concert and software configuration management principles in general. Further information on Rational Team Concert and other closely associated products can be found on the web site at Jazz.net. To support the reader of this article a number of key product concepts and terms for parallel development are included in this section.

Stream
The stream is similar in concept to a branch in most other version control systems. However, there are some significant differences that enable specific operations when using Rational Team Concert. Streams serve as a collection point for changes that can then be delivered to other streams. In the scenarios presented here, streams are used to collect changes into a logical unit that is then delivered to another stream to manage a release. Many parallel development structures within other version management systems become very difficult to use after a while due to the number of branches that exist. After work on a Rational Team Concert stream is finished, the stream can be removed, because all content will have been moved to another location. In this manner, streams can be considered to be either a temporary structure for doing work or a more permanent structure for the preserving and recording work.
 
Change set
When changes are made to files under version control within Rational Team Concert, they need to be managed and tracked. Some version control systems do this on a file-by-file basis, and content is merged from branch to branch, file by file. This often leads to mistakes, forgotten content or mismerged files that can result in broken builds or partially completed work. Developers have a natural process of grouping file changes together into sets that logically form a complete unit of work. This grouping task is performed as part of the check-in process of Rational Team Concert, in which a change set is created and managed. In most scenarios, a change set is then associated with a work item, such as a task, defect, or story. This enables the context of the change set to be visible, and it allows team members to view the changes performed to satisfy the requirements of the work item.
 
Baseline
At specific intervals during a development project, it is necessary to metaphorically draw a line in the sand and identify the file content that collectively forms a stable, releasable unit of software (or other unit of useful work held within the version management system). The identification point used within Rational Team Concert is the baseline. Applying a baseline identifies the files present, as well as their specific versioned content, at the time that the baseline is applied. Baselines can then be used as a reference point later to gain access to a specific configuration of files. Baselines can be compared to show the differences that exist and, thus, the developer activity, between two marked points in time.

In many version control systems, baseline comparison will show the differences as a list of files that have changed between the two points. Rational Team Concert can present the information in this way, and this method does have some value. But many people working on a development project need to see what actual changes have taken place at a higher level of abstraction. If change sets are associated with work items, as previously described, then a list of completed work items can be used to represent the differences between two baselines. Details of, for example, 35 defects and 12 stories that have been completed during the last iteration can often communicate a lot more about what has happened that a list of 728 files that have changed in the same interval.
 
Delivery
The term delivery refers to the transfer of file changes from a developer's isolated workspace to the stream that is currently associated with the workspace. The result of a deliver operation, or delivery, is that new files or new versions of file will be stored within the stream and will be available for other developers associated with the stream. Those other developers will be informed by Rational Team Concert of the presence of new content, and they can choose the appropriate time to accept the changes. Users can switch which streams they want to deliver code to (as described later), and project administrators can control who is allowed to deliver content to specific streams.
The delivery process is similar to a merge from one branch to another within other version management systems. One of the key advantages of Rational Team Concert is that it enables developers to deliver work items that include the change sets associated with the work items. Therefore, although the baseline comparisons mentioned previously can report at the work item level, so can the actual developer deliver operations.
 
User workspaces
Each user has a repository workspace that is connected to the stream into which they will deliver their work. When a user makes a change to a file, the edited copy is held in a client-side sandbox associated with the repository workspace. When the user has completed the changes, the file is checked in and copied from the client to a server-based area of the repository. The file is collected into a change set among other files that the user has also changed. When the change set is complete, the user delivers it to the stream.
 

Parallel development streams

Even when users are working on the same stream (such as Feature Stream 1, shown in Figure 1) there is still a degree of separation between the users and a controlled integration of changes as they deliver and accept changes, as shown in Figure 3.

Figure 1. Stream check-in and delivery
Client-to-server flow of check-in and delivery

Feature streams

The starting point of this scenario is a team that wants to split the work that they do into two additional streams for the purposes of isolating their activities. This is illustrated in Figure 2.

Figure 2. Simple feature stream structure
Flow diagram that shows the process

Figure 2 shows the Main Development stream into which a number of change sets have been delivered by developers. For example, a change set has been delivered before #1, and another has been delivered between #1 and #2 in the diagram. If no other streams are created within the project, then all change sets delivered by the team are integrated on the single shared stream. However, the development team working on this project has decided that some changes need to be done in isolation by several developers on the team. Feature Stream 1 has been created after a period of time working on the project. After more time has elapsed, Feature Stream 2 is created.

Some of the work is then done on the Main Development stream, and some is done on the Feature streams. For simplicity, only a small number of change sets are shown on the diagrams, but in reality, many change sets are likely to be delivered to each of the streams as multiple developers perform their work. After work has been done on Feature Stream 1, the team decides that it should be integrated with the Main Development Stream at point #2. The specific process for this integration of work from one stream to another is described later in this article. From the point of delivery, Feature Stream 2 is created and work continues on three separate parallel streams. When points #3 and #4 are reached, the work done on both feature streams is delivered to the Main Development stream, and a baseline is created at #5 for a release. After the final deliveries from the feature streams, the streams are removed.

Adding a shared Integration and Release stream

Building on the scenario from the previous section, as shown in Figure 2, an additional stream is now added to the scenario to provide a separate Integration and Release streams. Figure 3 shows the new scenario, which is explained in the text that follows.

Figure 3. Feature streams with a shared Integration and Release stream
Integration and Release stream added

The scenario of change set creation, baseline creation, and the integration of work from one stream to another follows the pattern described in the section on Feature streams, with a number of small changes. The Integration and Release stream will be used to formally integrate and system-test the application prior to a release.

  1. A baseline is shown at #3 in the Main Development stream, which is delivered to the Integration stream at #4.
  2. The integrated application can then be tested before a release from baseline #5 in the Integration and Release stream.
  3. Further development work then takes place on the Feature streams up to points #6 and #7, which are then delivered to the Main Development stream at #8.
  4. Feature stream 2 is then closed and removed.
  5. Further work takes place on the Main Development stream up to point #9, where a new baseline is created and delivered to the Integration and Release stream.
  6. A new baseline is then created on the shared Integration and Release stream at #10 to manage the release to production.

Splitting the Integration and Release stream

Over time, teams often find that it is useful to split the Integration and Release stream into separate entities for these reasons:

  • Splitting the Release stream away from development allows the team to increase the security of the Release stream by controlling which roles are allowed to deliver to it. See the section on security later in this article (Controlling deliveries to streams).
  • Modifications required for the code to integrate can be made to the Integration stream without compromising the integrity of the separate release stream.
  • Changes required for live system support can be isolated from main development, thus allowing such changes (generally to configuration files) to be made without impacting main development. However, there should be a route to capture such changes and feed them back to the Main Development stream. If the release stream is not isolated, then such changes might need to be done alongside partially integrated code that is not yet complete or ready for production. This could cause complications in production or delay the emergency fix that is required to be done to the live system.

Figure 4 shows the introduction of a Release stream and a separate Emergency Fix stream to capture live system changes. The process of capturing such emergency changes and feeding those back into development is described in the section that follows.

Figure 4. Separate Integration, Release, and Emergency Fix streams
Addition of Release and Emergency Fix streams

The application code at baseline #5 has been selected to be released to production, so a new Release stream hierarchy has been created to manage the release and any emergency patch work as described below:

  1. A new release baseline has been created at #6 and, from that, an Emergency Fix stream has been created (which might or might not actually be used).
  2. At point #7 an emergency change has been performed which is delivered to the Release stream at #8. Most organizations have strict rules about the type and volume of changes that are allowed to be performed on an "emergency fix" basis. Many organizations that do allow emergency fixes also have a headache ensuring that such changes flow back to the development team.
  3. A delivery of the code is made from the Emergency Fix stream to the Main Development stream, at #11, to ensure that the developers have this change to incorporate into the next formal release of the application. From the Main Development stream it may also be necessary to deliver the emergency fix content to either Feature Stream 1 or Feature Stream 2 (or to both), but this has not been shown on the diagram.
  4. While the release process was taking place the work done on the feature streams has been delivered to the Main Development stream at #9 and #10.
  5. Further work takes place on the Main Development stream up to the interim baseline #12, which is then delivered, to the Integration stream where an Integration stream baseline is created at #13 ready for the next release.
  6. The creation of a Release stream and Emergency Fix stream to manage this release is shown in Figure 5.
Figure 5. Creation of a second Release stream structure
Addition of a second Release and Emergency Fix stream

In Figure 5, a further cycle of Release stream creation, Emergency Fix stream creation, and emergency fix work has taken place, involving several fixes. The final activity shown on the diagram is the delivery of the emergency fixes back to the Main Development stream.

A new Release and Emergency Fix stream is created for each major release, because it might be necessary to continue the fix-and-release process on the first Release stream to provide a second fix-release baseline after the one identified as #7. When a release is no longer to be maintained, the Release and Emergency Fix streams can possibly be deleted.

The final flow relationship diagram in this section shows how streams can come and go during development. Figure 6 shows that the development process has moved on, Feature Streams 1 and 2 have been completed, all work has been delivered, and the streams have been deleted. Feature Stream 3 has been created for further development activity. The release associated with baseline #8 has also been completed and, although the Release stream is preserved, the Emergency Fix stream can safely be removed.

Figure 6. Further development activity
Further development work with supporting streams

Of course, there are many ways that the work of a development team can be partitioned and subdivided. Integration and release processes for each organization will vary considerably, but the example developed in this article shows principles that any organization can adopt or adapt. Teams can take the contents of this article and implement them in a manner that suits them. We expect them to vary from organization to organization.

The order of creation and removal of the streams indicates the style of development of the teams. As Figure 7 shows the project begins with a single stream for development and progressively gets more complex as the project progresses through the iterations. By removing streams as they are no longer needed the structure can be kept as simple as possible. Screen images later in the document show how Rational Team Concert can generate a pictorial representation of the streams, repository workspaces, and their relationships.

Figure 7. Stream activity over the project lifetime
Stream creation and removal during iterations

Creating the stream structure

A new project

When a new project is created in Rational Team Concert it has a single stream containing a default component. Further components can be created as necessary but for the purposes of this document a single component will be used. Figure 8 shows the stream and user repository structure for a new project that has just one developer repository workspace.

Figure 8. Initial project stream and repository structure
The start of the stream creation process in RTC

It is possible to visualize the stream and any connected workspaces by using a flow diagram, as shown on the right in Figure 8. Users can see the hierarchical nature of the streams and user repository workspaces, and you can show streams connected to other streams. It must be remembered that Rational Team Concert is inherently flat in structure, and any workspace can deliver to any stream, as long as the role-based permissions allow it. (Permissions are covered in the last section of this article.)

To communicate the required flow of changes, project teams should use documentation, such as the diagrams in Figures 2 to 6. This will help individual developers understand where their changes should flow to and who is responsible for the delivery of work to specific streams. Such documentation should be updated frequently so that the team members each have a good understanding of their responsibilities as the structure of the streams evolves.

More users join the project

New users who join the project can get access to the files under source control by creating a new repository workspace. Simply selecting the My Repository Workspaces item shown in Figure 8 and then selecting New, and then Repository Workspace will do this. A selection dialog window is then displayed, as shown in Figure 9, so you can select the stream to which changes will be delivered ("flowed"). The total number of streams for a project is typically small, so if the streams are given reasonably descriptive names, it is easy to select the right stream to use.

Figure 9. Selecting the stream to which changes will flow
The list of streams that can be selected

The flow diagram after the creation of the second stream is shown in Figure 10. Notice that flow diagrams can be created from a menu item that is displayed when you right-clicks on either the stream or the repository workspace on the left side of the screen shown in Figure 8.

Figure 10. Multiple users connected to the same stream
Two users connected to the same stream

Creating new streams

A note on stream-to-stream flows

The flow relationship between streams does not indicate a direct flow of file content from one stream to another. There is no action within Rational Team Concert to make this happen. The exact mechanism for the flow of changes from one stream to another is that the changes go through a repository workspace. This process is described in detailed in a later section here.

However, the creation of indicative flow relationships between streams shows to the development team the intention that changes collected in one stream will ultimately be delivered to another stream as a part of the development process. To create the indicative flow relationship between streams, it is necessary to open the detail of the source stream, as shown in Figure 11.

There are several ways to create new streams. One of the easiest is to use a flow diagram to pictorially display the relationship between streams and repository workspaces.

Right-clicking on a stream displays a menu with various functions and options:

  • Create a new repository workspace
  • Create a new stream
  • Refresh the diagram with the information held within the repository database
  • Compare the state of the stream with the current state of any of these:
    • Another stream
    • A specific workspace
    • A specific snapshot taken of the stream

When the option to create a new stream is selected, you are asked to provide a name for the stream and a team area within the project to own the stream. If no team areas exist within the project, then the project name is displayed instead.

In the scenario in Figure 2, the first stream to be created will be "Feature Stream 1." Immediately after the stream is created, it has the same content as the stream from which it was created. Additionally, the new stream has no flow relationship to any other streams, and it has no associated workspaces.

A note on Stream to Stream Flows

The flow relationship between streams does not necessarily indicate a direct flow of file content from one stream to another. As the stream structure evolves, as shown through the following pages, it can be advantageous to create a flow relationship between streams to show the intention to collect changes in one stream and then move some or all of the changes to the next stream. The two ways to make that flow of content from one stream to another happen are described in detailed in a later section.

To create the flow relationship between streams, it is necessary to open the detail of the source stream, as shown in Figure 11.

Figure 11. Source stream details
The details of a new stream

Larger view of Figure 11.

The information dialog for the stream allows these functions to be performed:

  • Creation of new components
  • Adding or updating reference components from other projects (at specific baselines)
  • The addition and removal of flow targets

A new flow target is added to Feature Stream 1 to indicate the flow of changes to the Main Development Stream. This is shown in Figure 12 for the configuration of the stream.

Figure 12. Stream configuration showing indicative flow of changes
Default and Current Flow targets for a stream

The updated flow diagram is shown in Figure 13, which also shows three developers who are currently working on the Main Development stream.

Figure 13. Flow diagram showing streams and repository workspaces
A feature stream and users connected to a stream

The addition of Feature Stream 2 to the scenario, as shown in Figure 14, completes the scenario indicated by the diagram in Figure 2.

Figure 14. Two Feature streams and the Main Development stream
Addition of a Feature stream to a flow diagram

Completion of new stream creation

To complete the stream structure shown in Figure 4, which includes a realistic integration, release and production hot-fix stream structure, new streams are created, and flow target relationships are established using the mechanism described previously. The results are shown in Figure 15.

Figure 15. Development, Integration, and Release streams
The hierarchy of streams and the indicative flow

The left side of Figure 15 shows the development activities of the team, in which two developers (Mark and Simon) are working on the Main Development stream and Adrian is working on Feature Stream 1 (having previously been configured to work on the Main Development stream, Adrian is now working on specific features on the separate stream). Mark and Simon are integrating their work through the delivery of change sets to the Main Development stream and by subsequently accepting change sets from the Main Development stream. The diagram has been simplified in terms of the number of users working on each stream. It is expected that Adrian and other developers will collaborate on the Feature Stream 1 and other developers will collaborate on Feature Stream 2.

To the right of the Main Development stream is the stream structure to support the release and emergency fix process. The Integration stream is used for the gradual (and controlled) integration of development changes. After a suitable baseline has been created on the Integration stream, the current state of the Integration stream (change sets and baselines) is delivered to the Release stream 1.0. A version specific Release stream is created, as shown schematically in Figure 4 and also shown on the flow diagram in Figure 15. This is to allow multiple Release streams to be maintained to support the scenario in which multiple releases are in production use at the same time. Such releases may need emergency fixes to be applied to them. In the example in Figure 16, the first release to be created has an emergency change set applied at baseline #8. It is possible that customers who have that release of the application may need additional emergency bug fixes after baseline #8 but they may not be in a position to take on the latest main release of the application shown on the second Release stream. As a result maintaining the ability to apply fixes to the release created at baseline #6 is important.

Figure 16. Details of the release and Emergency Fix streams
Emergency fix changes flow to the Release stream

The Emergency Fix stream, shown as "Release Stream 1.0 – E-Fix" on Figure 15, is to be used for emergency changes that must be applied to production use as soon as possible. Such changes are not expected to involve source code and recompilation, but in many cases apply to configuration files and settings that need an immediate update. These are still captured on an isolated stream ensuring that Release streams are not used for any development activity. Emergency fix changes are also likely to be needed on the Development stream too so that the changes flow naturally through to the next release. Figure 4 shows the change set identified as #7 being delivered to the Release stream and the Main Development stream at #11.


Connecting users to streams

In a parallel development scenario users need to do two main tasks as part of the configuration management aspects of their development activities:

  • Create workspaces that provide a degree of isolation from other users and that are connected to specific streams of the parallel development work.
  • Deliver their changes to appropriate streams. At times during development it will be necessary for a developer to switch the flow target of their workspace as activities change during the development process.

The creation of new workspaces was described in a previous section. The connection of a workspace to different streams for the delivery of work is described in the following section.

Changing the target stream for delivery

In the scenario shown in Figure 2 a developer has made a change on Feature Stream 1. This change set may contain multiple files and, in accordance with the process of the Rational Team Concert project policies, it will either have a description associated with the change set or a work-item associated with the change set. The changes to file content were performed on a local hard disk of the developer in question and the changes were then checked-in to the server side repository workspace and collected into the change set, as shown in Figure 3. The changes are then delivered to a specific stream. In the scenario shown in Figure 15, the users Mark and Simon deliver their changes to the Main Development stream, but Adrian delivers his changes to Feature Stream 1. The target stream for a delivery operation is a characteristic of the developers' repository workspace as shown in Figure 17 for the user Mark.

Figure 17. Repository workspace properties
Default and current repository workspace targets

The repository workspace information section displays a number of items of useful information. Relevant to the current topic it includes the flow target for the repository that indicates to which stream deliveries of change sets will be sent. In order to change the flow target select Add (within the flow target section of the screen), and then select the required stream. If the user named Mark wants to deliver change sets to the Feature Stream 2 rather than the Main Development stream, the flow targets section would show as displayed in Figure 18.

Figure 18. Alternative flow target added (but not selected)
Addition of a new flow target to a workspace

At the point of adding the new flow target, there are actually no changes to how change sets will be delivered. To change the actual delivery target, the new target stream must be set as the current target by using the buttons on the right side to result in the workspace state, as shown in Figure 19.

Figure 19. Alternative flow target added (and selected as current)
The selection of a new current flow target

The position shown in Figure 19 indicates that the default flow target for the specific repository workspace is the Main Development stream but at the present time the current delivery target is selected to be the Feature Stream 2.

This position is reflected in the flow diagram shown in Figure 20. The current flow target is shown with a solid line, and the default flow target is shown with a dotted line.

Figure 20. Flow diagram after setting a new current flow target
A change of flow target for a user

The Pending Changes view also shows useful information regarding the flow targets. Any non-default targets are shown in italics on the top line of the Pending Changes information, as shown in Figure 21.

Figure 21. Pending changes view: non-default flow target selected
Pending changes with none default flow target

As a new delivery starts the user is warned that they are delivering to a non-default target with the warning shown in Figure 22, so the user may wish to check that the delivery is going to the right place.

Figure 22. None default flow delivery warning message
Warning of the none default delivery of changes

The above warning can be removed if the user has completely switched to the stream into which they wish to deliver change sets by switching both the current and default flow targets to the new stream. In this case, the target stream will no longer be displayed in italics as shown in Figure 21.

Changing the flow target from the Pending Changes view

It is also possible to change the flow target of a repository workspace using the Pending Changes view. By right clicking on the name of the repository workspace and then selecting Change Flow Target it is possible to select a new flow target stream.


The Integrator role

There are two ways that work can progress from one stream to another. The first way is to use the repository workspace of a specific integration user, and the second is to deliver from one stream directly to another. The tasks are broadly described as an integrator role. Teams might want to create a specific user role, with appropriate permissions, for the person or small team assigned to this task.

Integration through a repository workspace

The arrows that connect the streams in the flow diagrams in Figures 13, 14, 15, and 20 might be present merely to indicate the intention that work will flow from one stream to another. The actions described in the following section are performed when the integration activity is performed through a repository workspace. As indicated by Figure 4, the changes will flow from stream to stream in the following order (for example):

Feature Stream 1 > Main Development stream > Integration stream > Release stream

The following operations are required to flow change sets from stream to stream:

  1. Set the current flow target of a repository workspace to the source stream.
  2. Accept any incoming changes from the source stream to the repository workspace.
  3. Change the flow target of the repository workspace to the target stream.
  4. Deliver the outgoing changes.

Tips:
It is very useful to perform these steps in a clean integration workspace. Otherwise, the delivery operation at Step 4 could include changes made locally by the developer who is performing the integration operation, rather than just the set of changes that have been collected on the source stream. Also, ensure that there are no outgoing changes listed in the Pending Changes view of the repository workspace before performing the Accept operation in Step 2.

The example that follows shows the steps to flow changes from Feature Stream 1 to the Main Development stream via the workspace owned by the user named Mark.

Collect changes from Feature Stream 1

Set the current flow target of the repository workspace (Mark's workspace) to Feature Stream 1, as shown in Figure 23. The Pending Changes view for the repository workspace then shows incoming changes for the work done on Feature Stream 1 by the user Adrian, as shown in Figure 24. The changes need to be accepted into the repository workspace by the Integrator (Mark).

Figure 23. Repository workspace connected to Feature Stream 1
Collecting changes from a Feature stream
Figure 24. Accepting changes from Feature Stream 1
Pending incoming changes from a Feature stream

Deliver changes to Main Development stream

Set the current flow target of the repository workspace to the Main Development stream, as shown in Figure 25. The Pending Changes view for the repository workspace then shows outgoing changes for the work that is now in the repository workspace, as shown in Figure 26. The changes need to be delivered from the repository workspace by the Integrator, Mark.

Figure 25. Repository workspace connected to the Main Development stream
Delivering changes to a target stream
Figure 26. Deliver changes to Main Development stream
Pending outgoing changes to the target stream

You can use this process outlined to collect changes from any stream and then flow those changes to any other stream. However, a degree of control is required to manage who is allowed to deliver changes to specific streams (such as the Release stream). The following section describes how to control access to streams.

Integration with stream-to-stream delivery

It is possible to deliver changes directly from one stream to another by following the stream flow hierarchy. To do this, the stream flow targets must be set correctly, as described previously in this article. The person who performs the stream-to-stream delivery does not need to change the target of the repository workspace. In fact, that user does not even need to have a repository workspace.

Figure 27 shows the starting point for the delivery of changes from Feature Stream 1 to the Main Development Stream.

Figure 27. Stream-to-stream delivery starting point
Stream with default flow target of another stream

To initiate the stream delivery process, it is necessary to identify the changes pending in a specific stream that are relevant to the default target stream. In the example in Figure 27, this means identifying the pending changes in Feature Stream 1 that are not currently present in the Main Development stream.

To do this, right-click Feature Stream in the Source Control area of the project structure within the Team Artifacts view, as shown in Figure 28, and then click Show and then Pending Changes on the drop-down menus.

Figure 28. Selection of pending changes for a source stream
Selections under Source Control and then on menus

The Pending Changes view (see Figure 29) shows the changes that exist in the source stream but not in the target.

Figure 29. Changes pending for a stream-to-stream delivery
List of change sets to send from source to target

You can then finish the delivery in the normal manner.

Stream-to-stream delivery conflicts

A merge conflict might result during a stream-to-stream delivery. For example, in the scenario that Figure 27 shows, developers who are connected to the feature stream and the main development stream could make a conflicting code or structure change. When this happens, the Pending Changes view for the stream-to-stream delivery will be as shown as in the example in Figure 30.

Figure 30. Stream-to-stream delivery conflict
Incoming and outgoing change conflict

When this situation arises, the solution is to resort to using a repository workspace to overcome the merge issue, as shown in Figure 31, where the repository workspace for the main development stream has been temporarily redirected to the feature stream.

Figure 31. Using a repository workspace to resolve a merge conflict
Pending Changes view

The incoming change from the feature stream can be accepted and the merge resolved, and then the result can be delivered back to the feature stream. This will allow the feature stream to main development stream delivery to finish.

For the reasons shown below, stream-to-stream delivery is particularly useful in the progression of work from one stream to another along a series of project phases. For example, Figure 20 shows the progression from the main development stream to the integration stream to the release 1.0 stream and, finally, to the release stream 1.0 E-Fix. Such progressions of stream-to-stream deliveries establish a structure that is then used for further project maintenance. In the areas of work covering the main development stream and the interaction with changes that involve the feature streams, the use of an integration workspace is better for simplicity.


Controlling deliveries to streams

You can use that Process Configuration area of the project to specify which project roles are allowed to deliver changes to specific streams for a specific component. You can find the appropriate area of the configuration by following these instructions within the Eclipse interface of Rational Team Concert:

  1. Select Project Area information.
  2. Select the Process Configuration tab.
  3. Select Team Configuration > Operational Behavior.
  4. Select Source control (Deliver Server).
  5. Select the Everyone (default) column heading.
  6. Check the box for "Preconditions and follow up actions are configured for this operation."
  7. Select Add, and choose the precondition called Restrict Change set delivery to components in a particular stream.

Note:
You can do this in the web interface, too.

Figure 32 shows the result.

Tip:
You can do this using the web interface, rather than the Eclipse one, if you prefer.

Figure 32. Process configuration for delivery control
Operational behavior control for change delivery

Larger view of Figure 32.

On a stream-by-stream basis, it is then possible to control which roles have the permission to deliver change sets, as shown in Figure 33 (which is actually the bottom section of Figure 32 made a little larger for readability).

Figure 33. Role-based permission control for delivery of changes
Details of role-based delivery control

By selecting a specific stream, such as Release Stream 1.0, it is then possible to click Edit Permissions button to control which roles are allowed to deliver to the stream. Figure 33 shows that a new role called Release Stream Integrators has been created, and only members of that stream are able to deliver to the Release Stream.


Summary

Rational Team Concert offers a highly collaborative environment for the reality of today's software development projects. Most teams need to support multiple threads of development and to share changes with others working on the project. The stream structure and relationships with the user workspaces make such processes not only possible but a highly effective way to segment and isolate work efforts to maximize the efficiency of the software development team.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps
ArticleID=753779
ArticleTitle=Managing parallel development with Rational Team Concert
publish-date=08302011