I am trying to create a dev scenario where I would create a project in a remote computer. Why so? So I could benefit of the advantage of hot deployment, and at the same time, being able to “disconnect” and let the app container running for the users to use the app.
I would like to do this temporarily for a set of users in our UAT phase, which would speed up user compliance.
Have tried to create the project in a remote machine (inside my network) but the project seems not to sync properly. For instance the ~/Project/.idea/cuba-project.xml file is not created, hence CubaStudio is not recognizing it as a CUBA project.
This solution would enable me to work on the project (almost live with hot deployment) as I am in the office.
Ok for the time being I have managed to install CubaStudio on the second machine and create a git repository where I would pull/push the changes from both machines…
If anybody has any additional ideas they are welcome.
I would assume that from what you are describing to achieve is a very tight feedback loop from idea to UAT, like users can sit next to you, they specify requirements and you implement it on the fly correct?
Generally speaking technically this is possible to achieve in various ways, although it is not very common scenario.
Technically you can achieve that via various ways:
gradle tasks that push the files to the tomcat directory on a remote server via ssh / mounted volume
configure the tomcat target directory to be a mounted volume (nfs)
but the most obvious solution is probably:
let your users access your dev machine via the browser
I said “not very common” because what I would consider is done in almost all other scenarios is to have a CI environment that plays as the orchestrator to pull changes, executes deployments. This has various other benefits as well that are not mentioned here.
yes indeed, it is more close to a DEV scenario than UAT, since this is a legacy application we want a small set of users to directly give us insights on certain modifications , and would like to be able to make changes on the fly almost, exploiting this capability of CUBA. After all taht is done we certainly would enter a more UAT related phase.
With this solution (git repository being accessed/updated from two machines) we more or less have a solution. When I am in the office I work on the inoffice dev machine, hot deploying all changes, whereas when not inoffice get the chance to work on fresh files.
It is more or less, although not fully optimized, a good solution.
Will slowly explore your Gradle solution. Can you recommend any good manuals/tutorials? Honestly don’t have much time left to spend on it, so if focused on the CUBA related tasks, the better.
Thanks for the time to answer it’s been really helpful.
No I don’t have any manuals on that. I just assume that it should be somehow possible to achieve something along those lines. Doing something via gradle was more a theoritical technical possibility. Honestly I would not really consider it. If I would be in your shoes i would either go with:
configure the tomcat target directory to be a mounted volume (nfs)
let your users access your dev machine via the browser or
setup a CI environment
Everything else seems to me like a questionable hack.