Buried in the calendar for the upgrade is a critical step that some may miss.
The pilot database will be written over by live database.
This is so everything you have in Live will be tested with the upgrade.
Downside, if you are working on something in PILOT - it will be gone.
This is definitely one of the reasons we (including Epicor) should start to think about DevOps (SecDevOps) practices. Customizations should be committed to source control and then moved into some environment (staging/test/pilot/prod/…). This prevents this issue and makes rebuilding a system soooo much easier if the need arises.
Each commit in Git calculates a hash (SHA-1 but soon SHA-256). If Epicor determined the unique characteristics for each type of modification (BAQ, EFx, Directive, etc.) and used those to calculate the same hash, then we could use REST to upload the artifact and tag it with the hash. It would require some thought but it should be possible.
I think the whole Git thing needs to be another thread, I see those sources and builds folders under the BPM folders on the server, interestingly in the sources folder every time you save it creates a folder with a unique number…I’m sure there is some way we can apply some automation around this to get it up into GitHub.
I’m thinking about being able to spin up a new instance (copy live to test for example, or maybe build a new dev based on the education database) and then load some or all known “customizations” (in the general term) for testing, development, or even rebuilding a system that got hosed. The number above on one system may not correspond to another system. It should look like it was just entered fresh because we’re not building (or rebuilding) pets, we just want a fresh new instance that was built the same same (more like cattle).
Thanks Mark, I can now feel comfort in knocking one of my chooks on the head, full now knowing I have another producing eggs, a very paltry example of HA
In all seriousness, I was sort of thinking that the most recent folder regardless of number would match off with the latest in the repo, that was my thought.
To add to the solution it would be helpful to just be able to split the customs from the data, then it really makes it easy to test against live data. That would be a lot of work to pull that out.
Thanks for the reminder Bruce. The Epicor upgrade webinars covered this area well last week. I believe these recordings are available on Epic Web if you missed them.
There are exceptions like us as we are not live yet and so Pilot and our 3rd environments are not over written in our case without us asking.
Mark - This document, the recording and other material should have been out a few weeks before the timeline for the update to start. Just a very minimal approach, in my opinion, from Epicor.
Honestly, breaking changes to enterprise software deserve months of notice… Not just before the update, but before the flex signup deadline as well. We were never even able to get a quote for how much the flex option would have set us back!
Could be worse though - you could be in the middle of a migration! Imagine reaching a point where remaining migration work requires validation and testing before deployment to live, then not having compatibility between pilot and live for 2 months.