I have some experience developing in the xs classical apps in the SAP Cloud platform neo evironment. And plan to migrate to xsadvanced in the cloud foundary landscape. I have a few fundamental doubts which sadly i could not get answers to even after reading the documentation.
If i understand correctly XSA is cloud foundary extented by SAP to support SAP HANA 2.0 as a service via the HDI Container, allowing the tradional xsjs to run as a node.js container and bunch of other SAP specefic serivces ?
the MTA (mutlti target application) development promoted by SAP looks neat however i have a few questions when it comes to working in a env where multiple developers work with the same MTA in the "dev" space for example.
the typical MTA is combined of a web module where the UI part resides , node module to hold the services and a db module that is the entire HDI container which holds tables,views and the actual data .
the developers dont work with WebIde and use VSS code and cf CLI.
Question 1 : if i want each developer to have an isolated MTA when developing , then each developer must push the same MTA app with a different name when he works with works for some feature development ? (preferably some feature brach that gets pushed as a new app) . every line of code change then needs a push to CF
Question 2: Pushing the app with the same schema name in MTA file creates a new schema for the second developer in the same HDI cointainer (i am not sure if this correct however this what i understand from : here
But the second schema will remain empty and many not contain data, do we then take care about data replication from schema 1 to schema 2. wont this explode the space usage ?
As i said, i did not find documentation about how multiple developers can work on the same MTA app in the shared space so any guidance will help
thank you
Multiple developers are able to work on the same MTA app, because of git functionality and different workspaces dedicated for each developer. More to that, you can even personally have even more that one workspace, which means you can have different features developed by yourself separately.
When you build your container or run your application in your space, each time get a unique schema name or application url, this means you can work independently.
A bit tricky part is when you want to join your commited code with other developers. Basically, it depends of how big your project is. If you have a large project, it's better to control merges using Code Review and Unit tests, or maybe you are in a small project and work on different files, which means you can merge your code easily to master branch by yourself.