Topic
  • 9 replies
  • Latest Post - ‏2013-09-26T14:15:41Z by alspaugh@us.ibm.com
PKD
PKD
5 Posts

Pinned topic Release Management - Collaboration server

‏2013-09-03T13:28:46Z |

Hi,

We are new to Infosphere MDM Collaboration Server. We use this for Product Information Management.

Wanted pointers on the standard release management process\best practice for MDM Collaboration server:

* how the code changes\releases can be moved from Dev to Test to QA to PROD environments

Updated on 2013-09-03T13:29:07Z at 2013-09-03T13:29:07Z by PKD
  • Rocky_01
    Rocky_01
    32 Posts
    ACCEPTED ANSWER

    Re: Release Management - Collaboration server

    ‏2013-09-05T09:22:22Z  
    • PKD
    • ‏2013-09-05T05:15:16Z

    If this is the case, then it is a serious limitation of the product.

    This form of release management process will not get endorsed in an enterprise scenario.

    Hi,

    For migrating the data model and associated modules, you can take the help of Environment Export/Import facilities.

    Environment Export creates a zip file then you just need to Import the zip file on your new environment and you are Done :)

    Path:

    System Administrator > Selective Export/Import

     

    Thanks,

    Rocky

  • KaranBal
    KaranBal
    108 Posts
    ACCEPTED ANSWER

    Re: Release Management - Collaboration server

    ‏2013-09-05T16:41:18Z  
    • PKD
    • ‏2013-09-05T05:15:16Z

    If this is the case, then it is a serious limitation of the product.

    This form of release management process will not get endorsed in an enterprise scenario.

    FYI: Environment export/import will create or update all of the data in the data structure selected e.g. it will create/update all the hierarchies or ACGs from one environment to another and does not allow you to limit it to certain customizations as I thought you meant.

    Therefore environments between which you're transferring back and forth must be in synch already before transferring customization. One way to ensure this is to transfer everything from production to QA/Dev, then make customizations in QA/Dev and test them thoroughly. When you're satisfied, move them to production. Ensure that there are no unwanted elements in QA because if there are, then they will be created in production as well. That is why, this is usually used to transfer from production to QA and not the other way round.


    There is extensive documentation available for this in the information center and you should review it for details on how this works.

  • Alexander_Zinovin
    Alexander_Zinovin
    93 Posts
    ACCEPTED ANSWER

    Re: Release Management - Collaboration server

    ‏2013-09-10T05:21:13Z  

    it is not necessary to use Environment Export to generate an export file because of multiple dependences you should consider. You can create a export file yourself with necessary objects via a script and import them into the production env. For example, the script below generate an export file including all scripts.

    var envObjList = new EnvObjectList();
    envObjList.setTypeToExport("DOC_STORE");
    envObjList.addObjectByNameToExport("/scripts/triggers/", null, "CREATE_OR_UPDATE");
    var result = exportEnv(envObjList, "script_20130214.zip");
    out.println("result: " + result);
     

  • KaranBal
    KaranBal
    108 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-03T21:59:46Z  

    The best resource on how to upgrade is the following section of the information center (drill down) as per your need:

    http://pic.dhe.ibm.com/infocenter/mdm/v10r1/topic/com.ibm.pim.mig.doc/pim_con_migratingcontainer.html

    But I am not sure I completely understood your last comment about moving code change/release from Dev to test and so on. It's a new install on each of these servers and there's no dependencies; apart from practice and testing.

  • PKD
    PKD
    5 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-04T04:58:34Z  
    • KaranBal
    • ‏2013-09-03T21:59:46Z

    The best resource on how to upgrade is the following section of the information center (drill down) as per your need:

    http://pic.dhe.ibm.com/infocenter/mdm/v10r1/topic/com.ibm.pim.mig.doc/pim_con_migratingcontainer.html

    But I am not sure I completely understood your last comment about moving code change/release from Dev to test and so on. It's a new install on each of these servers and there's no dependencies; apart from practice and testing.

    I am not talking about migration out here; we are already on v11.

    As part of the standard SDLC process; PIMS was set up in Dev environment and the necessary customizations were done.

    Now we need to move this customized version of PIMS from Dev to QA for user acceptance and henceforth to Prod.

    The basic installation will be done; but what is the standard process to move the customizations.

     

    Post GoLive, anytime we need to do any futher customizations - like adding new business rules, changes in the workflow, additional Java API based changes - it needs to go through the same lifecycle of quality assurance - from Dev to Test to QA to Prod.

    Wanted to understand the standard process \ best practice of achieving the same in case of Infosphere MDM Collaboration server PIMS.

  • KaranBal
    KaranBal
    108 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-04T18:19:56Z  
    • PKD
    • ‏2013-09-04T04:58:34Z

    I am not talking about migration out here; we are already on v11.

    As part of the standard SDLC process; PIMS was set up in Dev environment and the necessary customizations were done.

    Now we need to move this customized version of PIMS from Dev to QA for user acceptance and henceforth to Prod.

    The basic installation will be done; but what is the standard process to move the customizations.

     

    Post GoLive, anytime we need to do any futher customizations - like adding new business rules, changes in the workflow, additional Java API based changes - it needs to go through the same lifecycle of quality assurance - from Dev to Test to QA to Prod.

    Wanted to understand the standard process \ best practice of achieving the same in case of Infosphere MDM Collaboration server PIMS.

    There isn't a process per se for moving customizations from one environment to the next. In fact in most cases, they can't be moved between PIM instances and we need to start from scratch in production.

    So just test the customizations in QA and then make the changes in the exact same way in production. If you've tested these changes thoroughly in QA, then you can deploy it in production without testing specifically in production because the behavior should be the same; assuming QA is a replica of production.

  • PKD
    PKD
    5 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-05T05:15:16Z  

    If this is the case, then it is a serious limitation of the product.

    This form of release management process will not get endorsed in an enterprise scenario.

  • Rocky_01
    Rocky_01
    32 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-05T09:22:22Z  
    • PKD
    • ‏2013-09-05T05:15:16Z

    If this is the case, then it is a serious limitation of the product.

    This form of release management process will not get endorsed in an enterprise scenario.

    Hi,

    For migrating the data model and associated modules, you can take the help of Environment Export/Import facilities.

    Environment Export creates a zip file then you just need to Import the zip file on your new environment and you are Done :)

    Path:

    System Administrator > Selective Export/Import

     

    Thanks,

    Rocky

  • KaranBal
    KaranBal
    108 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-05T16:41:18Z  
    • PKD
    • ‏2013-09-05T05:15:16Z

    If this is the case, then it is a serious limitation of the product.

    This form of release management process will not get endorsed in an enterprise scenario.

    FYI: Environment export/import will create or update all of the data in the data structure selected e.g. it will create/update all the hierarchies or ACGs from one environment to another and does not allow you to limit it to certain customizations as I thought you meant.

    Therefore environments between which you're transferring back and forth must be in synch already before transferring customization. One way to ensure this is to transfer everything from production to QA/Dev, then make customizations in QA/Dev and test them thoroughly. When you're satisfied, move them to production. Ensure that there are no unwanted elements in QA because if there are, then they will be created in production as well. That is why, this is usually used to transfer from production to QA and not the other way round.


    There is extensive documentation available for this in the information center and you should review it for details on how this works.

  • PKD
    PKD
    5 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-06T04:22:47Z  
    • KaranBal
    • ‏2013-09-05T16:41:18Z

    FYI: Environment export/import will create or update all of the data in the data structure selected e.g. it will create/update all the hierarchies or ACGs from one environment to another and does not allow you to limit it to certain customizations as I thought you meant.

    Therefore environments between which you're transferring back and forth must be in synch already before transferring customization. One way to ensure this is to transfer everything from production to QA/Dev, then make customizations in QA/Dev and test them thoroughly. When you're satisfied, move them to production. Ensure that there are no unwanted elements in QA because if there are, then they will be created in production as well. That is why, this is usually used to transfer from production to QA and not the other way round.


    There is extensive documentation available for this in the information center and you should review it for details on how this works.

    Thanks Rocky and Karan; this definitely gives me a good start. I will read it up in details.

  • Alexander_Zinovin
    Alexander_Zinovin
    93 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-10T05:21:13Z  

    it is not necessary to use Environment Export to generate an export file because of multiple dependences you should consider. You can create a export file yourself with necessary objects via a script and import them into the production env. For example, the script below generate an export file including all scripts.

    var envObjList = new EnvObjectList();
    envObjList.setTypeToExport("DOC_STORE");
    envObjList.addObjectByNameToExport("/scripts/triggers/", null, "CREATE_OR_UPDATE");
    var result = exportEnv(envObjList, "script_20130214.zip");
    out.println("result: " + result);
     

  • alspaugh@us.ibm.com
    alspaugh@us.ibm.com
    3 Posts

    Re: Release Management - Collaboration server

    ‏2013-09-26T14:15:41Z  
    • KaranBal
    • ‏2013-09-04T18:19:56Z

    There isn't a process per se for moving customizations from one environment to the next. In fact in most cases, they can't be moved between PIM instances and we need to start from scratch in production.

    So just test the customizations in QA and then make the changes in the exact same way in production. If you've tested these changes thoroughly in QA, then you can deploy it in production without testing specifically in production because the behavior should be the same; assuming QA is a replica of production.

    The statement is not true. Environment export/import can be used to move from one environment to another. Doing development directly in production is very dangerous let alone bad practice.

    I have used environment export/import extensively and exclusively for migration from dev to test to prod with no issues.