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..

Hi!

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.

+1

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

+1. 

+1

I really want this :)

Our digital factory will have multiple sprint teams working in parallel on different themes.  At a minimum the factory has a team working on break-fix defects based on current production pipeline in parallel to a team working on new feature releases.  

The break-fix defect pipeline needs to be protected against getting polluted with new feature development that are release prematurely to production while the feature release pipeline will need a way to evaluate and merge (auto or manual) production fixes. 

This setup requires the ability to maintain two parallel (but linked) pipelines where we control synchronization at logical stages.  This is how we do it for all other technology including ASP.Net, Spring/Java, and even packaged application configuration baselines.  

This feature is necessary for reducing risk and managing complexity in an enterprise grade setup.

@Dany Hajjar

This is exactly my point :)

+1 this would be a great idea

Branching is a standard and basic idea to manage multiple feature development in parallel.

Feature Branch is used across many kind of development technologies. Here we are not using OutSystems in complex applications because it require Feature Branch to control parallel development.

I'm impressed that OutSystems don't have it yet. It is a big problem.

Do you know what's really funny,

Outsystems dev team uses github (what enables branching) according to:

https://stackshare.io/outsystems/outsystems

Why would they think this feature should not be possible for the developers that use there platform? its a guess to me..

Danny -

If you read their development blogs, they don't use branching, they use feature switches, same technique they recommend in developing with OutSystems.

J.Ja

Hi Justin

Certainly feature flag based development is the obvious workaround.  But I feel this method alone would require tight governance and QA as part of a continuous integration pipeline.   Otherwise regression defects will be leaked to production.   It would be interested to hear from others on how they have manage to tackle this whole area.

Dany

Dany -

Branching requires the exact same governance and QA controls... people do bad merges, people make breaking changes and you don't find out until they do a last-minute merge and your whole deployment cycle is interrupted because now all of the consumers are broken and can't publish, etc.

I am not saying one is better than the other, and I think maybe teams should have the choice.

But I can say that after many years with the OutSystems way, I have never wanted branching back. Forcing people to actually communicate and work together in real time, rather than letting them go off, do their own thing, and praying they didn't mangle the system when they eventually merge, has proven to be very much worth the risks of remembering to put a simple feature flag in the code.

Again, that's my experience, and I'm sure others will disagree so I am not saying they are wrong. But I think that the lack of branching isn't this big "house on fire" emergency either. OutSystems is a very opinionated platform, I understand the reasoning under their opinions (it's mostly to protect you from less-than-great developers), and I rarely disagree with their overall direction, just the specific implementation of certain things.

J.Ja

Hi all,

This topic of Trunk (with feature flags) vs Branch development is always hot.

Either way you do it, it always requires Governance! You can have feature flags that live forever, the same way you can have branches that seem to live forever, and neither is good.

The point here is that, practically and effectively,  the OutSystems platform, because the way it was implemented from the start and the way it has evolved, it only supports/allows one -- Trunk development with feature flags -- so you cannot choose, you are stuck with it. (*1)

Because now OutSystems platform is (finally?):

1/2) Truly Enterprise level in a wide landscape of big customers with big applications;

2/2) Getting a lot of attention from developers coming from more classic ways of developing with other programming languages (and so, not only developers that have only known the OutSystems way),

the OutSystems platform is feeling the pressure of "demands" such as this as "Branching". Developers are use to it, so they "demand" that OutSystems platform supports it. (*2)

And we all say that one is not better than the other, but you should be able to choose for yourself.

So, I think OutSystems as a decision to make:

1) Either says: "This (Trunk development) is the way we have always done it, and we are not going to change." -- and risks loosing a lot developers/projects/clients;

2) Or clearly states that this is an important topic and it will address it somehow in the near (?) coming future. (I see the "On our radar" tag on top, but that does not mean clearly anything).

I personally really miss "Branch development". The additional problem here is that merging in OutSystems is also not easy because the smallest elements that you can merge are entire screens/web-blocks and complete actions, so I will be very curious on how the R&D team from OutSystems will solve this, if they go through with implementing this.

(*1) - You can do a kind of branching by cloning espaces but this is tricky and not that straight forward.

(*2) - Another "demand" from classic development is "Check-in comments" (Idea)... Also miss it! Now I recur to workarounds, like filling in the description of espaces, to be able to get a small understanding on what was changed in a specific version of an espace.

--Tiago Bernardo

Hi all,

Feature flags are surely useful for what their name indicates, i.e., features, specially add-ons and configurable enhancements that can be pretty neatly isolated from the "main" code. 

However, I am very surprised that feature flags are being suggested as an alternative to code branching.

