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.
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).
- "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.
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.
- 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.
- 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.
- 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.
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
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
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.
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
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.
- A baseline is shown at #3 in the Main Development stream, which is delivered to the Integration stream at #4.
- The integrated application can then be tested before a release from baseline #5 in the Integration and Release stream.
- 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.
- Feature stream 2 is then closed and removed.
- 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.
- A new baseline is then created on the shared Integration and Release stream at #10 to manage the release to production.
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
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:
- 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).
- 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.
- 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.
- 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.
- 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.
- 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
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
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
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
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.
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 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
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.
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 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
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
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
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 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
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.
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.
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
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)
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 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
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
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
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.
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.
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.
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:
- Set the current flow target of a repository workspace to the source stream.
- Accept any incoming changes from the source stream to the repository workspace.
- Change the flow target of the repository workspace to the target stream.
- Deliver the outgoing changes.
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.
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
Figure 24. Accepting changes from Feature Stream 1
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
Figure 26. Deliver changes to Main Development 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.
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
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
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
You can then finish the delivery in the normal manner.
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
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
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.
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:
- Select Project Area information.
- Select the Process Configuration tab.
- Select Team Configuration > Operational Behavior.
- Select Source control (Deliver Server).
- Select the Everyone (default) column heading.
- Check the box for "Preconditions and follow up actions are configured for this operation."
- Select Add, and choose the precondition called Restrict Change set delivery to components in a particular stream.
You can do this in the web interface, too.
Figure 32 shows the result.
You can do this using the web interface, rather than the Eclipse one, if you prefer.
Figure 32. Process configuration for delivery control
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
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.
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.
- Read Scott Ambler's blog post for more details on disciplined agile delivery.
- For further information on process templates and automation frameworks, see the Process awareness and customizability page in the Rational Team Concert Features section of Jazz.net.
- Find Rational Team Concert articles and links to many other resources on the IBM developerWorks page. You can also watch the Using Rational Team Concert in a globally distributed team webcast or a demonstration of the Dashboards and reports, or listen to the podcast about IBM Rational Team Concert and Jazz.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Rational Team Concert trial downloads (free):
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational Team Concert discussions or ask questions in the Jazz.net forums.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a byline and a bio, and the benefit of professional editing and production on the developerWorks Rational website. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook and Twitter (@ibmrational), and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the developerWorks community and responding to the developer-driven blogs.
Mark 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.