99 Rational Synergy Build Manager’s Guide, Release 7.1
Adding an existing project to your hierarchy
1. Create a task and leave yourself as the resolver.
The new task is set as the current task.
2. View the project where you want to add the existing project.
3. Use drag and drop or copy and paste to add the existing project to the current project.
If you do not remember the name of the project you want to add, use the Query dialog box to find the project.
4. Complete the current task.
Cutting a project from your hierarchy
1. Create a task and leave yourself as the resolver.
The new task is set as the current task.
2. View the parent project that contains the subproject you want to cut.
3. Right-click over the subproject and select Cut.
This cuts the subproject from the project, but does not remove it from the database.
4. Complete the current task.
Deleting a project from your hierarchy
Note The delete operation permanently deletes the project from the database.
If you do not want the project in your hierarchy, but you still want it in your database, see Cutting a project from your hierarchy (page 99).
1. View the project you want to delete.
2. Right-click over the project to be deleted, and select Delete.
Be sure to select the appropriate scope for the deletion (project, project and members, etc.).
Converting a directory to a subproject
You can perform this operation from the CLI only.
1. Start Rational Synergy from the command prompt.
ccm start -h engine_hostname -d database_path -nogui After the session starts, the Rational Synergy address (CCM_ADDR) is printed in your command window (Windows) or in the shell where you started the session (UNIX).
2. Set your role to build_mgr.
ccm set role build_mgr
3. Create a task, assign it to yourself, and set it as the default.
ccm task -create -synopsis"string" -default
4. Change to the directory in your work area above the directory you want to convert to a project.
5. Create a project, specifying the directory as its root.
ccm create -type project-rootexisting_dir-versionint -release release-purpose "Integration Testing"
6. Create the platform for the subproject, if necessary.
ccm attr -create platform-type string -value platform -project project_spec
7. Use the ccm unuse command to unuse the directory.
8. Add the new integration testing project to your integration testing project hierarchy.
ccm use -p project_name delimiter version
9. Windows users: If you use absolute subprojects, change the makefiles, the build process, and all automated jobs to reflect the changes you have made.
If you use relative subprojects, no changes are necessary.
10. Complete the current task.
ccm task -complete default
11. Perform an integration test cycle, then Creating a baseline (page 68).
12. Copy a system testing project from the new project.
This operation is discussed in Creating the system testing projects (page 28).
Chapter 9: Project restructuring
101 Rational Synergy Build Manager’s Guide, Release 7.1
13. Update your top-level system testing project, rebuild your application, then run through your test suite.
Note Repeat this process for each platform, checking out integration and system testing project for each platform.
14. Exit from the Rational Synergy CLI.
ccm stop
Adding a new project to an existing hierarchy
Steps a and b below need to occur if a developer creates the new project to be added to your existing hierarchy. Developers performing this operation need to have the component_developer role set in Rational Synergy Classic.
1. Be sure that the developer does the following:
a. The developer must complete his current task.
b. The developer must check in his new project.
2. Copy an integration testing project from the project you just checked in.
Be sure to set the version, purpose, platform and release.
3. Add the new integration testing project to the integration testing project hierarchy.
If the developer already added the project to a directory in the hierarchy and checked in that directory, update the integration testing project hierarchy to ensure that Rational Synergy selects the new directory and includes the new project. Update is described in Updating a project (page 48).
Alternatively, if the developer did not add the new project to the hierarchy, you will need to add the project to the integration testing project hierarchy.
(This operation is described in Adding an existing project to your hierarchy (page 99).) Additionally, you will need to create a task, then complete the task when the change is complete.
If you get empty directory entries in your new project, it could be because some objects are not associated with a task for this release.
4. Create an external project, if needed. Note that you need to add one build management project for integration and one for system testing project.
This operation is discussed in Creating an external project (page 80).
5. Create versions for parallel platforms, if needed. Note that you need to add one for integration and one for system testing project.
This operation is discussed in About the platform file (page 17).
6. If the new project applies to multiple releases, create parallel release versions of it. Note that you need to add one for integration and one for system testing project.
This operation is discussed in Setting up parallel releases (page 95).
7. Change the makefiles, the build process, and all automated jobs to reflect the changes you have made.
8. Complete any tasks you have used for restructuring.
9. See Publishing a baseline to developers (page 71).
10. Update your integration testing project hierarchy, rebuild your application, then run through your test suite.
11. Create another baseline.
12. Create a corresponding system testing project for each new integration testing project.
This operation is discussed in Creating the system testing projects (page 28).
13. Update your system testing project hierarchy, rebuild your application, then run through your test suite.
14. Perform system testing.
Note Complete this process for each platform, checking out integration and system testing project for each platform.
© Copyright IBM Corp. 1992, 2009 Rational Synergy Build Manager’s Guide, Release 7.1 103
10 Build management variations
All companies do not build their applications in exactly the same way. Each company has its own special needs. Company Q might be very new and small with one product offering, while Company V might be very large, offering several products on different platforms.
The Rational Synergy task-based methodology includes the use of different features in Rational Synergy. Some of the features build managers will use are not included in detail in this book because they are not required. The features do, however, make the build manager’s job much easier by automating operations and by keeping developers from performing operations that are complex.
The following information is intended to give direction to those companies for whom the standard methodology, given in the previous chapters, does not apply completely. If your company falls into this category, you will use a variant of the methodology to perform your build management duties. The following variants are discussed:
• Build management for UNIX and PC together (page 104)
• UNIX work areas with local files (page 105)
• Grouping projects (page 106)
• Creating a custom folder template query (page 109)
Build management for UNIX and PC together
If your application runs on both UNIX and the PC, be sure to consider the following before you attempt to build:
• Work area visibility
A Rational Synergy session on UNIX probably cannot see your work areas on the PC, and a session on the PC cannot see your work areas on UNIX.
• Makefile formats
Most sites probably have existing parallel makefiles for building on UNIX and the PC; if so, you can continue using your makefiles on both platforms.
If not, do the following:
a. Set up parallel versions of the project, one for each platform.
b. Set up parallel versions of the makefile, setting each platform property for the makefile to the appropriate value.
When you update the parallel versions of the project, each will bring in the appropriate makefile for its platform.
• Automation
When you automate your update/build process, you will need to automate the Windows and UNIX jobs separately with shell scripts or batch files, or use a cross-platform scripting solution, such as Perl or Cygwin.