IBM Rational Team Concert

Orientation to concepts and concepts

At software development in the group environment often happens it is necessary to separate any works into separate flows. Also separation can be based on functionality (for example, a set of improvements of a security system separates from changes in the graphic user interface) or to represent separation of set of defects from new development quicker to deliver to customers the version with corrections. For such separation of works there is a set of the reasons, and in many version management systems it is implemented using a set of parallel branches.

In IBM Rational Team Concert parallel development is implemented by use of several flows. A ready part of work gets to a certain flow and is integrated with work of other developers working with the same flow. When using several flows activity of different development teams is separated until the specific objective then practices from different flows are integrated is carried out.

In other words, flows allow a development team to integrate work of the participants into the necessary timepoints automatically.

The purpose of this article - to provide process of parallel development using product capabilities of Rational Team Concert by the description of the scenario and steps on creation of this scenario. The provided scheme considers many aspects of development with which development teams usually deal, but process can be modified taking into account specific requirements of any organization and any development process.

Whether such development is flexible?

One of the key principles of agile development is frequent integration of the changes made by each developer and continuous assembly of again integrated application code. Therefore some fighters for purity of the concept of flexibility can consider that formally separated process is out of area of agile development. However owing to the scale of many projects on development of software products of resources of one combined team of developers can be insufficiently. Besides, scales and complexity of changes can be so big that inevitably it is necessary to resort to separation. The principles of IBM agilityscale encourage separation of group and, respectively, purpose of different works to different groups.

Owing to physical dispersal of groups or obvious complexity of the project there can be reasonable an introduction to group of agile development of a certain extent of separation and regulated integration. This degree itself can be shown in a flow for specific location or for the specific version. Rational Team Concert helps groups of agile development to execute work separation, for example, into a series of functional flows which integrate in a single whole by means of a shared integration flow.

It is necessary to recognize that many groups of agile development use the free software tools or inexpensive building tools providing limited support of separate development. Such tools often do not allow use of separate approach owing to functional restrictions and high costs of implementation of integration. Rational Team Concert provides to commands of agile development the mechanism which promotes improvement of methods of development and their raising on the new level of efficiency, flexibility and creativity and at the same time is easily built in development processes.

Both small uniform groups of agile development, and the large geographically distributed groups consisting of a great number of smaller groups of agile development can use a technique of Rational Team Concert. Some key characteristics of groups of agile development and the principles of timely delivery at agile development (Disciplined Agile Delivery) are described by Scott Ambler in his blog (see the section Resources).

Evolutionary character

According to Embler, flexible strategy inherently are iterative and incremental. The stream structure needs to allow to evolve for the purpose of support of current demands of the project. In the presence of the command able to work with flows, processes of integration and creation of software will provide support of its activity by means of tools of configuration management of software at any moment. The structure of parallel project development shall not be worked completely out prior to writing of the code, but some principles should be clear to all participants. Management of cross-stream integration, management of flows of releases and security concern them and also management of work which is not completed in short terms and remains "unfinished" in a flow or a working space.
</DD>

High extent of interaction

The mechanisms used for joint work and maintenance of good visibility of activity of developers can turn average group of agile development into highly effective. User training to mechanisms of sharing of content and collection of information about activity of other developers is the key moment in respect of prevention of unproductive dead times and ineffectual development.
</DD>

Self-organization within proper infrastructure of the management

Configuration management is area on which the set of materials is written (including the author of this article), but they are seldom read. Existence of infrastructure of the management of proper level is a key to understanding of value of actions by developers in the field of configuration management. The task of the structure of process allowing development teams to understand what they need to make for finished product output and at the same time preserving of freedom in how to make it, opens excellent opportunities for creativity and self-organization. Such self-organizing groups will aim to use the approach which is most acceptable for them taking into account the nature of development, skills of group and available technology of automation (the additional information on templates of processes and infrastructures of automation is provided according to the link in the section Resources).
</DD>

Introduction to Rational Team Concert

It is supposed that the reader has basic knowledge on the product Rational Team Concert and the principles of configuration management of software. The additional information on Rational Team Concert and other closely related products can be found on the Website Jazz.net. For the aid to the reader we provide the description of a number of the concepts and terms, key for this product, used in the field of parallel development in this section.

