In Dimensions you can map lifecycle states to stages in the GSL. If this mapping is setup, when you action an object to a lifecycle state that is mapped to a stage, it is automatically promoted to, or demoted from, that stage. If Deploy by Default is enabled for the deployment areas attached to the stage, the object is also automatically deployed to, or rolled back from, the areas.
In this example some of the states in this request lifecycle are mapped to stages in a GSL:
For example:
When a request is actioned up the request lifecycle from the Under Work state to In Test it is automatically promoted from DEV to SIT.
When a request is actioned down the request lifecycle from the Ready for QA state to In Test it is automatically demoted from QA to SIT.
NOTE
You can use action driven deployment with items, requests, and baselines.
For action driven deployment to work you require the privileges to action and promote to stages and areas.
Actioning an object to an off normal state removes item revisions from the associated stage.
You map lifecycle states to the GSL in the Lifecycles section of the Dimensions CM administration console.
When you use action driven deployment to promote or demote an item revision to another stage, the operation is applied globally to the same item revision across all projects in the current product. However, if you select the option Use local stages in a project/stream, the stage of the item revision in that project is not affected when the same item revision is promoted/demoted in any other project/stream. Therefore the same item revision can be at different stages in each project/stream. Once you have selected this option for a project/stream you cannot change it.
When you run the Promote, Demote, Deploy, and Rollback commands you have the option to schedule the execution in the future. For example, you might want to deploy to a live production environment during the regular maintenance period when the server is offline.
NOTE If you try to deploy to an area that already has a deployment scheduled, a warning is displayed. If you proceed with your deployment the scheduled deployment may fail.
Refactoring occurs when there are modifications in the structure of a project or stream that change the location or names of items or folders, including deletions. For example, exporting an item to a project, or moving a folder from one parent folder to another.
If you have refactoring changes you must deploy them using a request and not a baseline. If you try and deploy refactoring changes out of sequence the deployment will fail.
Always refactor using a new request that is not related to any other changes. If you do not use a new request, when you need to deploy the refactored changes (because another change is dependent on it) you might not be able to deploy the refactoring request because the other changes are related to it.