Hello,
we want to update OutSystems UI to the latest version and unfortunately found that the latest versions all contain breaking changes.
Has anything changed in the strategy of providing Platform Core components and avoiding breaking changes?
Are there best practices for handling breaking changes to core components in an environment with many applications with lot of different developer teams?
It is not practical to deploy all applications from DEV to TEST and to PROD in one big bang.
There will always be applications that are under development and cannot continue to be used in their current state.
We have addressed this issue in the past with OutSystems UI Web and also in an internal support case the statement was as follows:
Nevertheless, we agree with you when you say that "having a breaking change in an Outsystems core module leads to a situation which is very hard to handle"
Best regards,
Magnus
Hi Magnus,
We just finished the street.
Upgrade your first environment - we started with test - and learn from that. We created a new jQuery 3.63 resource and implemented that one for the OutSystems UI. Make changes in code in advance if possible.
In the end for Prod: make sure everything in UAT is ready to go should the need arise to go prod a seconds notice.
HTH
Hello @Magnus,
First of all thanks for reaching out. Looking at your post and, in order to try to clarify as much as possible, I believe we have two separate topics:
I hope this answer can make things a bit more clear and feel free to contact us, we will be happy to help you and understand your pain points mostly on the OutSystems upgrade!
Kind Regards, GM
Hello @Gonçalo Martins,
thanks for the detailed answer, I'll be happy to elaborate.
"The good news is that most of these changes don't require any changes on the code besides opening the consumer, refreshing references and publishing since most are related to changes in the parameter's names based on user feedback our new parameters which are always optional and by default have the same behaviour as before in order to guarantee retro compatibility."
This point sounds simple, but in a large factory it leads to a considerable impact. This impact could easily be avoided, for example, by providing a new version of the webblock for a new optional input parameter and setting the old webblock to deprecated. The latter approach has the same value for the developer and no impact in contrast to the first variant, which was preferred by OutSystems. In my opinion, this contradicts the statement regarding balance between impact and value ("This is also the reason why we always try to measure impacts on every release of OutSystems UI where we need to find a balance between impact and value for our customers").
We as a core team provide the OutSystems Platform to more than 100 OutSystems developers, who all develop at their own pace and do not always have the resources to release and test new versions of their application. So there is always a conflict when one development team wants to use the new OutSystems UI version on all stages, but the other teams do not have developer and testing resources available. Unfortunately, OutSystems 11 does not provide the option to run the applications with different OutSystems UI versions to work around this.
I am open to suggestions on how we as platform operators can pragmatically address this conflict. Unfortunately, we don't even have the possibility to easily identify the applications that are affected by the breaking changes. Perhaps OutSystems could provide at least one SQL statement for each breaking change using the system tables in version history to help with this.
"First of all, it would be great to know the version from which you will update to the latest in order to try to better guide you as well as know if you're simply doing an upgrade or also the migration to the latest components."
We are currently using version 2.8.0. Migration to the new components is left to the individual developers.
Thanks for your help!
Best Regards,
For large factory, one of the options you could consider, is to clone every version of Outsystems UI.
That will give teams flexibility to have their own roadmap with regards to incorporating (breaking) changes into their applications.
Dorine
That is exactly the practise we use at Product League.
Benefits:
Can you report from practice how you then do this with your own reusable or forge components that reference OutSystems UI? Do you also provide a separate version of all other components for each OutSystems UI version? Or are there no conflicts if mutually referenced modules use a different OutSystems UI version?
Cloning OS UI is *such* a horrible practice. Just the impact on AOs/licensing... UGH. And then it never gets upgraded at all, it just sits there rotting.
The real, fundamental issue under discussion is that OutSystems desperately needs proper version/library/branch management, and the OS UI situation just magnifies the struggles here very badly.
OutSystems was built with a deliberate decision to "fail fast, fail hard" on dependencies, and while that works very nicely within a single project team, it becomes very messy across a full enterprise, or distributed, disconnected work teams (like getting Forge components).
OS UI is the most obvious example, because the team tends to do breaking changes and every project depends on it very strongly, but we have this problem on *every* OutSystems project that uses Forge components or internally developed components that are on a different development lifecycle from their consumers.
Cloning producers *was* the "least awful" option during the time when OS licenses were unlimited, but now that AOs are back, it is absolutely not an option anymore.
J.Ja
It is a indeed a horrible BUT pragmatic practice on large factories with unlimited AOs, to manage time lines and not have a factory wide refactor because of OutSystems UI breaking changes.
AOs are back but customers can still pay to have unlimited AOs on enterprise license, and they do.
I can only agree with this and am therefore even more surprised that one does not do everything possible to avoid breaking changes.
If RWA introduces optional parameters as a breaking change, the reason for which is still not clear to me, then one has to bite the bullet and take this into account when developing new versions.
None of my clients were offered unlimited AOs upon renewals lately. I know we're in a separate topic now (likely one not for a public conversation lol), but with AO limits being in place for the majority of OS customers (or will be soon), cloning producers just isn't a strategy I can say "this is the way", even if managing it wasn't messy. :(
New, optional parameters should *not* be a red X error (and they are not to the best of my knowledge... they are a yellow triangle warning) that prevent a redeployment of code or are treated as a "breaking change" by the system. I'm surprised you are seeing true Red X Errors that block a republish or cause runtime errors.
This isn't even a RWA thing... this has been a challenge since Day 1 with the major shared components. I know OutSystems works hard to do things like rename broken items with "DEPRECATED_" and then make totally new versions, which is a huge improvement from the past. But it also wasn't needed in the past.
The big thing that has changed, is that in the past, breaking changes to OS UI (and before that, Silk UI, and Rich Widgets) only occurred during a major version upgrade, which is when you expect this to happen, and because of that, there was no way to accidentally apply a version of Silk UI for Version 10 to an app built in Version 9 and therefore get messed up. This was a once-a-year event, you treated it seriously, and your development team was not going to accidentally get a version off the Forge that would mess you up.
Now, breaking changes to OS UI (and presumably Charts, Maps, and other major components) are totally separated from the lifecycle of the platform itself, and if you aren't careful about permissions, any developer on your team can send your project on a one-way trip to a Very Bad Place just by clicking the upgrade icon in Studio.
Managing this stuff safely requires a lot of centralized management of teams, people, process, etc. and it's really the opposite of "agile". :(
cloning will shift the pain
but of course, the pain shouldn't be there in the first place, breaking changes should be a carefully planned rare thing.
I agree, optional parameters should not be breaking changes, but unfortunately they are in webblocks and screens, as it was also changed in the documentation.
I would have liked to see the problem solved rather than the documentation changed to reflect this.
Not having a branching strategy / being able to run multiple versions of a core component screwed us HARD within a year of us buying outsystems. We would easily have 100 apps on it, however, the problems caused by the pooling of shared resources like Outsystems UI has us holding Waaaay back.
One of the things I love about outsystems is the speed at which you can move. This omission slows that to a crawl when it's time to upgrade outsystems UI (which can be often due to using forge components requiring it - and being able to do that is another huge pro of outsystems). We keep our IT staff lean with relation to the functionality we provide, and there's not way we can support upgrading everything (and QA / UAT of changed apps which is required even if there are no code changes - we found this out as republishing left apps broken).
Worse yet over several internal tickets, it seems like this problem is difficult to explain, not a big deal, a problem with our architecture, etc. But it is a thing, just google 'dependency hell' and there it is.
Solution is this.
1) Allow apps to work with the copy of dependencies they are deployed with. There are cases where you'd want a business app to start consuming a dependency right away. But usually, you want deployments to be independent, not effecting others. This can be handled with versioning. (but then the AO problem - maybe these can be made not to count). This is a very common .Net practice - the DLLs for core version for example can be different for each program on a server. The key is a 'subdirectory' for each deployed app. Outsystems needs to either do this (or fake it).
2) Dependencies that expose a webservice interface should version it by name when there is a breaking change. Also this is very common in .net practice, and there are even standards for versioning (e.g., semver; however REST usually just uses v1, v2, etc in the URL). I mention this because some shared services - NOT written by us (customer) exposed an API and there were breakage problems. (I think it was Outsystems UI but I don't remember)
It's true this would leave older versions of dependencies in use. But there is a reason for that: as IT workflow ebbs and flows, and old versions build up, projects can be schedules on the org's own time, and farther apart, e.g., until there is a security critical discovery.
New stuff will work. Old stuff will work. I don't get how Outsystems is so awesome in so many ways, and this huge elephant in the room is holding us back from serious and Sprawling implementation of the platform.
If it could be made to work around the AO problem, the very least outsystems could do is release their core components like OS UI with a version number in the name. (or provide versions like that for customers with unlimited AOs).
We tried the cloning thing. Tons of problems as the original was still there, we'd already developed 3 major apps consuming it and they were in production and we have no budget to upgrade them for technical reasons only - and don't want to have to have one!
@Gonçalo Martins thanks for an otherwisely great product, and I think a fix for this should be prioritized in the list of improvements. This has literally thrown a huge we blanket on our unbridled utilization of the platform.
Hi All
I am having the exactly same problem as the title. I even worse, I am doing the migration from 2.3.2 to 2.19.2.
From the discussions and replies above, seems that cloning the module is least impact to the development but cost (AO) is another issue.
To clone the module, what is the best way to do so? Any step by step guide? Any better approach to upgrade the OutSystems UI?
This is in fact a huge struggle.
In case this helps:1. Step-by-step guide to cloning a module: https://success.outsystems.com/documentation/how_to_guides/development/how_to_clone_a_module_into_another_application/2. As I understand it, the most direct way to use the cloned version in a factory is:a) publish the clone in Devb) open every app where you don't intend to upgrade OutSystems UI just yet and change the references to point to the clone instead; c) wait for all these apps to be deployed to prod.d) Upgrade OutSystems UI and complete the upgrade in the apps where you wish to do it.To upgrade the apps that stayed behind later, open them again and change the references (either to the current version of OutSystems UI, or to a clone of a more recent version).If others are using a different process, feel free to share your experience.