On our radar
Branching could be useful in different situations, some more relevant than others, but on big factories with a team with several developers, it could be very useful.

A situation that occurs frequently is when we receive a change request which requires changes on core entities, this will break the environment , and will affect other developers that are working on a different feature, but are prevented of testing/developing without pain since the environment is broken.
So it would be great of having an way of creating a branching per pta of a solution, were the developer could make the change that will break the environment isolated, finishes the development, could test it isolated again (remeber that i've mentioned a branch of the solution), if everything is ok, perform the merge of the branches, create a new solution and schedule the publish.
Im mentioning PTA was a way of doing it, it could be by branch, if it was possible to work on different espaces on a context of a branch

If i was a smoker i would quit smoking with this feature :)
Created on 19 May 2010
Comments (19)

what about cloning?

will that not solve the branching?

Clone is a different espace, different id, which would lead to different entities (id's), and so on, so when you wanted to merge back of the original one they wouldnt match, and still i wasnt able of testing it. 
Im not seeing a way that clone could help in this situation, can you share what you were thinking?
Well, branching in my book is branching the source code.
not the actual data. so with cloning would accomplish that.

so actually what you are saying is "branching" the whole application including the data.
that is imho, the idea of synchronizig dev/prod/quaility servers.

Yep, i want to branch the source code, use the same data, and dont affect other developers work that are working on a different branch. With cloning im not able to accomplish this.

it doesnt have anything to do with synchronizing DEV/QA/PROD
But if you change the core entities, no matter what branch you are, it will effect the developers anyways, because the core data is changed in your case.

unless you want a clear copy of the developement environment, then my original thought that you should either

a) clone the relevant espac and bootstrap the data again
b) synchronize DEV/QA/PROD but more like DEV1/DEV2
or rethink your development street.

for example
1. DEV1: core entities
2. DEV2: other espaces + stable core
3. QA

or even think about the solution is organized.
frequent changes of core entities is imho somewhat strange.

Allow me to cast my vote in favour of branching eSpaces.

Yes, I get that that could cause problems/difficulties if the entities change and it wouldn't really solve the problem where developers must change the same actions, for different reasons (i.e. one needs to change it because it's part of a new development; another needs to change it because it's part of a bug fix).

However, branching would allow two things to happen:

1. Deloy just one branch -> suppose your development rules mean than you and only deploy new developments, and not bug fixes. Simply deploying the "development branch" instead of the "bug fix branch" would achieve this.

2. Simplify confict resolution -> since you know that what's on the "development branch" are all new developments, and what's on the "bug fix branch" are all bug fixes, merging both would be a bit easier because most bug fixes will happen on existing "code" and new developments are, well, new developments so there's less chance of conflict
I like this idea and looking for the same for a long time from Outsystems. I will describe my problem here and I think the original poster is talking about the same issue.

Suppose an espace - ABC having 3 Screens has been deployed into PROD. And a developer is creating a new screen # 4 in development environment for the same epace - ABC. In the mean time there was a bug identified in Screen # 3 functionality in PRODUCTION Environment and need to be fixed as soon as possible.  So is there a way we can migrate espace without having any of the new functionality of screen # 4 which is currently in development ?

There would need to be some way of marking a version/ branch in dev to you can choose which code to work on - like the difference between dev and quality. Ravi's scenario is one which I'd like to be able to do more easily. At present we freeze code to our quality server and hotfix & release from there and apply the fix to dev at the same time. However, this doesn't work when we need to quality test a release! Having a dev server, triage server and quality is one way to go I guess!
Merged this idea with 'Make branching an application possible' (created on 2017-05-01 09:18:22 by Danny Prager)

If you'r familiar with Git or Github you know what I mean. If not, here’s an explanation.

Casus: A colleague of yours “Citizen Developer” ha-ha. Made an app that works pretty well. Unfortunately he did not care about design, structure or future changes. Now the task is up to you to create new features in the spaghetti code he left behind. You decide to rebuild, refactor the app. This would result in a broken app that can only build again when you have finished refactoring his code resulting in a period where you are not able to perform hotfixes, maintenance or changes to the old application.

When branching is possible you could simply create a new branch from the current application and work on that when refactoring over a longer period of time. If anything goes wrong with the current application you can fix it without any worry’s. When the time for publication of the refactored branch  is ready you can merge it with the old branch and publish it to the webserver.

Merged from 'Make branching an application possible' (idea created on 2017-05-01 09:18:22 by Danny Prager), on 2017-05-03 13:59:49 by Goncalo Borrega

This is an often requested idea, duplicate of others.


Merged from 'Make branching an application possible' (idea created on 2017-05-01 09:18:22 by Danny Prager), on 2017-05-03 13:59:49 by Goncalo Borrega

Hello J.JA

Is there any update on this idea? is Outsystem planning to have this functionality in near future?

Hello J.JA

Is there any update on this idea? is Outsystem planning to have this functionality in near future?

I cannot speak for outsystems, but I really doubt it.

they have created an awesome platform with the dogma of not branching.

this also extends the agile-philosophy to deploy fast and often and there will be no need for branching.

hotfixing can always be done on production..


Totally share the same opinion as J. expressed in the previous post, but as the complexity of "enterprise applications" in "low-code" development increases this mechanism of branching will be missed more and more.

One issue is that OutSystems development includes the Datamodel, along with the Logic and Interface (and Processes), and so the Datamodel is also included when talking about branching, and branching the Datamodel is effectively not that simple.

But, if you exclude the Datamodel, I think cloning espaces is currently the only way feasible as workaround to do branching in OutSystems development.

If others have any custom procedure implemented in their factories to do branching, please share.

Tiago Bernardo

We really want this as well.


Would make things so much easier.

+1 our current mobile deployment plan is to try and push things to production at least every 2 weeks.

We know that some new features we are working on are going to take longer then 2 weeks to develop so we dont want these changes moving on to qa and then to prod until they are done.  Or if we are planning on pushing to qa in the next day or two we are reluctant to start working on something that will not be finished in time.

If we could create a branch for these larger features the other small features or bug fixes / enhancements could continue to be developed and released without having to worry about something getting pushed that shouldnt have.  

+1  Hope this is implemented soon