Refactoring scenario: demote request

If you are demoting a request deployment, then file and folder removes will revert to their old values when the request is demoted.

This example illustrates what will happen if you demote a previously promoted file rename.

The following table shows the filename and revisions initially in the main project and each area. The filename is the same, and earlier revisions have progressed farther along the stage lifecycle with later revisions:

Project DEV SIT QA LIVE
Docs/login.html;4 Docs/login.html;4 Docs/login.html;4 Docs/login.html;2 Docs/login.html;1

The user uses the desktop client to rename the file in the project to welcome.html against the default request R1, and the filename is changed in the project and the initial stage:

Project DEV SIT QA LIVE
Docs/welcome.html;4 Docs/welcome.html;4 Docs/login.html;4 Docs/login.html;2 Docs/login.html;1

This change is then deployed to SIT by promoting request R1, and the project and area contents become:

Project DEV SIT QA LIVE
Docs/welcome.html;4 Docs/welcome.html;4 Docs/welcome.html;4 Docs/login.html;2 Docs/login.html;1

The file is now renamed in the SIT area.

At this point, testing occurs at the SIT stage, and the team realizes that the file rename needs to be backed out from the SIT stage. The team leader demotes request R1 back to DEV, and the project and area contents become again:

Project DEV SIT QA LIVE
Docs/welcome.html;4 Docs/welcome.html;4 Docs/login.html;4 Docs/login.html;2 Docs/login.html;1

The file rename was reverted in the SIT area.

Back to top