Your flex option choice for 10.2.500 is due by 1 Sep 2019. More info…
Some changes in UBC migrations too (it is now Opt-In) so be sure to read the changes.
Your flex option choice for 10.2.500 is due by 1 Sep 2019. More info…
Some changes in UBC migrations too (it is now Opt-In) so be sure to read the changes.
@Mark_Wonsil Have you ever seen a talk about how they actually do their upgrades? I’m curious what their process is and what the steps are.
I have not seen any presentations about their actual process. I’m sure the Command Line tools are a direct product of automating many of the tasks required to do stand ups and upgrades. I would eager that there’s still a bit of manual effort that goes into these upgrades. I believe it’s one of the reasons it’s not financially reasonable to get rid of Multi Tenant. It’s also probably why there are set dates to do upgrades instead of letting users choose more convenient dates.
Where I hope they’re going would be a more DevOps pipeline approach. Like any lean, flexible manufacturing process, you would want to get to a lot size of one. This would make it easier to get rid of MT and give more flexibility to the customers. The tooling should be available to stand up a new environment (live, pilot, Dev, training, or other), copy live to Pilot, patch/upgrade instance, apply Solution, Model Regen, restart task agent. Once this tooling exists, it can be called from a Dashboard or put in a pipeline.
And all these tools should be available to the on prem folks or for those who want to go into the cloud on their own. This would be a big plus for public companies saddled with SOX requirements as there will be a well-logged trail of all changes because pipelines can include approvals.
Mark W.
Mark,
That’s what I was curious about. I would be extremely surprised if there was any automation at all based on my experiences.
John
Oh, I know for a fact there is automation. It’s why we have a Command Line Reference at all. Those pieces are required in order to ever string them together into a pipeline. That’s the part that’s not in place from what I can tell.
Again, once you can do everything with a single instance with automation then you can break up those MT companies into their own logical database and remove that restricting code that inhibits cloud adoption - well at least SaaS adoption.
Other than their Project Cirrus tools I haven’t seen anything that actually does that though.