Workflow for working on activities in a multiple-stream UCM project

To work on activities in a multiple-stream project, youdevelopers check out and modify source files and test yourtheir modifications. You might also need to enter information in your change-request management system to communicate your progress.While doing so, developers can leave comments to indicate their progress. On a multiple-stream project, if you are ready to make your work available to the rest of the team, you deliver itfinal changes are delivered to the integration stream.
In a single-stream project, you perform many of the same tasks, but the ordering is slightly different.
Checking out and modifying source files
To modify files and directories under DevOps Code ClearCase®version control, youdevelopers must check them out and ensure that you have assigned yourby opening the file and ensure that they have assigned their revisions to an activity. Checking out a file makes it writable in your view. Then you can use any editing tool to modify itallows developers to make edits in real time.
Viewing metadata
Metadata is information that is kept about your activities and source files in both DevOps Code ClearCase and Rational® ClearQuest® environments. While working with checked-out files (checkouts), youdevelopers might want to use DevOps Code ClearCase and Rational ClearQuest tools to view metadata. For example, you can do the following tasks:With , developers can do the following tasks:
- See the history of an element.
- Compare versions of an element.
- See which versions are checked out to your viewthey have checked out.
Checking in and testing source files
If you work in a multiple-stream project, if you want to keep a record of the current state of a checkout or to store versions for backup, check in the file. Make sure that you assign the version to the correct activity. Any work that you check in from your development view is not available to other team members until you deliver it.If developers want to either keep a record of the current state of a checkout or to store versions for backup, they can check in the file. Developers must make sure to assign the version to the correct activity. Checked-in file edits become immediately visible to other developers on the project, but final changes are delivered to the integration stream.
Before you deliver your work, build and test the work in your development view.Developers must build and test their work prior to delivery. This testing is particularly important to do after youdevelopers rebase the stream and before youthey deliver activities. This ordering of your work reduces the amount of merging needed when youdevelopers deliver yourtheir work.
When you are ready to make your work available to the rest of the project, deliver it.Deliver your work when you are ready to make it available to other developers on the project.
If you work in a single-stream project, you do not check in until you test your source files and want to complete your activity.
Indicating your progress
- Modify information in Rational ClearQuest
- Close an activity
- Use schema-specific actions
- Reassign an activity
- Delete an activity
Working on multiple activities
You can set your view to only one activity at a time, but you can keep multiple undelivered activities in your stream. You can work on one activity, set and work on a different activity, and then set and return to working on the original activity.Developers can set their view to only one activity at a time, but they can keep multiple undelivered activities in their stream. They can work on one activity, set and work on a different activity, and then set and return to working on the original activity. Developers can also view activity change sets to track progress, or delete empty activities on .