Refactoring occurs when there are modifications within the project/stream structure such that the location of items or folders are changed. Examples would be exporting an item to or from a project, or moving a project/stream folder from one parent folder to another. Operations that result in refactoring are:
File renames
File moves
Folder renames
Folder moves
File removals
Folder removals.
When you make these changes in Dimensions CM clients (web client, desktop client, or dmcli client) these changes will only happen automatically in:
The Dimensions CM project/stream in which you perform the changes
Any areas associated with the initial deployment stage for the project that are defined as Deploy by Default.
In order to have these changes reflected in the deployment areas for other stages in the GSL (global stage lifecycle) you will need to take some additional action to deploy these changes.
Using requests to track refactoring changes is the recommended method of ensuring that these changes are reflected in the appropriate deployment areas. Baselines cannot be used to deploy refactoring changes.
When you perform actions that will result in refactoring, such as exporting a file to a project, or renaming a project/stream folder, those changes are recorded or tracked in Dimensions CM against a request ID, provided a request was specified when those actions were performed. When you subsequently promote one of these requests to another stage in the GSL and deploy it, the refactoring changes that were tracked against that request will also be applied to the deployment areas associated with that stage to which it has been promoted.
For example, a developer needs to move a file foo.c from the folder src to the folder utils. The project uses the GSL consisting of the stages:
DEV -> SIT -> QA -> LIVE
The developer uses the desktop client Move dialog box to move the item in the project, and enters a request, R1, in the Track changes with request(s) field.
The project and the areas associated with the DEV stage now contain the item file:
utils/foo.c
Whereas the deployment areas for stages SIT, QA, and LIVE still contain the file:
src/foo.c
He then wants to deploy this change to SIT. He therefore promotes and deploys the request R1 to the SIT stage.
The deployment areas for SIT now contain the file utils/foo.c. The deployment areas for QA and LIVE, however, still contain the file src/foo.c.
When the change is ready to be deployed to QA and LIVE, the request R1 is subsequently promoted and deployed to those stages.
Request driven refactoring has the advantage of supporting all the types of refactoring: removing, moving, or renaming of folders or files. It also does not present a problem when demoting back down the GSL.
NOTE When using request driven deployment, refactoring changes must be deployed up in the order in which the refactoring changes were carried out. For example, if the file foo.c is added to the project, and then it is renamed to bar.c, the file foo.c needs to have been promoted to a particular stage before the rename can be promoted to that stage.