Hi, I am evaluating the move to ODC and I am struggeling with the problem when two people are working on the same feature. Let's say the Developer "ImproveOldFeatureEngineer" is working on an old feature. This means, he is going to deploy a running container over and over again.
A second developer "FixEngineer" needs to work on a hotfix of the same feature, and has to deploy quickly to production.
The problem: When FixEngineer wants to deploy to production, ImproveOldFeatureEngineer is not finished yet and is not possible to deploy, since they are working on the same branch.I can think of two ways of solving this:- Feature flags: In this case I don't like this at all, since the feature toggle needs to be done on the code itself (as it was until now, which I don't like).- K8s namespace per Developer: and later, the application deployed to production is given by the namespace (or maybe a middle step when all the namespaces get merged on the default one).
The use I would do to Feature flags/toggle would be only on the microservice level: whe I could toggle the whole container or not, makeing the toggle effectively on the feature/microservice level and not on some parts of the feature, which leads to a tech debt.How is this supposed to be solved on ODC?Thank you in advanceEDIT: Using namespace per branch is what other DevOps platform do. EDIT 2: Another mega crazy option would be to allow some kind of local development and connect to the cloud. A kind of custom telepresence+skaffold tooling
Hi @Francisco Roa,
To avoid blocking deployments, a recommended approach would be to adopt a branching strategy where each developer works in their own feature branch.
For quick hotfixes, FixEngineer can create a separate hotfix branch, allowing for independent deployment. Once the hotfix is applied, merging back to the main or shared branches can be done via a controlled process. Using namespaces per developer might also work, but it adds complexity.
In ODC, deployment isolation is usually managed via branching or similar separation strategies to avoid conflicts. Telepresence or Skaffold setups could also be explored if you need tighter control for each dev environment.
Hope this helps!
In the ODC, there is no concept of branching. Every time you publish, a new revision is created. When you deploy to a stage, a version number is generated.
For example, if you've made 100 publishes (i.e., there are 100 revisions) and you deploy revision 100 to production, it will create version 0.1.0 (assuming this is the first deployment). Let’s consider revision 100 as the baseline for production.
Now, suppose your developers continue working on new features, resulting in 10 more revisions, with the latest being revision 110. Now there is an issue in production and you need to hot fix the same. To do this, you’ll have to stop development, open revision 100, and apply the hotfix.
When publishing the hotfix, you must select "Override with this revision" to ensure no changes from revisions after 100 are included in production. This will create revision 111. Next, go to Deployment, select revision 111, and deploy it to production, creating version 0.1.1.
After deploying revision 111, you can select "Compare and Merge with another version or file" to compare with revision 110. Merge the changes and publish, which will create revision 112. Development can then continue from this point. ( You may also open revision 110 and merge changes from 111)
Note that you cannot have multiple revisions of an app in a stage. The deployed app revision overrides the previous revisions, so version 0.1.1 (revision 111) will override version 0.1.0 (revision 100). i.e Production will not have two versions running at the same time. ( Ref : https://success.outsystems.com/documentation/outsystems_developer_cloud/deploying_assets/ )
I understand this might seem complex, but if anyone has a different experience or approach, they are welcome to share.
This sounds like a cherry-pick, isn't it?
@Francisco Roa ,
i think there are 2 way may help you first is the fast but not the perfect from maintenance , bug fixing , add new features .. etc , is clone you application to prevent any performance issue or bug in the old application and open you finish you update merge 2 application or depend on the new one but that will required
- if there are any fix need to be added for the both application old and the new
the second option is use Feature Toggle Management and it's prefect to prevent any interruption of new development in the existing application but need to make sure you use it in the correct way ( in all screen, times , actions .. etc )
https://www.outsystems.com/forge/component-overview/9664/feature-toggle-management-o11
https://success.outsystems.com/documentation/how_to_guides/development/feature_toggle_in_outsystems/
I thought about cloning the app, but it could be more complicated than adding feature toggles. I have installed Feature Toggle