Bubble: How to Go Live

Can someone confirm if this is the correct information as of now (4 October 2017), as I’m not sure if I have this correct:

First Going Live:

  1. On development - Add LIVE URL to Settings page. Live URL will change from your default Web Host page to the Bubble default Web Host page.
  2. On development - Click ‘Deployment and Version Control’ using dropdown option. Deploy to LIVE.
  3. On development - Click ‘Copy Between Versions’ in App Data tab. Copy to Live. This ONLY copies database structure.
  4. On live - Upload all the live data you need via CSV
  5. On live - Go through LIVE Data Type fields and select/add all your defaults as these are not copied to LIVE.

Maintenance:

  1. Do in the wee hours so less customers/data affected
  2. On development - Click ‘Deployment and Version Control’ using dropdown option. Deploy to LIVE.
  3. On development - Click ‘Copy Between Versions’ in App Data tab. Copy to Live. This ONLY copies database struture.
  4. On live - Upload any extra live data you need via CSV or via your Admin Interface screens you have built.
  5. On live - Go through LIVE Data Type fields and select/add all your defaults for any NEW fields you created as these are not copied to LIVE, but existing field defaults are.

At no time is your LIVE data at any risk of being lost as it is never affected by deployment or copying the development database to LIVE (unless of course you remove a field from existing at all).

2 Likes

I don’t think this is quite right.

The database changes are copied across when you deploy to live. Doing that extra copy seems unecesseary and pretty dangerous.

Careful, there are a few things:

Live

  1. Yes
  2. Yes
  3. No, this copies app DATA only. The deployment process in #2 is what publishes your app structure. Also, this will OVERWRITE the target database. So if you copy from development to live, any live data in there before will be overwritten. You do have the option of selecting which data type you want to copy. Just be careful with this especially once you have live users generating live data.
  4. If necessary for every deployment, sure.
  5. I’ve never noticed that defaults don’t get deployed? They should…

Dev

  1. Yes, generally off hours are best, but do whatever is best overall. Consider major bugs that need to be pushed immediately.
    2., 3., 4. Same as above

Data is not affected from deployments alone as they don’t involve data. Yes, if you remove a field and there are still things in your app that rely on that field, that’s your responsibility to update. Data IS affected when you use the copy function. Please understand that copying from any direction will overwrite the target location, it doesn’t just add on to existing records.

3 Likes

Thanks heaps both of you. So I have corrected it and added to it as follows. Can you have a read…

First Going Live:

  1. On development - Add LIVE URL to Settings page. Live URL will change from your default Web Host page to the Bubble default Web Host page. (Usually less than 30 minutes, sometimes takes longer).
  2. On development - Click ‘Deployment and Version Control’ using dropdown option. Deploy to LIVE. This copies your entire app to LIVE except for the app data.
  3. On development - If needed for your app, click ‘Copy Between Versions’ in App Data tab. Copy to LIVE. This copies your app data to LIVE.

Maintenance:

  1. Try to release fixes/new features in bulk if you have a popular site because Customers who have your site open in a browser tab will be informed that you have made an update via a message on the site whenever:
    a. Database structure has been changed (eg. new field added)
    b. Visual design and functionality has changed
    c. Workflow has changed
    they won’t be informed if you only add new data into a table or if they do not have your site open in a browser tab
  2. If you have a popular site, you may like to release your update in the wee hours in case of any issues that crop up as a result, to reduce impact on customers.
  3. On development - Click ‘Deployment and Version Control’ using dropdown option. Deploy to LIVE.
  4. On development - ONLY IF you have added a new feature that requires new default app data - Click ‘Copy Between Versions’ in App Data tab and ONLY select the new data table that has the app data in it you want to copy to LIVE. DO NOT copy all data tables across as this will overwrite all your User’s data.
5 Likes

Hello @cowontherun @romanmg

How do I come to this section? I am in paid version and every time I preview it says you haven’t deployed your app to live yet. Then tells me to go to version tab and click on deployment. However in versions tab there is nothing to click on and no deployment mentioned.
& also where can I find all of this section about live and Dev.
Please help thanks a lot.

I did have this happen to me once and the fix was simple but I can’t remember what it was. Usually there is a big orange button in Version Control saying ‘Deploy Development to Live’.

I think Bubble are currently redoing their User documentation to make their Help pages easier to find, I don’t think they have a Go Live page in the manual, could be wrong, double-check their video tutorial section as well.

Will leave to someone else to answer, otherwise contact Bubble Support.

alright thank you!

Which link do you use to go live?

If you are on a hobby plan, the app is on a hosted Bubble link.

I am on hobby plan for now yes but where can I find the Bubble link?

Hi there, if you just go to your editor and click on Development top right of screen then click on Development and Version Control, there is a button ‘Deploy Development to Live’. That will make your site Live. If you don’t see this button, check your Settings section.

Hey how do I revesre going live. I think i did but did not mean to. Also dont remeber how I did it.

Does adding items to option sets require redeployment, or are these like adding items to a database table?

You need to deploy to live. Also note option set data is not private and can’t have privacy rules applied so make sure it doesn’t hold data you don’t want other developers to see.

Thanks for that!

It makes me wonder whether I’m better replacing one of my option sets with just a regular datatype, since it would requires semi-frequent updating and is much easier to manage than option sets are - expecially for large ones with many entires and attributes