Workspaces and change lists

When you edit the PolicyCenter product model in Product Designer, your changes are stored in a change list that is associated with a workspace.

• A workspace is a named association with a set of PolicyCenter configuration files. Product Designer refers to the location of the PolicyCenter configuration files as the configuration root folder. Your administrator defines Product Designer workspaces by following the instructions in Managing Product Designer workspaces.
• A change list is a named collection of changes that are held by Product Designer until you decide either to commit or revert the changes. Committing your changes means moving them to the application’s configuration files on the PolicyCenter server specified in the workspace with which the change list is associated. Because your changes are in a change list, you can safely make changes and then later choose to commit or not commit some or all of those changes. But until you commit the change list, the changes it contains do not become part of the active PolicyCenter configuration.

Each change list is associated with a workspace. Therefore, each change list, when committed, modifies the configuration files in a specific PolicyCenter instance. The following illustration shows interactions between Product Designer, Guidewire Studio, and a PolicyCenter development server, and deploying product changes to a production server.

You can create multiple change lists, and then select the active change list from among them. All changes you make are saved in the active change list. Using multiple change lists enables you to group your changes into separate sets and independently commit each change list at the appropriate time. Unless you assign it to another user, each change list and the changes it contains belong to you. Other users have their own change lists. A change list remains under your control unless you or your administrator reassigns it to another Product Designer user.

A workspace optionally can be configured with a source control system. When configured in this way, Product Designer automatically checks out individual files as each user makes changes to them. However, it does not check them in again. You must manually check in your changed files using the source control system.

In addition to a configuration root folder, your administrator also can designate a test server URL for each workspace. Test Server URL specifies a running PolicyCenter instance to which to deploy product model changes when you select the Synchronize Product Model or Synchronize System Tables command in Product Designer.

The Test Server URL need not designate the same PolicyCenter instance as the Configuration Root Folder for the workspace, although typically they are the same. However, the Test Server URL must point to an instance of PolicyCenter that is running in development mode. As indicated in the previous illustration, you cannot deploy the product model to a running instance of PolicyCenter in production mode. Instead, you must instead create a WAR or EAR file and manually deploy the file using the application server’s deployment commands. For more information on server modes, seeServer modes.