Hi, I would like to start general discussion about best practice of development of real application based on Corteza. Imagine, that we want to make a real working application, with users and data uploaded into our system. In long term perspective, we want to work on our application and continue development of our system. In order to minimize risk of failure I would imagine to use Development server and Production one.
On Development server I would like to test new solutions and create new features. Once some part of application is finished, I would like to update a namespace from Development to Production server.
Are you working in this way? Or everything is done on production server in You case? Is there any best practice how to perform upgrade of namespace.
One thing which comes to my mind is to take care not to change list of records in module, since it should not work. But what else should be considered?
Hi Pawform
Thank you for your question. I asked something similar a few weeks ago in an older forum post but unfortunately didn’t get any answers.
I would also be very interested in how professional developers write and publish applications with a development environment and a production environment. Only selected (defined) namespaces (fields, tables, modules, pages, charts, etc.) and workflows should be transferred from DEV to PROD. And no user data may be lost on PROD.
Are there any free developers here who could help describe their working methods?
It would also be nice if the developers of “Planet Crust” reported on this topic. You definitely have the most/best experiences there.
As long as this topic is not clarified or possible, I unfortunately cannot use Corteza for my customers.
There are no current features to properly support development environments.
You can hack it together using physical tables and database migrations, but that would be a lot of work.
Currently, my dev setup is to have an exact copy (except domain name and SSL) of the docker compose setup on my local machine. Changes are often made in production (e.g. changing the display name of a field is something administrators may do), so when I’m testing larger changes I clone the production DB and install it on my local machine.
I then develop, test, and make all of the changes necessary. If the final modifications end up being small, I make them manually. Other times I copy the delta’s (e.g. new modules) from the local db to the prod db.
If the changes are really large (this has happened only a handful of times), involve new tables, workflows, and other DB entities that have dependencies on each other, and I don’t want to do the work manually or think about copying deltas, then I wait until off hours and overwrite the prod DB with my local DB instance.