Hi all,
I just listened to the recording of the Webinar from yesterday entitled “Kinetic’s Transition to Monthly CI/CD Releases”. Really curious of opinions of this new cadence for upgrades from everyone else. I am very unsure about it and feel like Epicor is wanting to put out the shiny new Features earlier instead of focusing on getting the new Kinetic Web Version 100% functional like the Classic version we all are used to. Also not sure I am understanding the information in the webinar correctly. Don’t like that they had a webinar on a topic they have not 100% thought out and tested. They could not answer the simple question of how many days is it between the Pilot monthly update and the LIVE monthly update. Just my two cents worth after listening to the webinar. I could be fully misunderstanding everything.
You misunderstood nothing nada nil zip zilch. I have equal levels of confusion and concern here.
100% agree that we didn’t get a clear answer on how much time (if any) we’d have to test. If the monthly releases are deployed on the 2nd Tuesday of the month as was stated…where’s that being done - Live or Pilot? Do we get ANY time to test?
And with up-to-12 monthly releases, that also means up-to-12 or even up-to-24 more outage windows (12 Pilot, 12 Live) to deal with. One encouraging thing that was mentioned - but don’t recall an ETA for delivering it - was a “zero downtime” footprint for update deployment.
I think the “promise” is that the monthly CI releases will never contain breaking changes. New features will be released in a single, yearly major release, and the monthly updates are supposed to only be bug fixes.
In reality, this is the same promise that was made about point releases, and we all know how that’s gone. It’s deeply concerning.
For SaaS we’ll get “non-breaking” features monthly but anything that changes schema, etc will come at the next .100. They are only going to do a Controlled Release for the .100 releases now as well so we’ll see how these monthly “non-breaking” changes really turn out.
ANY feature/release could break something…that’s why the testing window needs to stay in place SOMEHOW…and not by forcing every customer to finagle around with CMP. Deploy on weekends as close to Day 10 in Pilot and Day 20 in Live…that’d give customers a chance to walk through things.
You really enjoy dumpster fire threads where we all bash epicor huh?
If they were truly embracing devops and proper CI/CD it could be a good thing. Based on how they have been doing, I don’t think that is happening. The pace of AI slop is just increasing.
We cannot update anything without running tests. Compliance reasons. So even though they claim no breaking, there will be full tests for every release (major or minor).
1000000% agree…I don’t put blind faith in ANY software vendor to deploy a bug-free update…not without at least trying to walk through before going Live.
10000000000000000% agree that’s why I put “Non-breaking” in quotes as they have yet to prove to us that these will be non-breaking. It’s not that I don’t trust them… I just don’t trust them.
I’m still digesting the info from the call yesterday. It seems like a good plan, I’m in favor of less major upgrades each year. I can still flex my upgrade and self upgrade and update via portal is the right approach. After-all, I have enough challenges in finding the right weekends to travel.
We have not had any issues with monthly patches. This might be a little different.
First, let’s go over what is happening today. There are two major releases with monthly patches. The Public Cloud (you) will be on the Continuous Track. There will be only one major release and the month updates, which are patches and features. The Maintenance Track will also have only one major release but only patches and no feature updates.
First, in the webinar it was mentioned that this is not how other companies like Google/Microsoft/etc. do CI/CD. The CI (continuous integration) means that changes are merged into the main code constantly and you know you have a good build with all the different changes from all the developers working on different things. The CD (continous deployment) means that the shipping version contains the code for all of these changes. However, these companies will often use feature flags to light up the new features in rings. People who want cutting edge will see the feature first. If there are bugs, they are fixed quickly since we’re constantly integrating fixes and deploying them. If the bugs are sufficiently bad, they will turn off the feature without having to redeploy the older version. Then the next ring will see the new features. Here the developers will look at telemetry to see how well the new feature is performing, catch errors, etc. so they can make performance or usage improvements. Eventually, the feature is accepted and they remove the feature flag and replace the old code completely.
If I understand correctly, Epicor is going to have two branches of the code that are only in sync during the annual baseline release. Will they add features and patches to one branch and only patches to the other? Will they update both and hide new features behind flags?
In CI/CD, companies like Microsoft try to keep branch life short with frequent updates. A branch that lives for a year would be a pretty ugly merge. But maybe they’ll just ship the base to everyone, but that might cause issues with the Maintenance track since this will be like a waterfall update.
Unless a feature can be turned off, I would still test.
fans?]
But maybe they’ll just ship the base to everyone, but that might cause issues with the Maintenance track since this will be like a waterfall update.