Clarification on branching in CI/CD workflow

1

In the docs it says that if you branch a workspace:

“You CANNOT manually change System Parts of parent Environments after Branching (for example, one Environment can’t be manually changed after another is created from it).”

Could you please explain what is meant by “manually” in that sentence?

I understand the User table is a “System Part”. Does that mean we cannot disable a user if the workspace has been branched? Does it also mean that new users could not sign up for our app because it requires row to be inserted in the Users table?

2

Hello!
Actually, CI/CD workflow does not cover CRUD operations for data records, so you can freely manage Users table records. So ‘manually’ here refers to the opposite of migration flow which works for schema changes in particular.
I guess this section of our doc confused you, right?

3

Ah, thanks for the explanation. That’s actually great news. The part that confused me “System Data”, I incorrectly assumed this to mean any data in system tables.

1 Like
4

Dropping in this video here! 8base Academy - How to Set Up a CI/CD Pipeline and Migrate Workspace Environments- Course 22 - YouTube

1 Like
5

Hi Sebastian,

Thanks for the video - very helpful. I have a few questions about the workflow.

  1. Is it possible to migrate only schema changes (i.e. new tables or columns in tables) without migrating data changes? I can foresee this as a common scenario. For example: We add a couple of columns to a table to support a new feature, we create a bunch of test rows in that table to test out the feature, then we want to apply the changes to the parent environment but ultimately we don’t want to migrate our test data into the master environment.

  2. Is it possible to apply migrations from dev directly into master (by-passing staging)? It’s not that I have a need for this, just curious if it’s allowed.

  3. Can you migrate data down the hierarchy? For example, we may have long-lived staging and dev environments. Over time, master acquires a lot of new data. Is it possible to update the existing child environments with the new data or do they need to be deleted and recreated?

6

Hey @daniel !

  1. Data is NEVER migrated. Data can ONLY BE COPIED WHEN CREATING A NEW ENVIRONMENT. However, you cannot migrate data between environments (certain system tables data, like Roles, are the only exception)

  2. It’s not! You have to obey the pipeline you set up. You can always rebuild your pipeline though by migrating (or deleting) all changes, deleting the environments, and then recreating them.

  3. Yup! Just make sure any change you care about get migrated to Production, then delete Dev and Staging, and then recreate them off Production with 8base environment branch --name Staging --mode FULL