Useful!

Usefull, but I think it`d be even better if I could configure this in the Preferences. Like, turning Studio more personalized.

This is the wrong way to accomplish your desired END GOAL.

What's needed is an easy way to refresh references without opening this window at all. Then leave this window alone because for the purpose of managing dependencies it is just fine.

There are already a number of Ideas for a simple "Refresh References" button that do not involve making the use case of "managing dependencies" so much more difficult than it needs to be.

J.Ja

Also, you'd typically use the "Refresh All" button anyway, so there's almost never a need to see what exactly needs to be refreshed.

That said, I would be in favour of this Idea for a different reason: 90% of the times I want to add a Reference from a Module I already reference. I now have to scroll to the right Module (cumbersome, we have a lot of Modules), or select "Show In Use", which is also annoying since there's a bug with its hit target.

Note however, that in P8 (or P9?) "Show In Use" actually was automatically selected when there was anything to refresh (as opposed to only when having breaking changes), but apparently people got confused and OutSystems decided to revert that functionality! So this Idea has very little chance of being implemented :).

Funny enough they should not have merged to two functionalities into one, akthough they are very much the same.

- refresh producers should be a seperate button.

- maintain references should be as is, because your action will be adding/removing references.

Glad that you have some points on this.

I see your points, but I never use "Refresh all" dependencies because of breaking changes that a platform that only isolates things by environments and does not have solutions like branching code can come any time.

There are at least two different problems I'm suggesting to solve:

• When I want to review one or more dependencies, I want to enter this screen and CHOOSE what dependencies I CAN update WITHOUT breaking changes(generally one that I did.) coming from other modules I already use;
  • To accomplish this on a dev environment, I need to wait for ALL sort of things we have on this environment and a lot of solutions downloaded from forge to be loaded first. I rarely will be using new deps and need to wait for all do load first. Not time saving.
• Time save and a more clean list of what I really was searching for.

I agree with João Melo. It may be a configuration if you prefer.

Not agreed with Justin this time, the objectives are not those. As I said, I never would DO a "Refresh All" and let me see what happens after.

If the objectives are not clear yet let me know if you want I elaborate it a bit more.

Marcio -

That workflow doesn't work very well, it completely falls apart when you make a breaking change. This feels rather edge case. I understand *why* you are doing this, but your workflow is never one I would recommend, never mind reinforce via product feature. This is especially true now that non-breaking changes do not force a refresh in a significant number of cases.

Service Studio tries to have as little configuration as possible, as you may have noticed, and that's a very sound decision in my mind. I would be very surprised if OutSystems works to support this workflow at all, even as a configuration.

J.Ja

Ok Justin, I got your point of view, but I prefer a more controlled way of update what I want/need without side effects. I never would give any "refresh all" to update things I have secure to update. If we make things like this sometimes we get caught by a undesirable behavior as a result of an "intended secure update", but as all of we know, software fails, people fails too..

It was just an idea to make things better for anyone, but if I lost more time "selling" simple things like this I end spending more and more time.

If Outsystems looked deeper in these lots of ideas, forge partial solutions to cover things that could be platform native we all were spending less time suggesting simple things like this and any other suggestions I had made to be more productive, effective.

Mmf

Marcio -

I am beginning to think that "Refresh" (and "Refresh All") do NOT work the way you think they do.

It does NOT MATTER if you refresh a reference or not, as soon as you publish the consumer, it gets compiled against the most recent version of the code. All that "refresh" does, is make your code aware of the changes, so it can be aware of changed names, added parameters to screens and actions, new records in static entities, and so on. Simply opening "Manage References" and not pressing "Refresh All" or "Refresh" on a specific reference... that doesn't prevent your consumer code from using the latest version of the change, because it WILL as soon as you publish.

If you are trying to update something without "side effects"... that isn't how this system works. It is deliberately designed to "fail fast, fail hard", and part of that is that as soon as you publish a producer, all consumers get the latest copy of the producer as soon as they publish (they won't get it when the producer publishes, they get it when the consumer publishes). If you are trying to avoid a "refresh" on a reference in the hopes of not getting the "side effects" of a change to a producer, that doesn't work that way. :(

J.Ja

Justin,

If the rules to update refs works the way you describe it, yes, I was wrong and the way you tell me it auto-update all deps is....frustrating.

This way, I never could manage and test impacts and all sort of bugs coming from 3d party solutions and even the ones we develop. Even if I found some issue and have not time planned to fix a tree of dependencies, I will have some broken apps trying make minor fixes.

If we was trying to update some 3d party or internal modules we update it and make a few tests, if in this time interval someone else need to fix something and republish the app, this deploy will carry any sort of things we don't know about, like indirect dependencies.


Taking advantage of your knowledge, let me ask for a related scenario where we were publishing between different environments and have different versions of dependencies between it, how Outsystems decides if  the versions of deps need be updated, if there were not basic breaking changes, only behavior changes?

If we deploy an app from Production > QA > or Dev via lifetime, what are applied to decide about most recent versions that were on these environments?

Sorry for the false assumption, but who could imagine this kind of dependency management/isolation. If I need to evolve some big enterprise apps my company will need many environments to isolate things according with business needs, as we today use cheap branches on Git.

Today we use Git repos and a very mature model and can control things like these in a more soft way. Low code sometimes brings neither low things and the time savings sometimes get neutralized with more management need to overcome this kind of thing.

Best regards,

Marcio -

So the way it works, each Espace is compiled into a separate IIS "application". Each time you deploy an espace, it looks in a central directory on the deployment controller where each module (espaces and extensions) are individually compiled to their current version, gets a copy of each one that it depends on, and puts it in its own application directory. *

Now, let's say you have a module (Producer) that is used by two other modules (Consumer A and Consumer B). Producer changes and Consumer A changes, you want to deploy to QA, but Consumer B is NOT ready to be deployed to QA.  To make it worse, Producer has breaking changes in it that Consumer A depends on.

What will happen when you deploy from DEV to QA, you select Consumer A and it will require you to deploy Producer. You will have the choice to deploy the current version of Consumer B from DEV to QA... do NOT do it. You will also have the choice to REDEPLOY the version of Consumer B that is in QA... UNCHECK THAT! Now, when you do your deployment, Consumer B will still be compiled against the older version of Producer, it will still work exactly as it expects to using the older version of the code from Producer.

So the system is set up to let you make those kinds of changes without breaking other code, it's just a question of learning the way the deployments work... which is really not obvious or well-explained anywhere that I know of. It's totally understandable that this is not obvious to you (something which OutSystems should find a way to make more clear).

Of course, "I sure hope no one re-deploys Consumer B because Producer changed and Consumer B isn't ready for the changes yet" really is not a great plan at all. The OutSystems recommendation on this is to use feature flags. I know that there are many people who do not like feature flags (and I can understand why, even if I personally do not mind them, and in some cases prefer them), but that is the recommendation. Again, everyone's preferred way of working, but having been involved in some super huge projects/products built on OutSystems over the years, I have had less problems with feature flags than I have experienced in other systems with the problems around merging of branches and such... that's just my experience and I know others have had difference experiences so I know it isn't "truth".

J.Ja

* That's actually a simplification. What it REALLY does, is each time a version is created of a module, it compiles to a DLL, gets put into the central directory with some random characters added to the filename. Then, whenever a consume is published, it creates a symlink in its application directory pointing to the most recent version of the producer's DLL. The actual file in the central area gets deleted when no more consumers are pointing to it.

Justin - 

Thank you VERY much for your time and information.

We will find more info/docs to try to have more control over the process.

With your info, I understand that, even a bit manual, we can achieve more control/less impact on publications over environments, but never within the same environment. Let me know if I understand it wrong.  But as you said: even if I DO NOT refresh deps and the kind of changes don't break anything detectable(just behavior changes), I will publish and catch whatever new version of my deps from the current environment where the code is modified.

Mmf

Marcio -

Yes, your understanding is 100% correct, and glad to help! I should write this up into an article, it's important information to have and it is not obvious how it works. :(

J.Ja