Branching your eSpace
Hi All,

Often I encounter the situation where someone is working on a espace with a release planning X while another wants to do a bugfix or even an other project with the same espace, but with an other releaseplanning Y. In "normal" development processes I would branche the code and give each developer/team their own edition while later these branches can be merged. This is very hard to do in the OutSystems way of working. What do you usually do in these situations and are there any plans to introduce branching in OutSystems? It would be great for me and I think for many more.

Let me hear your ideas....

could you not achieve it with cloning and merging back later?
Hi Joost,

With cloning you create a new application. So, if you'd want to release this clone before you can release the original, you have a problem. At least as far as I know. Have you done it this way?

Hi Mark,



What is usually done in the hot-fix/patching/bugfixing scenarion is the following:


  • Setup a Pre-Production environment that is equivalent to the production environment
  • Carry on your main developments in the Development environment
  • Whenever you need to apply a hot-fix/patch/bugfix:
    • Develop the fix in the Pre-Production environment
    • Test it there
    • Release the fix to the Production environment
    • Merge the changes back into the Development environment so that they will be released to QA, PreProd, and Prod in the end of the Sprint

Does this covers your scenarion? Thanks!

Hi Rodrigo,

Yes this covers my scenario, but usually this is not feasable because developers don't have the access to PreProd, usually not from QA on.
Besides that, this way you can not develop on the same eSpace if you have two different release scedules. This is why branching was invented. I know I shouldn't want this, I should steer towards releases every 2 weeks, but sometimes this is just not feasable. In those cases it would be great to have branching available.

I'd like to know if this is on the release scedule or if anyone else wants this feature?


Hi Mark,



Yes, this was already requested by other customers, namelly large factories. We have the support to such scenario in our backlog, but currently with no defined delivery date.



Thanks for the feedback!


Did anything came up from these requests?

Thank you.


Is there any news about this subject?



Any updates and/or feedback on this? We would rather not replicate the DTAP street just to have the concept of a develop and master branch.



HI Everyone ,

This topic takes me here ..

I have been in many back and forth with one of my customer asking the same branching things as he used to work with SVN and other source control with .Net and Java.

I had many discussion with Outsystems and finally there was a no from them. I also recommend to have this feature with the platform.



OMG, we need this feature SOON!

I am currently in an office with 8 developers, each working on different modules, but as happens, there are times when multiple developers are working on the same module, 

I would have thought that Branching, Forking, create a dev environment for many developers would have been a standard service for any development platform, what is worse is that the OS set up is p[reventing the way that code has been developed for a long time.

Git, SVN all allow numbered commits (with comments) the closet OS gets is providing a time when the last person updated, If I have to go back and find some code, with Git and SVN I can simply search the commits for the code I am looking for (very easy) with OS you have to remember when you wrote it, go to the modules published around that time, the loading each one individually to compare its code base with yours.

Have you any idea how much time this takes?

Publishing work is a nightmare, If I try to publish and find another developer working I have to re-download, merge and THEN upload.

Seriously guys, have you any idea how much time this wastes? on bad days it can be up to 90 minutes a DAY waiting on refreshing dependencies, finding code.

Your platform is amazing, but the time I save working with OS is more than offset by the problems it causes,  This feature has been requested for TEN YEARS!!!

Ten years to implement and apply that which most versioning systems have as standard.

that's just not cricket guys, not cricket at all. :(



I still do not understand why people think branching is the solution of the problem that multiple developers are working on the same screen/webblock/code. Branching will never solve this issue, it only means the delay of the inevitable merge and their conflicts.

Sure, I do like we can actually start developing a shortlived-branch to develop something independant so we can continue the main-trunk to fix bugs and develop more important stuff.

And I really wonder why people think GIT/SVN is so great. Whenever I want to use stuff I never know which branch is the best one, I always see a gazillion pull/merge requests waiting. Not to mention lots of other forks because people of annoyed etc.

For me, branching is simply a tool to kill of agile-development and continious development/integration and back to the stone age ;)

So I agree to disagree :)

J. wrote:

And I really wonder why people think GIT/SVN is so great. Whenever I want to use stuff I never know which branch is the best one, I always see a gazillion pull/merge requests waiting. Not to mention lots of other forks because people of annoyed etc.

I accept your right to agree to disagree, but I don't think you have been using it properly. When used correctly Versioning allows you to make fully independent environments on a per developer basis or even per-issue basis., with your project manager in charge of the merging you should be able to apply changes to the same files without causing conflicts or writing over other peoples files.  allowing Stashes and indexed stashes is one thing I miss, this allows me to try 3 or 4 variants of a fix to discover which one works best, all without republishing and rollbacks

Even if a branch is forked early on and major changes are made you will still be able to merge all those changes along with 100's of other changes made at the same time, the versioning system should keep track of each commit.  I also think that being able to have labelled Commits in the merge history allows you to cherry-pick specific changes.  at the moment to review any commits or to find an issue within any given publish you have to compare every merge you have done, 

Git and SVN are not just for Branching they are an invaluable tool for any developer if you don't know how to use a versioning system you are missing out on a lot of very good tools.


Yes, this allows us to run concurrent releases of a given app.  Without it, it becomes difficult to implement with four environments.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.