7 Replies Latest reply on Jan 28, 2013 1:06 PM by dmshimself

    Test to Live - how to lock Live down?


      This new pack looks like a very useful suplement to design transfer.  A few questions if I may?


      1. The manual rightly warns against making changes to reference data in live after the snapshot to dev/test has been made.  It talks about synchronising up; would it be posisble for someone to expand on what actually happens?  e.g. someone creates a new category in live that doesn't exist in test.  Incidents are logged with it.  What happens when Test to Live is run?  If both categories are created in LIVE and TEST for operational reasons, are they seen as being the same if created manually?  If a regular DT is used to take such a category across from TEST to LIVE, would both be seen as the same?


      2. This pack supplements DT - so are there any plans to allow DT to transfer all the items Test to Live does?  For those of us producing designs offline for a variety of customers, it would very useful to know if LD plan to allow DT to transfer business object reports and other items it doesn't currently handle.


      3. Would it be seen as best practise to restore PROD to DEV and TEST, do the dev in dev, sync dev up to test, do UAT in test and then finally sync DEV to PROD?  This would ensure any glotchas are well rehersed before touching PROD?


      4. Does Test to Live handle changes to user interface properties in BOD?


      5. Does Test to Live handle Business Object reports?


      6. In general how does it spot differences?  For example if a category was renamed in TEST (not uncommon) is the same category renamed in PROD?  If a query is renamed would be another example.


      7. Is there a list of items it doesn't handle so we can manually attend to those?


      8. Is any sort of report produced as part of the migration?


      9. Is this a supported module?  In the social pack, the chat app itself wasn't supported, so I just wanted to get some idea of the status of this pack if used against (say) 7.5.

        • 1. Re: Test to Live - how to lock Live down?

          8. The report it produced is at the database level, so if you want to know what queries have been pushed across or what processes have been synched etc, then this utility will not supply that information.  As a general comment and perhaps looking to the future, that makes this utility slightly limited in value on it's own as the majority of our customers want a list of changes that are going to be applied as part of their change control.


          10. Is there a way of locking down PROD so changes channot be made to PROD even by an administrator who thinks they know better?


          11. Can the utility be used while people are logged in to PROD?  This helps reduce the scope of outages.


          12. Does it handle User Dashboards and Queries?


          13. Does it handle crystal report configuration?


          14. How do I set Test to Live up to work with Oracle?


          15. Do we need to recycle the application pool/iisreset after the sync?


          16. If changes have been synched to SLAs does the background service need to be restarted?


          17. Does Test to Live handle changes to mail mappings?  The documentation refers to settings in the Mail component being OK, but I realise this might refer to just logins/password.  So some guidance on synching all the mail manager configurations changes appreciated.  In any case does inbound/outbound email need to be restarted?


          18. Does it deal with business objects knowledgeable-ness and search layouts?


          19. Does it deal with schedules in schedule manager?

          • 2. Re: Test to Live - how to lock Live down?



            Thanks for posting these up and hope you get a response.  We've been quite excited at the prospect of Test to Live being released however never thought of some of the implications/restrictions that you have detailed above.


            Looks like we could end up doing a Test to Test a few times just to see what exactly happens and get to grips with it!



            • 3. Re: Test to Live - how to lock Live down?

              Cheers Helen. We have quite a few clients over here who have really strong change management and so I've had the opportunity to learn from several ITIL masters the best practise approach to changes on big/live/critical infrastructure systems.  So some of the thoughts above are from conversations with them, but 1 or 2 are my own :-)

              • 4. Re: Test to Live - how to lock Live down?
                Stu McNeill Employee

                Hi Dave,


                Thanks for the questions   I'll see how many I can answer!  I'm looking to write some documents on this new feature but you have beaten me to the punch... I'll also pass your questions on to PM so documentation can be updated if required.


                1. The synchronisation is at a SQL level and looks at all areas related to design.  In the case of a category if you created this in live (which you should not do after creating the test system mirror!!) T2L would try to delete it - as far as it is concerned it could have existed in both Test and Live but deleted in Test as part of your design changes.  If it cannot delete the category due to it being referenced then the synchronisation will fail and the logs will give you details on why.


                2. T2L and DT are totally independent on each other.  They answer two different questions so while they have an overlap they are not really related so both will be enhanced in their own ways.


                3. Yes it certainly would be best practice and this is something I'm hoping to write about more.  Basically though the steps would be a. restore live to dev, b. work in dev, c. restore live to test, d. T2L to test, e. test the transfer (and as quickly as possible so the test db is less likely to change from live), f. T2L to live.


                4. Yes.


                5. Yes.


                6. Yes any differences will be synchronised.


                7. Not yet unfortunately.  By definition there should not be but I'm sure we'll find some!  If you look at the log you will see the tables being synchronised - a couple of those will have some filtering on them to only sync certain rows but in general if you want to check if something is going to be synced just look to see if its table is in the log.


                8. There is the log but nothing about the specific changes.  Because it is designed at the SQL level the changes are not really available in a product-friendly way.  Also there could be thousands of changes so any report would quickly become huge (for example the number of records over various tables that make up a single process).  The general rule is that EVERYTHING design related is moved so the specifics aren't as important.


                9. Yes it is supported against 7.4, 7.5 and once released 7.6 (although there may be an updated version of T2L at that point anyway).


                10. Not just yet....


                11. Live should be free to accept design changes exactly as you would with DT.  Because the changes are directly in the database it is the same as if the changes are made from a Console looking at Framework A while other users are connected to Framework B or Web Access.  They will pick up the changes automatically as best as possible but usual design change rules apply.


                12. User dashboards, queries and shortcuts are NOT synhcronised.


                13. Yes.


                14. T2L is only supported on SQL Server at present.  This was unfortunately missed from the first version of the documentation but that has already been amended for the 7.6 release.


                15. See #11.


                16. See #11.


                17. By default mail configurations will be synhcronised.  If you want to change an existing mailbox/outbound settings after creating the Test system (for pointing to a test mailbox) then T2L will ask if you want to keep the changes or not.  New mappings, etc. would still be synhcronised though.


                18. Yes.


                19. Yes.



                • 5. Re: Test to Live - how to lock Live down?

                  Excellent information Stu and thanks very much for that. 

                  • 6. Re: Test to Live - how to lock Live down?
                    Julian Wigman ITSMMVPGroup



                    Things concerning me:


                    In DT we were not allowed to overwrite certain objects in the destination.  Processes being one for example.    So what happens now if we snapshot Live back to Dev,  clear down all transactions,  remove a status that otherwise would be in use in the Live process,  then try to sync the updated sesign back into Live again.  DT would have stopped us doing this but what does TTL do;  assuming it's going to error.   Then what does it roll out all changes and revert or is it restore from backup time?


                    Clearing out data in DEV/TEST versions of snappshotted DB's is not uncommon expecially if the data is sensitive outside of the LIVE environment so I am seeing some dangers here.



                    • 7. Re: Test to Live - how to lock Live down?

                      Good point Julian.