The real and obvious need for branching has been explained in quite a lot of detail in the comments in this thread and the original threads. 

The lack of branching support in the platform is really a pain point for any development team that is involved in maintaining/supporting live applications along with implementing new versions of the application, for example.

Also, please note the other similar (low-code) platforms do support code branching. 

https://www.mendix.com/evaluation-guide/app-lifecycle/version-control#5-how-does-mendix-support-branching-and-merging

Regards,

Vikrant Sharma

With Git branching also allows to control development and reduce amount of the commits. Now the platform is easily messed up with all types of though processes that are not relevant, when studying what the guy before me has been done.  If the branching has been done, the feature can be squashed or organised to single or fewer commit(s) and that then can be contributed to other development line.

There are two features, I would require to see on the platform is the support for branching and also unit testing (with mocking) of flows. Unit testing would allow TDD really well sometimes. As newbie OS developer, I do struggle more how to achieve testing than actual feature. 

It's been 9 years and this is still "On our radar", when working in bigger teams branching (and using personal environments) is essential for developers to refactor big chunks of code without impacting the rest of the team.

Hi Joey and others that have been active on this forum thread - 

We will be introducing the first version of an OutSystems branching capability this year.  The new capability will allow developers to create branches and test their code in isolation as well as the ability for multiple developers to collaborate. The product management team has been actively engaging our customers to collaborate (pun intended) on development of this capability.  We will be introducing the new capability to our customer base via a high-touch Early Access Program starting in July.  If you are interested in learning more, please let us know and we will actively reach out to you.

Best regards, Mark from OutSystems

I'd love to join this Early Acccess Program :)

Show!

We are specting this a lot!

We will test and adopt as soon as is present on EAP.

Great news! We are waiting for this also, it will help working with multiple people on different changes in the same applications a lot! 

In fact, it's a very good new that this feature will be implemented soon. I am waiting !!

Very interesting to read, as up to now OutSystems was very opinionated about why they did not implement more tradicional branching functionality.

+1
I was going to suggest this but seems like the feature already got its long-time fans!

It's really a pain having to "freeze" the development and depoly when a dev needs to implement something new.

+1 That is already available in the EAP?

Hi,

There is a private EAP.

Branch does not work on Personal Environments.

It also does not work on OutSystems 10 infrastructures.

You may ask to participate by sending an email to branching@outsystems.com.

Thanks

Will branching work for multi-tenant applications? The private area didn't.

Hi, any update on this?

Hi,

Please let us know expected timeline for this feature to be available.

Thanks

Ravi

Hi,

Is the branching feature still in EAP?

Thanks,

Leandro.

Hi Leandro,

The branching EAP has ended, and the team is exploring next steps based on the feedback and results of the EAP. We have no dates to communicate at the moment.

New to OutSystems, and in this situation a possibility to branch would be much appreciated.
I don't really understand why outsystem is against it? Is there any links and videos that describe this? Would be much appreciated if someone could post it here, since it seems to be a lot of people FOR branching.


TIA! 

I believe that this feature would be a valuable addition to the platform, as it would allow developers to manage complex codebases more effectively.

With branching, developers would be able to create different versions of their codebase and work on them separately. This would make it easier to manage multiple features or bug fixes without disrupting other parts of the application.

I 100% agree with you. Rojo

This is simply becoming a must have with ODC. The feature toggle approach only goes so far. And cloning is also not the most efficient way of working.

Branching is the only real solution for a smooth collaboration, and now that hot-fixes are out of the picture on non-dev environments for ODC, this seems like the straight answer to it. I don't see how teams would be able to to work efficiently on projects that have a non-continuous delivery model but for which development is ongoing for the next version after a release.

The effort to isolate functionalities with feature toggles could become quite huge. Reverting to a previous version, fixing the issue, deploying and then going back to the latest version with the latest features and manually replicating the fix (if still applicable) is also a very cumbersome way of working.

Having a main branch with 1 branch per developer while working on the same App would definitely make lives easier and most probably solve the hot fixing challenge in ODC at the same time.

100% Agree with you Gregory

I've been read some coments and I admit that topic is very hot... 
But I have an opinion about Branch in OutSystems..

I understand that OutSystems should have Branch with ramification.

If not possible to have only 1 option about branch. 

So could then have 2 way (Actual OutSystems branch and branch with ramification) options and the company chose wich way do ?

Another question.. How are the status of this topic ?

O11 will stay around, and OutSystems does improve the platform, but even on the ODC platform they did not change too much and still use Trunk based branching, with only a nice addition that applications can selectively use released libraries.

So what is the status of this topic, I would say dead. No version control changes to be expected in O11.