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,

    That's actually not an easy thing to answer, but let me try to give you an idea.

    A Version Manager workspace can viewed as a transparency sheet that is laid on top of the project and file view in the GUI, allowing you to change certain properties, which are shown from the (right-click ->) Properties dialog, on the Workspace Setting tab:

    Project:



      Workfile location

      Default Version (label)

      Branch Version (label)

      Base Version (label)

      Default Promotion Group



    File:



      Workfile location



    Changes made within a workspace only affect that workspace, with one exception:

    Files and Project inherit from both the parent workspace and from the parent project until a property has been (re)defined in a workspace. Once it is defined, that property will be used by all files and subprojects while the workspace is selected, until it is changed again in deeper nested project or on a file.

    The most common use is for someone to define a workspace (private or public) and then change the workfile location at the PDB root. Normally projects have a relative workfile definition, meaning they just add to the path of the parent project. Because of this you can change the checkout / get location for the entire PDB, just by changing the workspace. Helpful for certain processes.

    If this sounds very unclear let me know and I'll try to elaborate :-)

    The promotion model can be viewed like a specialized set of version labels which each version label being linked to a parent as defined in the promotion model. Whenever you select promote on the group "label", it gets renamed into the parent label.

    You can use this concept to identify the state (stage) of a revision. Imagine the following very simplistic promotion model:

    Development -> Ready for QA -> QA -> Ready for Production -> Production.

    When a developer is done with a given file (stage Development) he can click promote and the group moves up a level to "Ready for QA". The QA manager can now promote from "Ready for QA" into "QA", accepting the newly updated file and run tests after performing a get on all files at the "QA" stage or higher (meaning an unchanged file without the "QA" group associated with it would be fetched using the revision that is associated with group "Ready for Production" or "Production", which is something VM can do automatically by performing a Get on a promotion group).

    Once QA has accepted the changes, the file gets promoted again to "Ready for Production". Now the person in charge of production data can promote files at this stage into "Production" and perform a get on this group, updating the files in production.

    Promotion groups are generally volatile in that they describe the stage of a revision in a file. You would still assign permanent version labels to be able to go back in time and find out which revision would be associated with "Product Release 1.0". Such labels you could create once the files were promoted to "Production", by assigning a label to all revisions in files that are associated with this promotion group.

    Promotion groups can be used to change the security model that Version Manager uses, meaning you can prevent someone in Development from promotion into Production by limiting at what stage in the promotion model developers can promote. Explaining this in detail will take some time, so I'm just posting it here as a note.

    Using promotion groups can make simultaneous development on different revisions in an archive (branches) a bit more complicated, as each revision being checked out will need its own unique lowest level promotion group. If you need this you will need to have multiple lowest levels groups. A possible model could include the lowest level "Bugfix", so that group and "Development" could be associated with different revisions.

    Hope this wasn't too overwhelming. If you need me to elaborate on anything, please let me know.

    Kind regards,

    - Richard.
Reply
  • 0  

    Hello Gerald,

    That's actually not an easy thing to answer, but let me try to give you an idea.

    A Version Manager workspace can viewed as a transparency sheet that is laid on top of the project and file view in the GUI, allowing you to change certain properties, which are shown from the (right-click ->) Properties dialog, on the Workspace Setting tab:

    Project:



      Workfile location

      Default Version (label)

      Branch Version (label)

      Base Version (label)

      Default Promotion Group



    File:



      Workfile location



    Changes made within a workspace only affect that workspace, with one exception:

    Files and Project inherit from both the parent workspace and from the parent project until a property has been (re)defined in a workspace. Once it is defined, that property will be used by all files and subprojects while the workspace is selected, until it is changed again in deeper nested project or on a file.

    The most common use is for someone to define a workspace (private or public) and then change the workfile location at the PDB root. Normally projects have a relative workfile definition, meaning they just add to the path of the parent project. Because of this you can change the checkout / get location for the entire PDB, just by changing the workspace. Helpful for certain processes.

    If this sounds very unclear let me know and I'll try to elaborate :-)

    The promotion model can be viewed like a specialized set of version labels which each version label being linked to a parent as defined in the promotion model. Whenever you select promote on the group "label", it gets renamed into the parent label.

    You can use this concept to identify the state (stage) of a revision. Imagine the following very simplistic promotion model:

    Development -> Ready for QA -> QA -> Ready for Production -> Production.

    When a developer is done with a given file (stage Development) he can click promote and the group moves up a level to "Ready for QA". The QA manager can now promote from "Ready for QA" into "QA", accepting the newly updated file and run tests after performing a get on all files at the "QA" stage or higher (meaning an unchanged file without the "QA" group associated with it would be fetched using the revision that is associated with group "Ready for Production" or "Production", which is something VM can do automatically by performing a Get on a promotion group).

    Once QA has accepted the changes, the file gets promoted again to "Ready for Production". Now the person in charge of production data can promote files at this stage into "Production" and perform a get on this group, updating the files in production.

    Promotion groups are generally volatile in that they describe the stage of a revision in a file. You would still assign permanent version labels to be able to go back in time and find out which revision would be associated with "Product Release 1.0". Such labels you could create once the files were promoted to "Production", by assigning a label to all revisions in files that are associated with this promotion group.

    Promotion groups can be used to change the security model that Version Manager uses, meaning you can prevent someone in Development from promotion into Production by limiting at what stage in the promotion model developers can promote. Explaining this in detail will take some time, so I'm just posting it here as a note.

    Using promotion groups can make simultaneous development on different revisions in an archive (branches) a bit more complicated, as each revision being checked out will need its own unique lowest level promotion group. If you need this you will need to have multiple lowest levels groups. A possible model could include the lowest level "Bugfix", so that group and "Development" could be associated with different revisions.

    Hope this wasn't too overwhelming. If you need me to elaborate on anything, please let me know.

    Kind regards,

    - Richard.
Children
No Data