Understand seperation of data in DEV and PROD?

[gerhardmpl]

First, let me apologize if my testing and/or reasoning is wrong, as I may be completely off the mark here.

While preparing a PoC app for test in production, I wanted to understand how data in the production (PROD) environment (aka "published app") is protected and separated from data in the development (DEV) environment (aka "unpublished, work in progess app". I am aware that the datasource is shared and that there is only one budibase stack / budibase database). My approach was to test this with a simple app on the BB cloud offering, where I changed data in the published (PROD) and changed (DEV) app to see what was happening respectively.

1. initial app publish from DEV to PROD includes dev data (let's call them initial dev or idev data)
2. changes on idev data in PROD make it to DEV
3. changes on idev data in DEV do not make it to PROD
4. deleting idev data in PROD does not delete data in DEV
5. adding new data in PROD (nprod) makes it to DEV
6. changes on nprod data in PROD make it to DEV
7. changes on nprod data in DEV do not make it to PROD
8. deleting nprod data in PROD does not delete data in DEV
9. adding new data in DEV (ndev) does not make it to PROD
10. changes on ndev data in DEV do not make it to PROD
11. doing some minor changes to screens in DEV and republishing the app brings all DEV data to PROD

Maybe I am misunderstanding the deployment process, or my tests are not adequate, but I have some issues with my findings.

Depending on the app data, having PROD data in DEV will most certainly be a compliance issue in a corporate environment because of segregation of duty and need to know principle.

Another problem is that I would expect a lot of crash and burn or smoke tests in DEV, which will create, change, and delete a lot of arbitrary data. This must not be published to PROD when the app is (re-) published.

This leaves me wondering how an app can be used in PROD while development continues although we cannot have different datasources for DEV and PROD? How can we protect production data in an agile development process with short sprints and regular app releases?

As I said: as a BB noob, I may be completely off the mark here, but I would love to understand the deployment process and the mandatory separation of DEV and PROD data.

edit: some clarification and typos

[mjashanks]

Hey @gerhardmpl

All of your observations are correct. Prod replicates to dev, but not vise versa, until you publish. On publish, all data gets replicated from dev to prod.

One point I would clarify...

the datasource is shared and that there is only one budibase stack / budibase database

Budibase dev and production databases are actually 2 separate databases that sync with each other at the various points that you describe.

I completely understand your issue around compliance, and agree - I would like to see a time where we have more segregation over prod and dev data.

Our decision to implement it this way was the most simple solution. A Budibase app database (both dev and prod) contains both

1. Schema for the apps - Data schemas, Design section and Automations definitions.
2. Data of internal tables

When we publish from dev to prod, we need to at least replicate the schema for the apps. Copying ONLY the schema is completely possible, and is a feature that we should definitely consider in the future.

However, copying the data is a little more complicated, as sometimes you would want to copy the data, and sometimes you might not. An example of when you do want to copy data is when updating lookup or reference data.

The ideal scenario here is to give the user control of what data to copy over. As you can imagine, presenting this to the user gets quite complicated. This is why we haven't implemented it (priorities).

So, we had to choose between

• Never sync the data on publish
• Always sync the data on publish

Since we had no other way to copy data across, we chose to "Always sync the data"

I realise that this is not the ideal solution, but hopefully, you can understand the decision-making process behind the current method.

[gerhardmpl]

@mjashanks thank you for your detailed explanation. It helps me to better understand Budibase’s options of use and I appreciate that.

What I still would like to understand is how a best practice development and deployment process would look like that does not impact the data in PROD.

Prod replicates to dev, but not vice versa, until you publish. On publish, all data gets replicated from dev to prod.

This means that you cannot test in DEV, because all data from DEV is replicated to PROD? For this reason, I export the app to a separate DEV instance and manually merge (edit) the changed apps schema (data schemas, design section, automations) in the PROD instance. Personally, I find that tedious and error-prone, but now I understand that more clearly. Or is there a better approach?

Reading #3682 I came across an important hint:

Syncing happens whenever you open the app in the builder.

This is in line with my finding that you cannot just deploy to PROD at any given time while you are working in the builder because that might cause data replication issues. There must be some sort of downtime for user and for builder log out / log in, syncing and deployment. But I need to test that more thoroughly and with more patience (which is not my core competency).

#2869 and #4630 are interesting reads as well.

[magickaito]

@gerhardmpl have you figured out a clean way to separate dev and production data? I just realised this challenge today...

[gerhardmpl]

@magickaito unfortunately there seems to be no good way to separate DEV and PROD data. For the moment, I am doing it the way I described above, since I do not (yet) trust syncing data when deploying to PROD.

[phifogg]

Oh ... wow. This is a great thread. I just wondered why some of my data is in sync and some not. I believe it is very very important to understand when a sync happens in which direction.

I started digging into this as I saw duplicate AutoID's one some records and wondered how/when this would happen. But now that makes more sense. I probably need to think about this more as I especially do not want test data to be published (or for the sake, be available on prod).