This topic includes the following sections:
The Rational Synergy database is a data repository that stores all of your controlled data, including source and data files, their properties, and their relationships to one another.
The database contains projects. A project is a user-defined group of related files, directories, and other projects. A project normally represents a logical grouping of software, such as a library or an executable, and it contains the directory structure of the files. Projects have version, like any other object.
Each project has a purpose, for example, development or testing. A project purpose, together with its release, determine the behavior of the project. Each release has a process, implemented with process rules that define the behaviors of projects. You can use one of the shipped processes or modify one. The Rational Synergy default development process helps teams implement best practices. Insulated areas help developers to test and debug their work. Frequent integration of the latest changes introduces these changes to the development environment when developers are ready to include them. Stabilized milestone builds establish a quality standard without introducing new changes.
The planned work for a team is described by tasks. A task groups all the software modifications that must be made to complete a logical change. A task can be created to fix a defect or to implement an enhancement. The following list shows some of the properties for a task:
The current task is the task you are currently working on. When you designate a task as the current task, you tell Rational Synergy that each time you check out an object, you want the object to be associated with that task automatically. When you finish making all the software changes for a task, you can complete the task. Completing a task checks in all object versions associated with the task, and also sets the task status as complete.
Using tasks, you can move each logical change as a unit through the Rational Synergy lifecycle to completion. Using task information, you can gather versions of software for building and testing by specifying which logical changes you want.
Typically, developers perform operations for developing and testing software. Developers work on tasks in their own work areas. A work area is a location in your file system into which Rational Synergy writes a project when you check it out.
Typically, build managers perform operations for collecting and integrating software, and configuring and building areas where developers can access the integrated software. They also configure and build test areas, and prepare software for release. They perform build management operations by using build management projects.
By default, Rational Synergy supports two test areas, one for integration testing and one for system testing. Build managers use the build management projects to manage those areas.
The integration testing project, enables build managers to collect, build, and test the latest completed tasks checked in by developers. The members of this project are brought in through a query of all completed tasks.
The system testing project, enables build managers to collect, build, and test the application in more detail, to reach an agreed-upon quality standard. The members of this project are brought in through a carefully controlled process.
Additionally, build managers create a baseline as soon as they perform a build. A baseline is a set of projects and tasks used to represent data at a specific point in time. When a build manager performs an update, Rational Synergy uses a baseline as a starting point to look for new changes.
Creating a baseline for each integration testing and system testing build enables users to refer to the set of changes that were used to create the build. Typically, build managers create a baseline for all projects in the same release and purpose. For example, a build manager would create a baseline for each integration testing build using all integration testing projects for a release.
Baselines also improve performance for update operations. An update that uses baselines analyzes only the tasks that were added since the last baseline, rather than all tasks for the entire release.
When the build manager has updated the system testing projects, dealt with conflicts, built products, and tested the application, he is ready to publish changes to the development team. The build manager then publishes the baseline.
Publishing the baseline makes it available as a baseline for selection during an update. The process rules ensure that projects use the latest baseline.
The previous section discussed the development cycle. Developers move through the development cycle and complete tasks in their projects. Build managers move through the build management process by gathering and testing tasks, releasing projects, and establishing a baseline. The following figure summarizes how projects are used to implement the workflow. The arrows show how tasks flow through the various projects. The key points in the figure are:
The figure shows the default process. The process is configurable by release.