Flow

The concept of a flow is conceptually close to the concept of a branch used in the majority of other version management systems. However there is a number of the essential differences allowing to execute specific transactions when using Rational Team Concert. Flows serve as a rallying point of changes which then can be transferred to other flows. In the scenarios provided here flows are used for collecting of changes in logical ones which then are transferred to other flow for version control. Many structures of parallel development implemented in other version management systems become very difficult to be maintained because of a large number of branches after a while. After completion of work with a flow in Rational Team Concert the flow can be deleted as all content is already moved to other place by this time. Thus, the flow can be considered or as a time structure for performance of work or as long-living structure for preserving and fixing of work.
</DD>

Set of changes

At version control in Rational Team Concert it is necessary to manage the changes made to files and to trace them. Some version management systems perform these processes pofaylovo so content integrates from a branch to a branch, the file behind the file. It often leads to errors, emergence of not used content or incorrect consolidation of files, the spoiled assembly or short a complete work can turn out to be consequence of what. At the disposal of developers there is a natural mechanism of grouping of changes of files in sets which logically create the complete block of work. The task of grouping is carried out as a part of process of registration in Rational Team Concert in which there is a creation of set of changes and management of it. Then in the majority of scenarios a set of changes contacts a work element, such as task, defect or version. It does visible a context of set of changes and allows members of the group to browse changes, works performed for meeting requirements of this element.
</DD>

Basic line

In the course of the project of development it is necessary to draw periodically a metaphorical line on sand and to identify file contents which form an element of the software product, stable, suitable for release (or other unit of useful work within version management system). Such point of identification in Rational Team Concert is the basic line. At the time of application of the basic line the available files and their contents for the specific version are identified. Later basic lines can be used as a reference point for gaining access to a specific configuration of files. Basic lines can be compared for demonstration of the existing distinctions and, thus, activity of developers between two recorded timepoints.</DD>

In many version management systems when comparing basic lines of distinction are displayed in the form of the file list which changed between two timepoints. Rational Team Concert can provide information in this way too, and this method has some value. However many developers would like to see real changes at higher level of abstraction. If sets of changes are connected with work elements as it is described above, then the list of complete elements can be used for representation of differences between two basic lines. For example, data on 35 defects and 12 versions completed during the last iteration often can give much more information on changes, than the list from 728 files changed for the same time.

</DD>

Delivery

The term delivery belongs to transfer of changes of files from the isolated working space of the developer in a flow which is connected with a working space at present. Preserving in a flow of new files or new versions of files which will be available to other developers connected with a flow is result of transaction of delivery. Rational Team Concert will inform these developers on emergence of new content, and they will be able to select suitable time for acceptance of changes. Users can switch between flows to which they want to transfer the code (as it is described below), and administrators of the project can manage permissions to transfer of content to specific flows.
Process of delivery reminds the process of merge of one branch about another implemented in other version management systems. One of the main advantages of Rational Team Concert consists that this tool allows developers to deliver work elements which include sets of changes connected with these elements. Therefore though above-mentioned comparisons of basic lines are possible at the level of a work element, actually the developer can deliver transactions as whole.
</DD>

Working space of the user

Each user has the working space of a repository connected with a flow to which it will transfer the work. When the user executes change in the file, the edited copy remains on client side in the sandbox connected with a working space of a repository. When the user stops making changes, the file is given in a system and is copied from client to the server area of a repository. The file is transferred in a set of changes together with other files which were also changed by the user. After completion of formation of set of changes the user gives him to a flow.
</DD>

Flows of parallel development

Even when users work in one flow (for example, a functional flow 1 at figure 1), there is some separation between users and the delivery managed by integration of changes in process and acceptance (see figure 3).

Figure 1. Registration and delivery in a flow

Starting point of this scenario is the development team which wants to separate the performed work into two additional flows for the purpose of isolation of the activity (see figure 2).

<A name=fig2 target=_blank>Figure 2. Simple structure of a functional flow</A>

