Hi, I actually have developed functionality in RRR|Chive for using other field(s) as primary key instead of the Request ID field, but I never got it to the point where it was 100% functional. Probably because I have not needed it myself in any consulting job yet. The problem with RRR|Chive is that it has proved hard to charge money for it, which in turn limits the amount of time I can put on it...
Best Regards - Misi, RRR AB, http://www.rrr.se (http://www.rrr.se) (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs Find these products, and many free tools and utilities, at http://rrr.se (http://rrr.se) February 15, 2017 12:49 AM, "Jason Miller" wrote: **Good point about full DB restores from prod. I left that out. Yes, after we restore a DB from prod, then we use Migrator :) We are supposed to restore quarterly however it usually works out closer to twice a year. Even then we have a good enough process that Migrator does very well because our environments are still largely in sync. It is often the data that is too far out of sync instead of the objects if we go too long between DB refreshes. I occasionally sync data using RRR:|Chive from prod however since it is based on Request ID we often have duplicate config records with different Request IDs. Of course the sync option would take care of dupes however sometimes new config records are legitimate as development efforts progress. Some config is managed by our Service Desk and while they typically add/change config in dev --> QA --> prod they do it manually so the Request IDs vary. We have talked about setting up a promotion process based on RRR:|Chive so they can add/update config in dev and promote it forward but it is at the bottom of the to do list. I remember when I first started using Migrator and didn't really think about all required objects. Our test system was so far out of sync with production that it blew up production by migrating way more (bad) objects than what was needed and we had to restore the prod DB from backup. Ever since then I have been respectful of Migrator and treat it like a loaded gun. Jason On Tue, Feb 14, 2017 at 8:39 AM, Brian Pancia wrote: ** Everyone, Thanks for all the feedback. I've been messing around with a lot of these tools the last couple weeks. I've seen some very interesting results. Migrator - When comparing our test system with our production system using migrator. The process is extremely slow. This is because the systems have never been synced with each other since they were upgraded 6 months ago. There are a lot of code and data differences between the two systems. Migrator does work though and it is nice to see what the differences are in the difference reports. RRR Tools - rrrExport and rrrImport are a lot quicker than Dev Studio when importing large amounts of code. I think both work fine and I didn't see huge benefits of one over the other. There were minor pros/cons to each. If you're hard core command line the simplicity of rrrExport and rrrImport are great. One issue I did come across with rrrImport was with overlays. Some of the forms with overlays didn't come over right. - rrrDefDiff - this tool was interesting. It seems to go off the last modified date. Migrator is a lot slower because it will show a difference even if a field moved over a pixel, I believe. rrrDefDiff doesn't give a lot of report functionality other then with there was a difference or if it was on source or target only. I ran this multiple times after importing differences and the counts actually seemed to go up after importing differences. I expected the difference counts to go down. -rrrchive - this is a good tool to move data. I've used this many times and it works really well and is extremely robust on the configuration. Haven't messed around with AR System Deployment Management yet. Mark - I will have to look into the tool you mentioned. I've seen a lot of Remedy implementations over the years that have dev/test/prod/coop environments that aren't even remotely close to each other. Most of this is a process issue and not necessarily a tool issue. I have a bunch of systems that haven't been synced in 6 months, which makes all but production worthless. All the tools above would take a long time to sync the systems. I think I need to do a full database backup/restore of all the systems, put a strong process in place, and then use a combination of the above tools to ensure the systems stay in sync. There should be differences in all the systems but for test/prod/coop the differences should be minor. Throw multiple developers across multiple groups and it can cause some headaches. I think ideally I would use the following steps: - Backup production and restore to Test and COOP - Backup any development code from dev, restore prod to dev and import development code using Dev Studio - Now that all systems are in sync, except for the new dev code, I would setup replication at the database level between COOP and Production using MS SQL replication tools - Test I would setup a nightly sync of data using rrrchive of selected forms from Prod to Test and then do a full database restore after major releases. - Dev full database restores would happen on an as needed bases, probably at least quarterly - For release packages AR System Deployment Management looks like the best tool. However, without testing fully it is yet to be determined. Both AR System Deployment Management and Migrator have rollback capabilities, so I would probably opt for the them over the different combinations of RRR Tools. - Setup a nightly batch job on all the environments using rrrexport and rrrdefdif and review the results list daily. This will allow us to identify any potential changes that happened in one environment that didn't follow the process. Thanks again, Brian ------------------------------------ From: Action Request System discussion list(ARSList) on behalf of Mark Herring Sent: Tuesday, February 14, 2017 4:29 AM To: arslist@ARSLIST.ORG (mailto:arslist@ARSLIST.ORG) Subject: Re: arslist Digest - 12 Feb 2017 to 13 Feb 2017 (#2017-38) ** Hi Brian, I’ve not tried the Deployment Tool but if you’re looking for a comprehensive easy to use migrator tool with a friendly UI, take a look at ITSMBridge. It includes a difference report to compare servers, pre-built templates to migrate selected ITSM applications (foundation and/or transaction data) and options to migrate between different AR/ITSM versions or from external SM platforms like Service Now to BMC Remedy. HTH Mark On 13 Feb 2017, at 23:00, arslist automatic digest system wrote: There is 1 message totaling 560 lines in this issue. Topics of the day: 1. Migrator Tool _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org (http://www.arslist.org) "Where the Answers Are, and have been for 20 years" ---------------------------------------------------------------------- Date: Mon, 13 Feb 2017 13:19:15 +0000 From: Brian Pancia Subject: Re: Migrator Tool Misi, I've been playing around with your tools and as always they are pretty awesome. There's a new tool in ARS 9.1 called AR System Deployment Management that looks pretty promising. Messing around with Migrator was painful just like I remembered. It looks like the deployment tool will end up replacing Migrator. Another toy to add to the tool box. I'm sure there are a few kinks that need to be worked out of the deployment tool, but I'll give it a go to see how it works. I'm curious to see anyone else's experience with the deployment tool. Thanks again, Brian ________________________________ From: Brian Pancia Sent: Friday, February 10, 2017 8:14 AM To: arslist@ARSLIST.ORG (mailto:arslist@arslist.org) Subject: Re: Migrator Tool Awesome. New toys to play with. I'll have to play with different scenarios depending on the source and destination servers. I'm thinking monthly syncs to dev and weekly syncs to test for code. I may do weekly data syncs to both environments. In theory Prod and Test should be locked down, preventing development directly from there, but that's a different beast to tackle. I guess RRRDefDiff will be a good way for me to tell if updates are being made to Prod or Test without going through Dev>Test>Prod sequence. Batching that process out may be interesting to see if developers aren't following the proper process. For a COOP environment I'm thinking using SQL replication is probably the best bet. With replication I can do near real time updates. Brian ________________________________ From: Action Request System discussion list(ARSList) on behalf of Misi Mladoniczky Sent: Thursday, February 9, 2017 1:37 PM To: arslist@ARSLIST.ORG (mailto:arslist@arslist.org) Subject: Re: Migrator Tool ** Hi, Why not try a combination of RRR|ExportDef, RRR|DefDiff, RRR|ImportDef and RRR|DeleteObject. The important one is RRR|DefDiff, mening that you can use other tools to export/import definitions and delete surplus objects. https://rrr.se/cgi/tools/main?tool=rrrDefDiff (https://rrr.se/cgi/tools/main?tool=rrrDefDiff) RRR|DefDiff rrr.se (http://rrr.se) RRR|DefDiff updated 2015-06-16 Finds differences between two def-files https://rrr.se/cgi/tools/main?tool=rrrExportDef (https://rrr.se/cgi/tools/main?tool=rrrExportDef) RRR|ExportDef rrr.se (http://rrr.se) RRR|ExportDef updated 2012-11-23 Exports definition files from your server https://rrr.se/cgi/tools/main?tool=rrrImportDef (https://rrr.se/cgi/tools/main?tool=rrrImportDef) RRR|ImportDef rrr.se (http://rrr.se) usage: rrrimportdef [ -l error.log ] [ -e error.def ] [ -verbose ] [ -silent ] server tcpport user password import.def usage: rrrimportdef -help https://rrr.se/cgi/tools/main?tool=rrrDeleteObject (https://rrr.se/cgi/tools/main?tool=rrrDeleteObject) Best Regards - Misi, RRR AB, http://www.rrr.se (http://www.rrr.se) (ARSList MVP 2011) RRR|Home www.rrr.se (http://www.rrr.se) RRR|Log Fix specific performance problems or work proactively with performance by using RRR|Log. It will help you make sense of the information in the Remedy log ... Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs Find these products, and many free tools and utilities, at http://rrr.se (http://rrr.se) RRR|Home rrr.se (http://rrr.se) RRR|Log Fix specific performance problems or work proactively with performance by using RRR|Log. It will help you make sense of the information in the Remedy log ... February 9, 2017 5:52 PM, "Brian Pancia" wrote: I'm blowing off the dust on BMC Migrator. It has been years since I've messed with it. I've used it in the past to migrate small amounts of code from dev to test to production. What I'm looking at now is using it as a sync tool between the environments for code only. I've usually just done a database backup and restore in the past and for small code migrations I just export/import .def files. There are definitely pros/cons to all these methods. My plan now is to use RRRChive to migrate data updates and BMC Migrator to do code migration. This will give me much more control then a simple database backup and restore. Is anyone currently taking this approach between dev/test/prod. We're using MS SQL 2012 on the backend, which I'll use database replication between prod and coop. Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org (http://www.arslist.org) "Where the Answers Are, and have been for 20 years" ------------------------------ End of arslist Digest - 12 Feb 2017 to 13 Feb 2017 (#2017-38) ************************************************************* _ARSlist: "Where the Answers Are" and have been for 20 years_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
