Play Book Tool for production Environment RRS feed

  • Question

  • Hi,

    We have EPM -2010 environments in production and on and off it is required to create many custom fields and change/edit/update various look –up level structure.

    It very time consuming and monotonous work and since need to follow all three (Development, QA, Production) cycle .we though to use play book migration tool to reduce our precious time but when tried to ran the tool in development it turned out to be some malicious entry for older data with some prefix in case of merge but in case of replace it use to add value.


    • Can it be used in Development àQAà Production cycle with effecting existing data for custom field migration? 
    • In case of yes with what option (Merge/Replace) it is most reliable.


    Vipin Upadhyay

    Tuesday, December 31, 2013 5:43 AM

All replies

  • Hi Vipin,

    Yes, you can use it. You can select the specific element from setting while back up and restore which is new or which you have changed .

    Xml file which will be the output you can restore in any server means DEV-->QA-->Prod

    Use merge when you want to add new element (look up ,custom field, view etc)

    Use replace when you want to replace any element Means all the values of current server will go away and new setting will sit on server.

    • Merge: This option is typically used when you are moving from one test environment to another to collect the list of settings that you want. An example of a merge going from the backup file to the target server and its result is shown here:

      Backup file Target Server Result

      View A

      View C

      View A

      View B

      View B

      View C

      In this table, the Backup file contains Views A and B from the initial Project Server 2010 instance. Selecting the Merge option results in the new Project Server 2010 instance that contains the views from the Backup file (Views A and B). It also contains the existing views that were on the Project Server 2010 instance to which the backup file was restored (View C).

    • Replace (where it is possible): Use this option when the data in the backup file takes precedence over the data in the target server. This could be used when you are rolling out data from a test environment to a deployment where the items in the backup file represent the final status of the server. The example here shows what happens when you do a replace operation:

      Backup file Target Server Result

      View A

      View C

      View A

      View B

      View B

      In this table, all existing views on the target server on which the Backup file is restored (View C) are replaced by the views contained in the backup file (Views A and B).

    • Note:- Custom Fields, Lookup Tables, and Security Categories use the merge strategy.


    • Edited by Kirteshtiw Tuesday, December 31, 2013 6:58 AM
    Tuesday, December 31, 2013 6:57 AM
  • Vipin,

    This is a bit off topic to your question but relevant as you are there with the cross environment configuration maintenance pain. Time consuming is an understatement.

    I started with Playbooks but quickly outgrew it when attempting to manage 3 PWA instances across  Dev/QA/Prod/DR environments. For example, there was no way in Playbooks to update a single custom field. It was all or nothing. There were other issues we ran into that led us to look elsewhere.

    We also had audit requirements and trying to document was a monumental effort. We tried out and finally purchased FluentBooks to do this work. It offered greater flexibility and more functionality. If you haven't looked at it, you should. I think it's worth its weight in gold.

    SharePoint has similar tools as well as we also hit issues keeping SharePoint configuration in sync across environments. Something else to consider for budget time.

    Hope you find this relevant.


    Treb Gatte, Project MVP | @tgatte |

    Tuesday, December 31, 2013 10:23 PM
  • Agree with Treb that FluentPro is the option to go for if you plan to do this a lot. 

    That being said, I prefer to manually promote changes into PROD.  It's usually not so onerous to do - and doing so manually saves me time on the back end doing verifications, etc. to confirm the tool did what it was supposed to and didn't break anything.

    I usually build fresh in QA, use Playbooks to move the initial settings across - and then manually promote afterwards - unless I am redoing almost the entire system.

    Andrew Lavinsky [MVP] Blog: Twitter: @alavinsky

    Wednesday, January 1, 2014 10:07 PM