This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Correct Use of Promotion Model and Workspace


I'm using PVCS VM, we use Version Labels but I'd like to know What is the purpose and the correct use of Promotion Model and WorkSpace. And How Can Improve my enviroment using these features. I read the manual but It's not clear for me. I'd like to know How You uses these features on your enviroments

Sorry for my poor English.

Best Regards
Parents
  • 0  

    Hello Gerald,

    Sorry for the delay in my response as well :-) I was unavailable for a few weeks.

    For the QA group you could restrict their promotion to just the next level (by only allowing the to promote if the group is "QA"). The "demote" operation is more problematic in that you cannot presently restrict the assignment of a promotion group based on the target group. That's something we could consider changing in the product, so we could submit an enhancement request if you are interested in doing that. (Kindly submit a support case if you do).

    You could potentially write an application that does the demotion for you (as a different user with sufficient privileges) and have users call that from the toolbar, but that solution may be overly complicated, unless you have a lot of demote requests that are overwhelming the VM admin. If not, having the admin perform this task is the next best thing.

    All you really have to do it remove the QA group and tell the developer to fix the problem.If you trust your QA team to not remove the Production group, you could grant them both the Promote To The Next Promotion Group privilege (into Production) and the Delete Promotion Group privilege (to demote back to Dev). Developers performing a checkout to fix the problem would automatically assign a lowest level group.

    You could potentially have QA apply a label to the bad revision to help developers find it (but they would have to remove it when done!), or have a designated "Returned from QA" lowest level group which you could then both find and which would promote back up to QA through the regular promotion process.

    Hope this help you along. If you have any more question, just let me know.

    Kind regards,

    - Richard.
Reply
  • 0  

    Hello Gerald,

    Sorry for the delay in my response as well :-) I was unavailable for a few weeks.

    For the QA group you could restrict their promotion to just the next level (by only allowing the to promote if the group is "QA"). The "demote" operation is more problematic in that you cannot presently restrict the assignment of a promotion group based on the target group. That's something we could consider changing in the product, so we could submit an enhancement request if you are interested in doing that. (Kindly submit a support case if you do).

    You could potentially write an application that does the demotion for you (as a different user with sufficient privileges) and have users call that from the toolbar, but that solution may be overly complicated, unless you have a lot of demote requests that are overwhelming the VM admin. If not, having the admin perform this task is the next best thing.

    All you really have to do it remove the QA group and tell the developer to fix the problem.If you trust your QA team to not remove the Production group, you could grant them both the Promote To The Next Promotion Group privilege (into Production) and the Delete Promotion Group privilege (to demote back to Dev). Developers performing a checkout to fix the problem would automatically assign a lowest level group.

    You could potentially have QA apply a label to the bad revision to help developers find it (but they would have to remove it when done!), or have a designated "Returned from QA" lowest level group which you could then both find and which would promote back up to QA through the regular promotion process.

    Hope this help you along. If you have any more question, just let me know.

    Kind regards,

    - Richard.
Children
No Data