Since moving from an on prem company to a cloud company, I keep running into little things that I swear don’t work the way they did last week. But I always consider that maybe I’m misremembering or just didn’t notice something before.
Now I have a paper trail. I was working a confirmed issue with support when the stack traces and error messages suddenly changed, and then the problem disappeared as mysteriously as it had appeared. Support doesn’t seem to be aware of anything changing, because it was when they asked me to run a data fix that I discovered the issue had seemingly resolved itself.
Have any other cloud users had this kind of thing happen?
We were an early Dedicate Tenant/Public Cloud user and I’ve only seen it once - sort of. Because we were new, we weren’t on the cloud notification mailing list for the out of cycle patch. So others knew, we didn’t. (It was also rolled back shortly afterwards…)
Just wondering, who all has the ability to make setting changes at your company? Can you rule that out?
The possibility of someone else making changes is always a source of doubt. To be more specific, I had an old configurator written by my predecessor that we were keeping around for reference. It was unapproved and unreferenced by any revision. One day, its mere existence started causing Regenerate Configurators to fail. I can rule out that the broken configurator had changed for months prior to the problem emerging, but I can’t rule out that something it references changed more recently, like maybe a Part.
I hope I can rule out that Epicor itself changed. In trying to troubleshoot this, I learned that approving any configurator regenerates all configurators; that this includes unapproved and unreferenced ones; and that an error in one halts the regeneration of all. Any of these things might have changed recently, but with so many variables, it’s hard to say for sure.
It seems like this kind of thing happens a lot, and it didn’t when I worked for a company that was on prem. So I wonder if Epicor has ever clearly stated whether they follow a strict release cycle for changes, or if some changes are considered minor or urgent enough to deploy out of cycle. In at least one case, an issue I reported was slated to be fixed in a specific future version, so they do at least sometimes follow a cycle.
I have seen this at least once. It was very similar to Kevin’s experience except there was never any e-mail just a rollback of the functionaltiy with equally no annoncement. But this was back 2+ years ago. I haven’t seen it since.
Product Management, Support, development, and QA have reviewed these bundle fixes. They have strict rules on what can be changed and impact to minimize disruption.
There are rare hot fixes that may get applied. I am not aware of anything recently, but feel free to double check with our support leads.
I think those emails went to a former employee. I’ll see if I can figure out where to change that.
Do they really only give you four days to test between updating your test and production environments? My gold standard for how to do SaaS right is Shopify. Although their API surface is only about 1/200th the size of Epicor’s, they let you control when to upgrade your production integrations, and old versions are supported for a year (two release cycles.)
Only for patches. The Release (.100,.200 or .1, .2) which come twice a year, you have a month.
When the SaaS team started out, they too had the on-prem mindset and did things in batches. This has been changing as time goes on (Azure DevOps, etc.) But I agree, an entire upgrade should be automated and taken down to a lot size of one - like we try to do in manufacturing. The advantage here is that the SaaS team can scale out upgrades for the formerly named MT customers by time-zone. Public Cloud users could go to a Portal and manage their upgrade choosing when to start, when to copy Live to Pilot/Test, when to run pre-post test reports, and when to commit to the upgrade.
Shopify is a different beast. It truly is multi-tenant and like you said, it’s mostly just an API surface. They can update their UI without affecting everyone’s business. But Kinetic/ERP drags along a lot of legacy baggage, so getting to a cloud world will take some careful planning and time.
Patches are applied every two weeks the API’s are stable and no functionality changes or are behind feature flags. This is how Shopify/Chrome/Azure and almost every modern company now works some go faster than two weeks - multiple releases a day, hour but the key part of these are they are non-events.
Bi Annual releases you can flex on and you have more time to verify. These can include API changes, but we always try to minimize disruption keeping API’s stable and compatible.
Shopify’s promise is that “Every stable version is locked for a minimum of one year, meaning that . . . it will only be changed in the event of a critical security fix.” Epicor needs to follow a similar cycle for SaaS upgrades, and customers need to be able to decide when to upgrade.