In figure 2 the main flow of development to which developers reported several sets of changes is shown. On the scheme it is visible that, for example, one set of changes was transferred to a flow before delivery #1, and another - between deliveries of #1 and #2. If within the project no other flows are created any more, then all sets of changes delivered by group are integrated into a single shared stream. However the group working on this project decided that several developers should execute certain changes separately from other group. After a while after the beginning of work on the project the functional flow 1 was created. Then later some the functional flow 2 was created.

The part of work at the same time is performed in the main flow of development, and other part - in functional flows. For simplicity on schemes only a small part of sets of changes is shown, but in reality in each of flows in process of accomplishment by a great number of developers of their work the set of sets of changes is delivered probably. After completion of work with a functional flow 1 group decides that this flow should be integrated with the main flow of development in a point #2. Specific process of integration of work of one flow in another is described below. In a point of delivery the functional flow 2 is created, and work is continued in three separate parallel flows. On reaching points of #3 and #4 the work performed in two functional flows joins the main flow of development, and in a point #5 the basic line for release is created. After the end of deliveries from functional flows these flows are removed.

Adding of a shared flow of integration and release

Having created the scenario shown in figure 2 in the previous section, we will add to it an additional flow of integration and release. In figure 3 the new scenario which is described below is shown.

<A name=fig3 target=_blank>Figure 3. Functional flows with a shared flow of integration and release</A>

The scenario of creation of set of changes, the basic line and integration of work from one flow in another corresponds to the scheme described in the section Functional flows, but with little changes. The flow of integration and release will be used for formal integration and system application testing before its release.

1. In a point #3 in the main flow of development which is delivered in an integration flow in a point #4 the basic line is shown.
2. The integrated application can be tested before release from the basic #5 line in a flow of integration and release.
3. After that work on application programming in functional flows to points of #6 and #7 which then are delivered in the main flow of development in a point #8 is continued.
4. Then the functional flow 2 is closed and removed.
5. Further work is continued in the main flow of development to a point #9 in which the new basic line deliverable at a flow of integration and release is created.
6. Then in a shared flow of integration and release in a point #10 the new basic line for management of product output is created.

<A name=N10170 target=_blank>Separation of a flow of integration and release</A>

Over time development teams quite often come to conclusion about expediency of separation of a flow of integration and release on separate elements. It can occur for the following reasons:

• The carrying out of a flow of release for a framework of application programming allows group to increase security of this flow by supply management in it (see the section Supply management in flows devoted to security).
• Modifications of the code, necessary for implementation of integration, can be executed in an integration flow without violation of integrity of a separate flow of release.
• The changes necessary for a first line support of a system, it is possible to isolate from the main development that will allow to perform them (usually in configuration files), without influencing the main development. However the channel for fixing of such changes and their transfer back should be provided in the main flow of development. If the flow of release is not isolated, then such changes should be made to partially integrated code not completed yet and not prepared for release. It can complicate product output or delay the urgent corrections necessary for system operation.

In figure 4 introduction of a flow of release and a separate flow of urgent corrections for capture of operational changes in a system is shown. Process of fixing of such urgent changes and their transfer back to development is described in the following section.

<A name=N1018E target=_blank>Figure 4. Separate flows of integration, release and urgent corrections</A>

The code of the application program for the moment determined by the basic #5 line is selected for release therefore the new hierarchy of a flow of release for management of release and possible work on urgent corrections is created as it is described below.

1. In a point #6 the new basic line for release is created, and the flow of urgent corrections is from this point created (which in fact can not be used).
2. In a point #7 urgent change which is delivered in a release flow in a point #8 is executed. In most the organizations there are strict rules concerning a type and the volume of changes which are authorized for executing within "urgent corrections". Many organizations permitting urgent corrections experience difficulties in transfer of these changes back to a development team.
3. In a point #11 transfer of the code from a flow of urgent corrections in the main flow of development is performed to guarantee entering of the given change into the following formal release of the application. Also there can be a need of transfer of content of urgent corrections from the main flow of development in a functional flow 1 or a functional flow 2 (or in both), however such situation is not reflected in the scheme.
4. In the course of release the work performed in functional flows is delivered in the main flow of development in points of #9 and #10.
5. Performance of work continues in the main flow of development up to the intermediate basic #12 line which then is delivered in an integration flow where in a point #13 the basic line for the following release is created.
6. Creation of a flow of release and flow of urgent corrections for management of this release is shown in figure 5.

