Andrei Grigoriu
Rank: #2866
30Views
6Comments
Developer sandbox for Reactive apps
Question
Reactive
OutSystems 11
Usability

Hi guys,

I recently found out about the Developer sandbox that OutSystems has in order to not publish to the Public Area and break the application for every other colleague when you're working on something.

We are developing a Reactive web app and I can't seem to find the option in our app and I don't know why. Is this not available for Reactive yet?

If that is the case, do you know of any work-arounds for this?

Kind regards,

Andrei

0
0
on 2020-10-23
Copy link to comment
Pramod Jain
mvp_badge
MVP
Rank: #51

Hi Andrei,

A Traditional Web module can be executed and debugged in two different areas: the Public Area or the Personal Area. Reactive Web and Mobile modules are always published and debugged in the Public Area.

For more info please visit this link.


Regards,

-PJ-

0
0
on 2020-10-24
Copy link to comment
Pramod Jain
mvp_badge
MVP
Rank: #51

Please also go through this link as well.

Several developers can work on the same module at the same time. When you publish your changes, OutSystems tries to merge your new code with the changes that other developers published in the meantime. 

Working in a team is really easy as Outsystems prompt you for changes made by other in same module and does automatic merging for you as well , there are few cases when more than one member is working on the same screen or logic than you have to decide it manually which one you want to keep.


Regards,

-PJ-


0
0
on 2020-10-24
Copy link to comment
Joost Miltenburg
Rank: #1605

After doing a reactive project for just a couple of weeks with just one other team member I wish OS would just implement a decent collaboration facility. We have had conflicts, errors and lost work after publishing.

Not to mention me or the other breaking stuff for the other because of publishing during testing. We need a decent sandbox option; this just sub-par.

1
0
on 2020-12-15
Copy link to comment
Pramod Jain
mvp_badge
MVP
Rank: #51

Hi Joost,

I have been working in OS with big teams and it works perfectly in merging and showing what to merge. Most of the time SS manages the merge by itself but you always have an option to see what is different from your current version and you also have an option to manually mark the element to get merged.

This sometimes takes time between team to understand how to merge and get improved with experience.

Also whenever you publish a module with public element which being consumed by some other module and had strong dependency , Service Studio shows the warning for Potential Incompatible Consumer like this below.

Consumer module 'ABC' may have incompatible dependencies. Republish module to validate compatibility and avoid runtime errors.

You can also go through this document for more details on merging.

https://success.outsystems.com/Documentation/11/Developing_an_Application/Merge_the_Work/Compare_and_merge_example_with_conflicts


Regards,

-PJ-

0
0
on 2020-12-15
Copy link to comment
Joost Miltenburg
Rank: #1605

Hi, 

I don’t agree that it doesn’t do a decent job in showing conflict and such.

I am just saying that sometimes after a merge and publish someone gets errors. Obviously, mileage may vary here and that is, sort of, ok.

What I do have a big problem with is that we should have our own sandboxes, like most other systems (Mendix/Servoy)  have.

When I am extending / changing functionally I don’t want it to interact with colleagues. If it is complex I am surely not getting it right in one pass. They can break my stuff and I theirs.

I am currently experiencing this as I want to get rid of an performance suggestion from OS which is just wrong, but I only can hide it. So, that should be an extra option here: ‘don’t bother with this one again’


regards,


Joost

0
0
on 2020-12-15
Copy link to comment
Andrei Grigoriu
Rank: #2866

I have to agree with Joost here.

The conflict management part works pretty well, no one has a problem with that.

My, and probably Joost's problem, is with the fact that on Reactive everything needs to be in the Public area.
This sucks because, as he said above, if you have a bigger change you may want to debug locally first, and publish it on public only when you know you are finished.

Reactive right now is like doing a commit every time you want to build your changes, so to say.

Not fun at all.


Regards,

Andrei

1
0
on 2020-12-16
Copy link to comment