Kinetic's Transition to Monthly CI/CD Releases - what is your opinion

What-If scenarios with cost changes using standard cost, average, lifo, etc. that’s what I wish was there too.

if you self apply with the Cloud Management Portal (CMP) your downtime will be minimal, possibly less than an hour. If you wait for us to apply, then we have a broad window on that upgrade window where you MIGHT be down since you and many others are all upgraded at the same time.
CMP allows you to take the update anytime in the two month window after the release becomes available. You could take it on a thursday night after the 2nd shift goes home.

Any word when that is available to Gov Cloud?

I thought I would address some of the concerns. I hear you all… YES (@hkeric.wci) we DO need to prove ourselves. This is our first time doing something like this. @Mark_Wonsil has it mostly right.. we will be building new features in our STS (Short Term) version, and once done, then we transition those changes into the LTS (2027.100) as well. this means that we will have two branches going. but the LTS will also have those changes that are “breaking changes” being developed specifically for that release.
Lets take two examples. Neither of these have high vote counts… but they were “easy” examples for us to use as test cases for our new rollout procedures:

Example 1 - STS CICD Release: Idea Reduce Clicks to Add New Part Rev

We intenionally chose this one to be one of our “proof” cases that we can get CICD right. Our change will be that when you press the NEW Revision option, the system will return a blank value instead of “New” in the revision field. This simple idea for the most part will not have breaking changes UNLESS you have a BPM that looks for the “NEW” and does something with it. Yes, that COULD be the case, in which case, you would need to adjust a BPM. So, this sort of falls in the middle… something that for MOST customers will never cause them a problem, but you might be able to prove us wrong. In any case, this will be well documented, will have a feature spotlight, and will probably be one of the small list of features coming out in 2026.103.

Example 1 - LTS CICD Release: idea Customer Part Cross Reference

We also chose this one for a sample of an LTS change. On first glance, this idea seems “simple”.. fix the screen so that it is more usable. Our developer worked out a solution in just a few hours. It is now easier to recall a customer’s cross references.. but when development looked at the UX, they realized that this will take a complete rearrangement of the screens, cards, etc. We cannot do this without breaking any customizations that you might have on this screen. So, THIS is being written for 2027.100 and will not be part of CICD. It will require you to further test, and will go through Controlled Release.

So some of you might think: “TimShuwy, you just proved our case… both of these COULD have breaking changes”… and you are right. BUT I can also tell you that we have customers who actually USE BUGS to their advantage, and if we squash the bug, we break their procedures. There comes a point at which we have to call out the new feature, document it, demonstrate it, and let you address it. BUT REMEMER, this is not 12 full annual releases per year. Each month will have one month worth of changes and will be focused and easier to test than the large batch you have been used to.

That’s one of the questions I had during the webinar…how much time will we have to test (assuming we don’t use the CMP)? Drops were planned for the 2nd Tuesday - presumably to Pilot…so when would they hit Live?

EDIT - not trying to put anyone on the spot here - optimistic that the CI/CD will work out well.

I beleive we stated that there would be a 2 month window between the release and the Epicor installed upgrade into production. But with CMP you can do your own before that once you do your successful testing.

So, 2026.101 comes out say in Aug to PILOT so will go to PROD in October?

Meanwhile, PILOT will get 2026.104 in Sept and 2026.105 in October?

So theoretically 2026.100.9 would hit Pilot in September and Live in November?

That could work. :slight_smile:

Except, I don’t feel like up to this point changes have been well documented so that we as customers know what to selectively test. Most of the updates and even the CR the testing recommendation is “Test everything!” So yes, there are fewer changes, but if we don’t know where they are, that doesn’t mean the we are able to test any less than we would with a big release. The haystack is the same size, there are just fewer needles to find. We may find fewer issues, but we would still have to do full quote to cash and as many edge cases as possible, and even then we’ll miss some (many? most?).

Until you prove me wrong, I don’t think we’re going to believe that the changes will be documented well enough to trust that we will be able to catch a majority of possible breaking changes before it would hit production. Epicor as a whole is developing/changing faster than they can keep up with even basic user guides, much less changes that may have unintended consequences.

And, the thing that I have still yet to understand, is what happens when a breaking change IS found? I’m still lucky enough to be on premise and we can stop the process, but what about cloud customers? If there is a change that really hinders their business and they can’t stop the upgrade, what happens?

“I promise it won’t break” isn’t a business model.

I can answer that. You get upgraded anyway. Hopefully you figure out a workaround by the time it hits prod!

:100: this

@timshuwy Why is the availability of the Gov CMP being avoided like the plague? I ask various Epicor representatives every 3-4 months, including webinars, and never get a straight answer. All I’ve heard is “sometime 2026” last year, and now it sounds like “sometime 20227”.
Seems like a lot of, lack of a better term, “admin availability” is being lost if we don’t have this tool for Gov Cloud. Upgrades, refreshes, and even simple data model regen is not quick and relies on support to do it on their time. CMP is a must have for anyone in the cloud and not having a timeline for Gov is worrisome.

Great question, and I dont know all the details, but I do know that before we do this, we have to support Gov Cloud in Containers. Gov cloud support must reside in USA only… so we need to make sure that all the infrastructure support is all US Based and works in containers. Once that is in place, I am sure that you will have CMP.

Gov cloud is not on AKS.

Ahh.. that Documentation/help file thing… Way back over a year ago, when we started designing our CI/CD methodology we created rules:

  1. we dont decide which release the change goes into, until the feature is finished. BEFORE, we would define a feature, and define what version it was coming in, and it got released even if the documentation was not done.
  2. A feature is not complete until the documentation is complete. Therefore, we cannot specify what version the feature will be released in until docs and help files are done. This also includes any Feature Spotight videos.
  3. If during the feature build, we find that there are breaking changes, it will automatically be pushehd to the next annual release, even if finished 11 months early.
    These three changes in our procedures (along with many others) will very much help with these plans for CI/CD… Will we be perfect? well, Excellence is our goal. Will we make mistakes? Probably, but that is not our plan.

The problem is, too many things have been broken recently that it’s hard to trust the promise of “No breaking changes” with your new CI/CD. I hope this does go smoothly as you guys need to rebuild some trust with your userbase.

Until then, I’m still with @Banderson

What She Said GIF by The Free Mama

Busch GIFs | Tenor

Like Haso said. I’m happy being left out. We’ve seen their track record on updates lately.

Most of those things had nothing to do with application changes. those were some required infrastructure changes that were not what we would call part of CICD. Moving to containers so that we could have the Cloud Management portal. Moving to Linux so that the system worked more efficiently… neither of those were changes to the application.

It’s a systemic issue @timshuwy. Infrastructure, application, insights planning, documentation, email communications, we can point to any part of the business as a whole right now and see major issues that are affecting customers. So to say that “It was a different issue, trust on this issue” rings a bit hollow.

We really want the systems to work. We’ve built our careers on it. But you’ve got to build the trust back. And that takes a LOT of work and time. Not just talk. Hopefully we can see things improve soon.