<A name=N101B6 target=_blank>Figure 5. Creation of structure of the second flow of release</A>

In figure 5 the further cycle of creation of a flow of release, a flow of urgent corrections and also the work on urgent corrections including several changes are shown. The completing action on the scheme is transfer of urgent corrections back in the main flow of development.

For each big release the new flow of release and urgent corrections as continuation of accomplishment of process of corrections and release in the first flow of release for creation of the second basic line of correction and release after the basic line designated as #7 can be required is created. Upon termination of support of specific release the corresponding flows of release and corrections can be deleted.

The last scheme of thread communication in the section shows how flows replace each other during development. In figure 6 it is shown that development process continues, functional flows 1 and 2 are complete, all performed work is delivered, and flows are deleted. For continuation of development the functional flow 3 is created. The release connected with the basic #8 line is also complete, and in spite of the fact that the flow of release remains, the flow of corrections can be deleted safely.

<A name=N101CE target=_blank>Figure 6. Further development</A>

The order of creation and removal of flows reflects style of development of group. As shown in figure 7, the project begins with one flow of development and gradually becomes complicated with each iteration. By removal of unnecessary flows the simplest structure of flows is supported. The screenshots provided in the following sections illustrate creation by the Rational Team Concert system of evident representation of flows, a working space of a repository and their interrelations.

<A name=N101E4 target=_blank>Figure 7. Activity of flows for lifetime of the project</A>

<A name="3.Creating the stream structure/outline" target=_blank>Creation of structure of a flow</A>

<A name=N101F7 target=_blank>New project</A>

When in Rational Team Concert the new project is created, it has one flow containing a component by default. Additional components can be created as required, but in the context of this document one component will be used. In figure 8 the flow and structure of a repository for the new project in which the working space of a repository only for one developer is provided are shown.

<A name=N10202 target=_blank>Figure 8. Initial structure of flows and repository of the project</A>

The flow and any working spaces connected to it can be visualized using the flowchart shown in the right part of figure 8. Users can see a hierarchical structure of flows and working spaces of a repository and also the flows connected to other flows. It is necessary to remember that Rational Team Concert in fact has flat structure, and information can be delivered from any working space in any flow in the presence of the corresponding permissions. (Permissions are described in the last section of article.)

For transfer of a required flow of changes of a development team should use documentation, for example, the schemes represented in figures 2-6. It will help certain developers to define in what place of a flow it is necessary to make changes and who is responsible for delivery of work to specific flows. Such documentation should be updated rather often that each member of the group well understood the obligations for a measure of development of structure of flows.

<A name=N10217 target=_blank>Connection to the project of new developers</A>

The users who are again connected to the project can get access to files for making changes by creation of a new working space of a repository. This transaction is executed in several steps: in the beginning select the item My Repository Workspaces (cm figure 8), then New, and then Repository Workspace. At the same time the dialog box shown in figure 9 where it is possible to select a flow into which changes will be delivered ("flow") will be displayed. The total quantity of flows of the project is usually small therefore to select the necessary flow simply if suitable descriptive names are appropriated to flows.

<A name=N1022B target=_blank>Figure 9. The choice of a flow to which changes will be made</A>

The flowchart after creation of the second flow is shown in figure 10. Pay attention that flowcharts can be created by means of the menu which appears by clicking with the right mouse button either on a flow, or on a working space of a repository in the right part of the screen represented in figure 8.

<A name=N1023D target=_blank>Figure 10. Several users connected to one flow</A>

<A name="4.Creating new streams/outline" target=_blank>Creation of new flows</A>

Explanation on information transfer from a flow in a flow

However creation of indicative communications between flows gives an evident picture of the fact that the changes which are saved up in one flow eventually will be transferred to other flow within development process. For creation of indicative communications between flows it is necessary to open a window of parameters of an initial flow, as shown in figure 11. <P>There are several methods of creation of new flows. One of protozoa is use of the flowchart providing the evident image of interrelations between flows and working spaces of a repository.

