13
 Followers
76
 Likes

Branching

Collaboration
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 (37)

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.

see:
http://www.outsystems.com/wisdomofthecrowds/IdeaComment_List.aspx?IdeaId=64
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
or
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
4. PROD

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.

J.Ja



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

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 :)


Merged this idea with 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 04:22:43 by Vikrant Sharma)

Please add the support for simple code branching and merging. It is very badly needed and I was quite surprised that this basic software development feature is absent from the platform. 

Without the branching feature, we are not able to handle typical software development, release, and maintenance lifecycle challenges such as - independent feature development, separation of new development code from critical bug fixes in released/live code, and similar situations. 

I noticed elsewhere that"cloning" has been recommended as a solution. Please note that "cloning" of espaces or creating copies of entire applications is not really a practical alternative to branching and merging because of the way Outsystems handles the modules (separate ids, new names, different entities, challenges in merging, challenges in making the cloned espaces as the new released versions with the same names of the older espaces, managing existing data, etc). 

The need for easy branching and merging support cannot be ignored. It is one of the basic concepts software development lifecycle and software maintenance.




This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

Indeed. We need a way to tag and comment on published versions as well.



This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

Nice opportunity to bring more improving to Dev 



This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

Could you give an outsystems example why you want to branch?

I don't like the idea of having to merge more often than needed.


It's all about the process and when to develop what,when and why.

With outsystems you could have small release cycles, so there is no need for branching...





This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

Branching is needed in many situations in software development, release, and maintenance life-cycle. Let me give a typical example that most software development teams would have come across.


Suppose there is a Outsystems application that is already live, and being used, in Production environment. If any critical or showstopper kind of issues come up in Production, that need to be fixed immediately, the application support team performs a code change in the Development environment, and after following the due QA process and pre-release checks (in QA and Pre-Production environments respectively), the code is pushed to Production environment.


Now consider that the next version of this application is planned, including major changes to the existing application with new features. Assume that the overall development and QA process of the new version of the application takes 2-3 months to complete, and those features cannot be incrementally released in parts. The development team starts performing those changes in the development environment. During this period of 2-3 months, if some critical or showstopper issues come up in the live code in the Production environment, that need to be fixed immediately, the development team obviously cannot perform the bug fix in the current development environment. The development team would then have to save the current development, rollback to the released version, perform the bug fix, follow the QA process and pre-release check, finally release the fix in production environment, and then revert to the new development code version in the development branch and continue working.


There are other options as well, for example:

 - Making the critical bug fix directly in Production or Pre-Production environment, but this compromises the QA process and pre-release checks.

 - Creating a copy or clone of the individual espaces or entire applications, but this is not a preferred solution due to various reasons: separate IDs, new names, different entities, challenges in merging, challenges in making the cloned espaces as the new released versions with the same names and URLs of the older espaces, managing existing data, etc.


If branching feature was supported, it would have been possible to simply create separate branches for released code plus critical bug fixes, and new feature development, and merge as and when needed. In the example mentioned above, just to elaborate a bit more, if branching feature was supported, the application support team could work on the "release-and-maintenance" branch, while the application development team can work on the "new development" branch independently. After the new development is completed including the QA process, the "new development" branch changes would be merged with the "release-and-maintenance" branch, and then released as a new version of the application.


Hope this clarifies the requirement.




This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

Changed the category to Collaboration




This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro

I agree with Vikrant,  we often need to merge bug fixes made in the main release back into older versions that are in production. 

One problem is that the merge selects ALL the new code and you have to un-check it all to only select the updates that are needed (we may want to keep 99% of the old code). The option to simply "Select All" from the other side would help - at present you have to manually select every single item!

The other major problem is the consequence of copy/paste and cloning (changed IDs) as this makes merging impossible. It would be far better if it had an option to compare "textually" (by action names) rather than using IDs, so the cloned blocks can be compared. There should also be an option to ignore all layout differences - do I care if an action ball has been moved 5mm to the right? I think not. 

As a result 9 times out of 10 we end up replicating the changes in multiple versions manually - which is tedious and prone to accidents.



This comment was:
- originally posted on idea 'Improve Version Control to support Code Branching and Merging' (created on 21 Sep 2018 by Vikrant Sharma)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:19 by Carlos Alfaro
Merged this idea with 'Better Branching' (created on 03 Apr 2018 12:39:12 by Patrick Baanvinger)

When you make a release of an application, you can develop for the next iteration. But maintaining the publiced version with hotfixes through OTAP and developing new functionality is hard to do.

Merging the hotfixes and new developments in a new version is hard to do.


A.K.A. Better version control ;) 



This comment was:
- originally posted on idea 'Better Branching' (created on 03 Apr 2018 by Patrick Baanvinger)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:40 by Carlos Alfaro

Changed the category to Collaboration




This comment was:
- originally posted on idea 'Better Branching' (created on 03 Apr 2018 by Patrick Baanvinger)
- merged to idea 'Branching ' on 30 Nov 2018 09:17:40 by Carlos Alfaro
Merged this idea with 'Working in branche lines' (created on 26 Mar 2018 09:03:52 by D.)

I would appreciate it if OutSystems also offered the opportunity to work in Branche lines. You can then quickly go back to the starting point and merge stories when you have finished. I know that OutSystems keeps track of versions but a Branche line is just a bit more clear.


Idea:

Offering the possibility to work in branch lines. Developers can  quickly return to the starting point and merge their work easily when they have built a functionality.



This comment was:
- originally posted on idea 'Working in branche lines' (created on 26 Mar 2018 by D.)
- merged to idea 'Branching ' on 30 Nov 2018 09:18:02 by Carlos Alfaro

Changed the category to Collaboration




This comment was:
- originally posted on idea 'Working in branche lines' (created on 26 Mar 2018 by D.)
- merged to idea 'Branching ' on 30 Nov 2018 09:18:02 by Carlos Alfaro
views
2028
Followers
13