Skip to Content (Press Enter)
How is your experience with the OutSystems Community?
UserImage.jpg
Matthias Desmet
39Views
6Comments
Solved
How do teams handle parallel development in ODC without branching?
Question
1-Click Publish
Best Practices
Development
Deployment
ODC

Dear OutSystems community,

One challenge I've encountered in OutSystems ODC (same for O11?) is the lack of branching like Git. 

Changes are developed in the DEV environment and then promoted to TEST and PROD. However, deployments include all changes that exist in the application, including work that is still in progress.

This can become problematic in situations where a developer is working on a large feature that is not yet ready for release, while at the same time a small bug fix needs to be deployed urgently to production. Deploying the bug fix may also deploy parts of the unfinished feature, creating a risk for the release.

How are other teams managing this? Are there recommended strategies, best practices, or architectural approaches to isolate unfinished work and safely deploy urgent fixes without bringing along incomplete developments?

I was thinking of creating a boolean setting-variable: Dev-Branch. In dev set it to true, so the flow includes the new development. In prod set it to false, so it doesn't include the unfinished development in the flow.

Thanks!

Enjoy the weekend!

0
0
07 Aug
Copy Link
2021-09-06 15-09-53
Dorine Boudry
 
MVP
Solution

This IS a challenge, and the answer I know is a combination of (in order of importance)

  • build small features, in scrum terms, break user stories down in smaller stories if they get over a certain size, but you don't need to be doing agile to do this anyway
  • organize your pipeline to deliver fast and often all the way to production, so you don't get a whole bunch of 'waiting' features that are not ready to go because for example in your process UAT is mandatory and your business is only available for testing once every 6 weeks
  • don't make applications/modules too big, try to find ways of splitting them up along the same type of boundaries your features would most of the time not cross, increasing the likelyhood that any given feature only blocks part of the other developments
  • feature flags
    • use sparingly if needed 
    • allot time as integral part of the feature d.o.d. to tear all usage of the flag out when no longer needed
    • this is a bit more advanced than your dev-branch boolean
      • you do it at a per-feature level
      • can switch any feature on or off in any env, not only dev
      • for example, in UAT env, you can swith it off to test application as will go to prod to make sure the feature flag is not leaking anything of the new functionality, and swith it on to do user testing or demo's of the new features
      • There is a 'Feature Toggle' forge component, don't know what exactly it offers, haven't used it
  • agree on a hotfix method with the entire team, where you do these fixes (only if really necessary) in a higher env and immediately propagate the fix all the way back to dev, and talk about them during your daily so everyone knows what is happening

Dorine

3
0
07 Aug
Copy Link
2026-06-20 17-43-43
Sherif El-Habibi
Champion

Dorine has said all the vital and important points for this one. A small addition I just want to add one that's actually proposed as a means for such situations, though it may not be the best thing to do only for critical times.

OutSystems promotes the whole application state, not isolated changes like Git branches. So when you have an in-progress version sitting in DEV and an urgent prod bug comes in, you can't cleanly deploy just the fix without dragging the unfinished work along (unless you code it manually on PROD, which also gives you a warning before publishing).

One thing that can be done in crucial cases: make one of your lower environments a mirror for prod. Say you have 4 environments DEV, QA, STG/UAT, and PROD and you're preparing release 2.0 while your live version is 1.19. A bug arises in prod that needs fixing asap. So what's proposed is:

  • DEV and STG hold the new 2.0
  • QA and PROD stay on 1.19

This way UAT/business testing is done in STG normally, so end users don't mix with the testers working there. For any urgent bug fix that needs deployment or release notes, you do it in QA right away against the live version, then push it to PROD basically switching the order of the environments in LifeTime for that.

Again, this may not be a proper fix. The trade-off is that you temporarily lose a clean QA space for the 2.0 work testers end up testing in DEV with coordination with the team. That's part of why this only makes sense in genuinely urgent situations, not as a standing process.

This approach fits best when you've deployed a new version to STG and it may take some time to go live waiting on policies, CAB approvals, and so on leaving a window where PROD is still on the old version and an urgent fix can't wait. After it goes live everything goes back to normal

0
0
08 Aug
Copy Link
2025-12-08 23-06-08
dex2dot0

I don't think approach works in ODC as I believe you can only ever work off DEV directly and promote up. I don't believe there is a way to "do it in QA right away". Would be happy if I was wrong here though as it would be very convenient. 

0
0
11 Aug
Copy Link
2026-06-20 17-43-43
Sherif El-Habibi
Champion
2021-09-06 15-09-53
Dorine Boudry
 
MVP

@dex2dot0 ,

🤦‍♀️

yes, i completely missed the 'in ODC' part of that question, it is right there in the title !

so, hotfix in higher env is not possible in ODC

also, the ODC limitations make it harder to make small applications

1
0
02 Sep
Copy Link
UserImage.jpg
Matthias Desmet

Thanks Dorine and Sherif for taking the time to reply and your tips and tricks!
Have a nice day!

1
0
10 Aug
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.