At right click on a flow the menu with different functions and options is displayed.

• Create a new working space of a repository.
• Create a new flow.
• Update the scheme using information from the database of a repository.
• Compare a flow status to a current status of any of the following objects:
  • Other flow.
  • Specific working space.
  • Specific picture of a status of a flow.

When choosing an option of creation of a new flow the user is offered to enter a name of a flow and area of group within the project which has access to a flow. If in the project there are no areas of groups, then the project name is displayed.

In the scenario in figure 2 the first created flow is called Feature Stream 1. Right after creation the flow has the same contents, as a flow from which it was created. Besides, the new flow has no interrelations with other flows and the related working spaces.

<A name=N10284 target=_blank>Figure 11. Parameters of an initial flow</A>

<A href="http://www.ibm.com/developerworks/ru/library/r-parallel-development-rational-team-concert/fig11_lg.html" target=_blank>The increased version of figure 11</A>.

In a dialog box for a flow it is possible to perform the following operations:

• Create new components.
• Add or update links from other projects (from certain basic lines).
• Add and delete destination objects of transfer.

The new destination object of transfer of changes to the main flow of development is added to a functional flow 1. Such configuration of a flow is shown in figure 12.

<A name=N102AC target=_blank>Figure 12. A flow configuration with indicative transfer of changes</A>

In figure 13 the updated flowchart on which three developers working at present with the main flow of development are represented is shown.

<A name=N102BE target=_blank>Figure 13. The flowchart with flows and working spaces of repositories</A>

Adding of a functional flow 2 (see figure 14) completes the scenario shown in figure 2.

<A name=N102D0 target=_blank>Figure 14. Two functional flows and main flow of development</A>

<A name=N102DD target=_blank>Completion of creation of a new flow</A>

For end shown in the drawing 4 structures of flows which consists of flows of integration, release and operational corrections new flows are created and connection of destination objects of transfer using the mechanism described above is established. Results are shown in figure 15.

<A name=N102E8 target=_blank>Figure 15. Flows of development, integration and release</A>

In the left part of figure 15 the activity of group connected with project development in which two developers (Mark and Simon) work with the main flow of development is shown, and Adrian works with a functional flow 1 (before Adrian worked with the main flow of development, and now it works on specific functions in a separate flow). Mark and Simon integrate the work as way of delivery of sets of changes to the main flow of development and the subsequent acceptance of sets of changes of this flow. The scheme is simplified regarding the number of the users working with each flow. It is supposed that Adrian and other developers will work jointly with a functional flow 1, and other developers will share a functional flow 2.

To the right of the main flow of development the structure of flows for support process of release and corrections is shown. The flow of integration is used for gradual (and managed) integration of the made changes. After creation of the respective basic line in an integration flow its current status (sets of changes and basic lines) is delivered in a flow of release 1.0. The release flow for the specific version is created as it is schematically shown in figure 4 and also on the flowchart in figure 15. It allows to support several flows of release for implementation of the scenario providing simultaneous use of several releases. Such releases can demand application to them urgent corrections. In an example in figure 16 the first release during creation has a set of changes from the basic #8 line. The situation when the customers using this release of the application have a need for additional urgent error corrections after passing of the basic #8 line in the absence of an opportunity to purchase the latest release of the application shown on the second flow of release is possible. Thus, support of a possibility of entering of corrections into the release created from the basic #6 line is of great importance.

<A name=N10300 target=_blank>Figure 16. Elements of flows of release and urgent corrections</A>

The flow of urgent corrections designated in figure 15 as "by Release Stream 1.0 - E-Fix" is intended for the fastest entering of urgent changes into the product prepared for release. These changes do not affect the source code and its recompilation; in many cases they belong to configuration files and settings which require immediate updating. Nevertheless these changes are transferred to the separate flow guaranteeing that flows of release will not be used when developing. Urgent changes probably too need to be made to a development flow that they naturally overflowed in the following release. In figure 4 a set of changes #7, deliverable at a flow of release and the main flow of development in a point #11 is shown.

