I wish that I had the foresight to be that organized and disciplined!
I’d put my foot down as far as I could.
If it’s still decided that they are going to develop in a soon to be legacy system,
then a detailed list of changes needs to be provided to you, on a regular basis.
But did you die
I’m going to push back a little bit here on @klincecum, @Banderson, and others I HIGHLY respect.
“Code” comparison will come in handy in more places when we get “source code” and revisions involved. I am thinking way beyond screen customizations when I talk about this DevOps crap.
Since REST came onto the scene, we can - for the most part - represent most Kinetic objects in JSON (with some embedded XML but put that aside for now). Take RDL for example, if I can get the vanilla representation of the system RDL in source control, I can compare one version of that RDL to my customized version. I can compare the current system RDL version to the previous Kinetic version to see if Epicor has changed it. If not, I probably won’t have that much work to get it to run in the next version.
I can do the same with:
- SSRS .RPT files (XML)
- Report Styles
- Data Dictionary (ZData tables)
- Business Object Definitions
- Menu items to see if Epicor moved or renamed something
- Added or deleted System BAQs
- Even Kinetic UI layer changes that Epicor has shipped
Why wait and hope for Epicor to tell us what changed when we can see it with our own eyes?
And if I have these items external to the instance, I can now do controlled installation of changes from environment to environment instead of the Pet building that the current toolset promotes. I can do a simple search to find everywhere I used a particular field in a Linq statement or some SQL reserve word that has to change (e.g. XML FOR) with an SQL Server upgrade.
I can also use source control to monitor changes to:
- Reason Codes
- Account Numbers
- UD Codes
When I can export these things, I can manage the state of my instance. I can know:
- if a directive was disabled
- Somebody imported an outdated version of a customization
- a user is granted Security Manager or Impersonation
- an API key was added or is going to expire
- BAQs without Security IDs
- all the things we need to do to prove we have control over our system during a SOX audit.
And I even didn’t get started with using APIs to encapsulate logic and test. And speaking of testing, use automated tools to run our business logic to check upgrades.
I’m suggesting that this process of managing “cattle” I am describing - which is used by Microsoft, Google, Amazon, etc. - might have some advantages over the Pets we continue to build in ERP systems.
And no, I haven’t started drinking…
But it’s St. Patty’s Day…
I’m Polish, among many other non-Irish things.
No need. I agree with you.
Watch out now!
Well, yeah, I respect and appreciate all of you guys. Otherwise, I wouldn’t bother explaining or arguing my case!
I’d just ignore you!