I want to setup production and development versions of my apps, as described in Best Version Control Options. I understand the concepts, but I’m a bit hazy on how data tables work with clones.
When I clone an app that has data tables, the clone seems to get its own copy of those data tables (at least, rows inserted into one don’t show in the other).
So, the question. If I have several apps that share data tables, and I want to create production versions of those apps, it seems as if I would need to:
-
Clone each app individually. This would give each its own (non-shared) copy of the data tables, right?
-
Delete the shared tables from all the apps except one, and then add them back to the other apps as shared tables so all the production apps are working off the same tables.
Am I missing something that’s going to make things more difficult than that?
1 Like
I’m looking to make this leap as well and my initial fooling around has led me to the same conclusions.
Then, I’d follow Stefano’s nice instructions, which I find myself going back to a lot these days.
Good luck. It sounds like you’ve got it figured out as far as I can tell.
1 Like
I also split things up so that server modules are in a separate app. The ‘main’ app has Forms and data tables and the sever modules app is a dependency.
That way, I can have a clone of the main app with a dependency on the dev version of the server modules whilst the live main app is dependent on the published server modules.
4 Likes
Idea: As a failsafe, the Development tables could include something to distinguish them from the Production tables. Likewise for the two Dev and Prod Server Modules apps.
Thus, if any app’s configuration gets screwed up – so that dev-only or production-only code is being called in the wrong setting – then this would make it possible it to check, before anything too embarrassing occurs.
I know, configuration errors never happen in practice 
, so there’s never any value in automating any safety checks…
2 Likes
On additional gotcha that adds a #3 to my list from above:
- Fix up any linking fields that were previously linking to tables you deleted and readded from the other app. They’ll show as linking to an unknown table until you remove that field and add it back, linking to the shared table you just added.
I should clarify: this applies to tables in the app that you are not deleting, that link to tables you are deleting in order to add from another app. That link needs to be rebuilt afterward.
4 Likes
In this case, it might be better to use “conventional” foreign keys in place of row_ids. They should not need such a step.
1 Like
Another:
- if the Users table was one you dropped in order to add from another production app, go to the Users service and tell it to use it again.
Avoiding row ids would avoid step #3, but I think that’s only a problem because I’m making this transition with an existing project that’s fairly complex. If I’d started with the development and production apps originally, they’d have evolved together and using row ids wouldn’t be an issue.
4 Likes
While this doesn’t deal with data tables, I’ll put it here because it’s another prod/dev app gotcha I just discovered.
- If you have multiple prod/dev apps and some of them have others as dependencies, each of those dependencies will need fixed up. For example, if you clone your dev apps to create production apps, the production apps will still be depending on the dev apps.
As long as you keep the import package name the same, the old references in forms will still work.
Again, this is something that won’t be an issue if you start with a production and dev app split right from the very first.
2 Likes
I haven’t tried this (yet), but perhaps it can help with the Dev-vs-Prod .yaml files:
Once it’s understood which elements of the .yaml file are (should be) common to both, and which are not – some of which will vary from project to project – then it should be possible to automate the transfer of the common parts from one to the other.
In the meantime, that diff listing may help. Ordinary line-oriented comparisons are doomed to fail, because much of the data is unordered, and may be saved in a different order/layout each time.
2 Likes