<A name="5.Connecting users to streams/outline" target=_blank>Connection of users to flows</A>

In the scenario of parallel application development users should carry out two main objectives concerning configuration management:

• Create the working spaces providing some extent of isolation from other users and connected to specific flows of parallel development.
• Transfer the changes to the corresponding flows. From time to time in development process the developer needs to switch the working space to other destination objects according to the tasks arising before it.

Creation of new working spaces was described in the previous section. Connection of a working space to different flows for delivery of work is described in the following section.

<A name=N10325 target=_blank>Change of a target flow for delivery</A>

In the scenario in figure 2 the developer made changes to a functional flow 1. This set of changes may contain several files and, according to the principles of project implementation in the environment of Rational Team Concert, has either the description, or the related element of work. Changes of contents of files were executed on a local hard drive of the developer, and then handed over in a server working space of a repository and collected in a set of changes, as shown in figure 3. After this change are transferred to a specific flow. In the scenario in figure 15 users Mark and Simon deliver the changes in the main flow of development, and Adrian delivers the changes in a functional flow 1. The target flow for transaction of delivery is one of characteristics of a working space of a repository of the developer, as shown in figure 17 for the user Mark.

<A name=N10330 target=_blank>Figure 17. Properties of a working space of a repository</A>

In the information section of a working space of a repository there is a number of useful elements. According to a solvable task it contains a destination object for a repository which specifies, in what flow sets of changes will be delivered. To change a destination object, select Add (from the section of Flow Targets), and then select a required flow. If the user Mark wants to give sets of changes to a functional flow 2, but not to the main flow of development, the section of Flow Targets will look as it is shown in figure 18.

<A name=N10345 target=_blank>Figure 18. The alternative destination object is added, but not selected</A>

In a point of adding of a new destination object there really are no changes in a delivery method of sets of changes. To change the current destination object of delivery, the new target flow needs to be made current using buttons on the right side of the screen, as shown in figure 19.

<A name=N10357 target=_blank>Figure 19. The alternative destination object is added and set as current</A>

Figure 19 shows that the destination object accepted by default for a specific working space of a repository is the main flow of development, but the current destination object is the functional flow 2.

It is reflected in the flowchart shown in figure 20. The current destination object is represented by a solid line, and the destination object is by default represented by the shaped line.

<A name=N1036C target=_blank>Figure 20. A type of the flowchart after a task of a new current destination object</A>

Pending Changes representation also contains the useful information concerning destination objects. Any objects which are not destination objects by default are italicized in top line in Pending Changes representation, as shown in figure 21.

<A name=N1037E target=_blank>Figure 21. PendingChanges representation: the object which is not a destination object by default is selected</A>

At initialization of new delivery the window shown in figure 22 with warning of delivery to the object which is not a destination object by default at the same time is displayed the user can check that delivery is executed to the right place.

<A name=N10390 target=_blank>Figure 22. Warning of delivery to the object which is not destination object by default</A>

This warning will not appear if the user switched the destination objects flowing and accepted by default to a new flow in which wants to deliver sets of changes. In this case the target flow will not be italicized.

<A name=N103A6 target=_blank>Change of a destination object in Pending Changes representation</A>

Also there is an opportunity to change a destination object in Pending Changes representation. The new target flow can be selected, having right-clicked on a name of a working space of a repository and having selected Change Flow Target.

<A name="6.The Integrator role/outline" target=_blank>Role of integrator</A>

As it was told above, the shooters connecting flows on flowcharts in figures 13, 14, 15 and 20 serve only for informing on intention to transfer work from one flow to another. Work on transfer of specific changes from a flow in a flow is performed by the person to whom the role of "integrator" is appointed. This process is described in the following section. As shown in figure 4, changes will be transferred from a flow to a flow in the following order (for example):

Functional flow 1> Main flow of development> Integration flow> release Flow

In practice sets of changes should be transferred from a flow to a flow through a working space of a repository. The role of integrator often comes down to implementation of this process. For transfer of sets of changes of a flow to a flow it is necessary to execute the following transactions:

