I’m very much behind the times and just recently happened to come across the posting where you released the Trace Viewer to the group. Thank you very much! It’s a very useful tool!
I am in the middle of working toward migrating a ton of classic client customizations and BPMs into the Kinetic environment for my employer. I’ve needed a way to compare customization and BPM code between the production environment and my Kinetic environment.
I have queries developed that pull the code from the XXXDef and BPDirective tables of the respective environments. Initially, I was trying to pull the data into Excel and use data transforms to do the code comparison, which almost worked, although incredibly, incredibly slow, but then I discovered that several of the customizations and BPM code are large enough that they exceed the size of an Excel cell
So, I’ve been pondering another method for doing this. When I saw your user interface for the Trace Viewer, it struck me that it was very close to what I need.
What I would like to know is how you constructed the Diff viewer. Is that based on some library that is available, or is it all custom code that you developed yourself?
I’ve pondered how to extract the information in some format where I could pull it into something like WinMerge, but that seems like it might be pretty messy, if it’s possible at all.
Any insight that you or any other member of the community might be able to provide would be greatly appreciated!
You are correct. It would be overkill if I was in a situation where I could do the migration and everything in the production environment remained static. Unfortunately, the company elected not to freeze new development, so I’m trying to hit a moving target. I need a workable way to see the differences in the environments. It isn’t the ideal way to do a migration, but I have no control over it, so I have to find ways to make it work.
Required statement of how having a user DevOps framework would help you and the rest of us manage migrations… Add a comment on how it would help - and vote if you feel the need.
I tried and found that I’m not set up to log in to Epicor Ideas and my “domain won’t permit me to self register”. But it looks like it automatically submitted at ticket for login assistance, so hopefully I will be able to vote soon!
I don’t think he’s talking about web UI @klincecum . It’s he’s trying to compare code, those are apples and oranges. It’s got to be classic customization.
My recommendation is do a test upgrade, run all of the conversions, verifications, and see what breaks. Make a list of those and document the fixes. Then any new developments that you do between then and upgrade, you keep track of so you have a smaller list to attack.
I’m assuming you aren’t developing new functionality in the upgraded system, right? You would just be making new functionality in the old and making sure you have parity in the upgraded system.
No. Just Classic stuff. The intention is to get all of the classic customizations working in Kinetic first. Once we have a Kinetic environment in production, we will start customizing our classic stuff and trying to replace it at the same time!
That being said, what is the reason behind the need to compare code? It should have come over in your upgrade, and the only real differences should be the things that you need to fix due to the upgrade. I’m not understanding the need to compare the code…
As I said in my reply to Jose, the production environment is continuing to have changes made to it. They didn’t freeze new development just because they’re trying to do a migration. Your common sense assumption that nothing has changed on the production side is not true here.
No, that’s not my assumption. My assumption is that production is the old system. You can check how everything upgrades in a test upgrade, and make a list of the changes you need to make for everything current, then from them forward, keep documentation on the new changes so you know which things will need to be looked at when you do upgrade, or if it’s long enough, on your next test upgrade.
The upgrade conversions will make a list of what things are broken. You will have to upgrade your old system into your new one, and at that point everything will “match” and you need to make the upgrade related changes into your “new” production system.
Comparing the code from one system to another isn’t any faster than running “Verify All” in customization maintenance.
You’ll have so much noise from stuff that was Auto Upgraded, that you won’t be able to use a diffchecker to even tell you want you need to look at.
You can run through a whole uprade cycle in an afternoon. So if you’re trying to keep your testing and prod systems in sync, just restore the database and run the upgrade.
Unless these fixes or customizations are super complicated, I think you would be better served by recording errors between upgrade passes, and if something significant comes up, make a note of it.
You’ll be able to research the fixes in the meantime and make notes.
If they make more changes, your errors list (may) change, so there is your comparison.
They are super complicated, or I definitely wouldn’t bother with this. I’ve had to do most of it manually. These customizations are massive, tons of C# code. The upgrade process converts very few of the customizations and BPMs in this system automatically.
So, we did the initial conversion. Tons of stuff to fix. It took me a while. But I finally got everything that was “obviously” broken working. I created solution files to save all of my fixes so that they could be restored on the next pass.
We do a fresh update. I load my solution files. And… I find that many of the items that I fixed and stored in the solution files are obsolete because the code had been changed on the production side, didn’t automatically convert, and now I get to make all of the same changes all over again to the newer code. Then the business analyst starts testing and finds more things that are broken, so I fix all of those.
Then the cycle repeats itself.
I just don’t see any solution but to make sure that my fixes and the production environment are synced up with the most current code in Kinetic before I go through another cycle.
I appreciate all of you guys trying to tell me that I don’t need to do this, but I just don’t see any other way around it. In the company(s) that I worked at before, what you are saying makes absolute sense, because the customizations simply weren’t as widespread and massive.
@mccoyjf
What we did for our upgrade was as follows
Upgrade System
Fix Customization and write documentation of what was fixed (code snippets that were changed etc)
Repeat Step 1 and apply “notes” from Step 2 as needed
That worked rather well because any changes that were made on the production system were generally cosmetic (or new functionality) so we were able to quickly go to the spot in the code where we had made tweaks and copy / paste in our changes. See below from our documentation.
We notated what was there Old and what we changed “new” then we are able to quickly jump back and apply the changes. This makes it so that any UX changes (moved buttons around) don’t have to be re-done and it allows us to quickly iterate.
I suspect your approach of comparing Code is going to be quite difficult both to implement and to execute because just a few extra spaces in the wrong place and your entire document will look “changed”
Obviously you do you but just throwing out there an approach that worked well for us and allowed us to be flexible and nimble without over-engineering.
