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?
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!
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 :-)
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.
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.
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.
Excellent information Stu and thanks very much for that.
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.
Good point Julian.