1. Appoint the current destination object of a working space of a repository to an initial flow.
2. Accept all entering changes from an initial flow in a working space of a repository.
3. Appoint a destination object of a working space of a repository to a target flow.
4. Transfer outgoing changes.

Councils.
It is recommended to execute these transactions in a net integration working space. Otherwise transaction of delivery on a step 4 can take the local changes made by the developer executing integration transaction, but not just a set of the changes collected in an initial flow. Besides, before accomplishment of the transaction Accept on a step 2 it is necessary to be convinced of lack of outgoing changes in representation of Pending Changes of a working space of a repository.

In the example given below steps on transfer of changes from a functional flow 1 in the main flow of development through a working space of the user by the name of Mark are described.

<A name=N103DE target=_blank>Collecting of changes from a functional flow 1</A>

Appoint the current destination object of a working space of a repository (a working space of Mark) to a functional flow 1, as shown in figure 23. After that in representation of Pending Changes of a working space of a repository the entering changes made by the user under the name of Adrian to a functional flow 1 as shown in figure 24 will be displayed. The integrator (Mark) should include these changes in a working space of a repository.

<A name=N103E9 target=_blank>Figure 23. The working space of a repository connected to a functional flow 1</A>

<A name=N103F8 target=_blank>Figure 24. Acceptance of changes from a functional flow 1</A>

<A name=N10405 target=_blank>Delivery of changes to the main flow of development</A>

Appoint the current destination object of a working space of a repository to the main flow of development, as shown in figure 25. After that in representation of Pending Changes of a working space of a repository outgoing changes for the work which is at present in a working space of a repository as shown in figure 26 will be displayed. Integrator Mark should give these changes from a working space of a repository.

<A name=N10410 target=_blank>Figure 25. The working space of a repository connected to the main flow of development</A>

<A name=N1041F target=_blank>Figure 26. Delivery of changes to the main flow of development</A>

Such process can be used for collecting of changes from any flow and the subsequent their transfer to any other flow. However it is necessary to provide management of users to which transfer of changes to specific flows is resolved (for example, in a release flow). In the following section the procedure of access control to flows is described.

<A name="7.Controlling deliveries to streams/outline" target=_blank>Supply management in flows</A>

In the field of Process Configuration of the project it is possible to define roles of the project, it is authorized to them to deliver changes in specific flows for a specific component. The respective area of configuring can be found, by following these steps in the Eclipse-system interface of Rational Team Concert:

1. Select Project Area.
2. Select the Process Configuration tab.
3. Select Team Configuration> Operational Behavior.
4. Select Source control (Deliver Server).
5. Select the Everyone (default) column
6. Note the Preconditions and follow up actions are configured for this operation checkbox.
7. Select Add and the precedent condition Restrict Change set delivery to components in a particular stream.

In figure 27 the result of these actions is shown.

Council.
If desired instead of the Eclipse-interface it is possible to use the Web interface.

<A name=fig27 target=_blank>Figure 27. Configuration of process of management of deliveries</A>

<A href="http://www.ibm.com/developerworks/ru/library/r-parallel-development-rational-team-concert/fig27_lg.html" target=_blank>The increased version of figure 27</A>.

For each flow it is possible to specify roles, it is authorized to them to deliver sets of changes, as shown in figure 28 (which is the enlarged image of the lower part of figure 27).

<A name=N10487 target=_blank>Figure 28. Management of permissions to making changes on the basis of roles</A>

8. Having selected a specific flow (for example, a flow of release 1.0), it is possible to click the mouse button on Edit permissions and to appoint roles, it is authorized to them to make changes to a flow.

In figure 28 the new role of Release Stream Integrators is shown, and now only the members of the group having access to a release flow will be able to execute delivery to it.

<A name=8.Summary/outline target=_blank>Conclusion</A>

Rational Team Concert provides the highly effective environment of collective interaction for modern projects of software development. Support of several flows of development and collateral execution of project changes is necessary for most of groups. The stream structure and interrelations with working spaces of users do such processes not by the just possible, but very efficient method of segmentation and isolation of works providing maximum efficiency of group of software development.