Best practice for working on a site that is accruing user-generated content

I’m new to Bubble and trying to get my head around one thing: I’ve built a simple site that displays episodes of a new podcast I started:
So far so good - everything works.

How though do you do content updates while working on new features?

Is there a best practice for how to work on a site that is constantly getting new content and user generated content? Do you make all the schema changes and UI design changes on dev and then just keep a list of what you changed such that when you’re ready to roll out these new features, you:

  1. make the site inaccessible so no UGC can happen
  2. do a final copy of the Live DB → Dev
  3. redo all the schema changes you made
  4. deploy the dev version of the site to live
  5. copy the Dev DB to Live

Does that seem right or is there a better way to do this?

Hi there, @sean18… I’m guessing I am missing something here, but I don’t know what it is. The new content (user-generated or otherwise) is constantly going into the live database, right? So, you should be able to work on new features (even those that include data type changes) and deploy them to live whenever you want without having to make the site inaccessible. Sure, you might pick a time to deploy when the fewest users are on the site so as few people as possible see the refresh banner. But again, I’m not sure why you would need to make the site inaccessible, and I don’t know what you mean by “redo all the schema changes you made”.

Anyway, maybe someone else will jump in if they see what I must be missing, but it should be as simple as making your changes in development and deploying those changes to live, and that should have no effect on the content in your live database.

Oh, and if I have totally missed the mark here, maybe you could give some examples of the kinds of changes you are talking about and how you expect them to effect live data, and then it might be easier for folks to provide suggestions.


Thanks for your response @mikeloc. So an example of a feature I’m adding soon is the ability for a podcast listener to create an account and monitor any activity on a particular episode (activity as defined by people nominating a new project to tackle a problem discussed in the episode).

This would involve the creation of a few new tables in the db.

So what about the scenario where I’ve published some new episodes adding them only to the Live db. I go to deploy the new monitoring feature from dev which doesn’t have the latest episode content from live. It seems like it will blow away the most recent episodes on the live site unless I do a copy first in the other direction (from Live → Dev). But then at that point you’re stomping on the schema changes you made on Dev, no?

It seems like as soon as you do any work on Dev while making content changes on Live you’ve essentially forked the db’s and one will have to eventually overwrite the other unless i’m misunderstanding something crucial about how this works. Any clarification would be appreciated. I suppose I should just clone my project and go try to do this stuff and only worry once it’s an issue :wink:

I think that might be the case here. :slight_smile:

Deploying development to live does not overwrite the live database with the development database from a data perspective. Yes, changes to the data types themselves will be deployed, but actual data is not affected. There is a completely separate action (and rightly so) to overwrite the data in the live database with the data in the development database (or vice versa).


It seems like as soon as you do any work on Dev while making content changes on Live you’ve essentially forked the db’s and one will have to eventually overwrite the other

Maybe I’m missing something entirely here (and there definitely can be situations where you’ll need to modify live data after making changes to your database structure and deploying them to live) - but I don’t see how deploying changes to your app will affect the data in your live database?

Nor do I understand why you’d want to copy your dev database to your live database in this case?

Just make the changes you need to your app, deploy them to live, and if needed update any live data to fit the new database structure.

Maybe I’m misunderstanding what you’re trying to do, and what you’re concerned about - so perhaps some further clarification on your use case might help…

1 Like

OK thanks fellas. Appreciate the clarification.

I didn’t realize it was possible to copy the schema from Dev → Live independently of copying the data as well. That solves everything with the exception of when the new functionality on Dev relies upon existence of new data in new tables that won’t yet exist in the live site. Presumably the advice there is to just replicate that data manually on live so you don’t blow away what’s already there in other tables.

Anyways this is great to know and I appreciate the responses @adamhholmes @mikeloc