Hi there. It's Sebastian, Product Manager over here at 8base. Today, I'm going to be walking you through 8base's native implementation of CI/CD, which can stand for continuous integration, continuous deployment, and continuous development, all of the above. Now in this, we're going to dump into our it tool. I've also set up a little workspace where we're going to change the data model to show how I or how CI/CD works. However, what's really important to understand about CI/CD is why it's relevant.
Essentially, in a workspace as we're developing, if we're just in development, we can use one workspace because whether or not we break it, we're constantly developing and things are constantly changing. However, after you do that first release to your users, your users are usually hoping or at least relying on some level of stability within your product and platform.
If, while your users are using your product, you have your developers going in and adding new features, changing data model, trying out new things. That's not really going to work because your software might continuously be breaking while your users are trying to utilize the service.
To solve that problem, what we do is we create up different environments of a workspace such as production, which is the one that your users will always be relying on; staging, which you'd then be able to maybe use for QA testing; and development, which would be where you develop or push developmental features and even feature branches if you have separate development efforts going on at one time. Now all this is possible using 8base's CI/CD system, which is super powerful and we're going to dive into right now.
The first thing that I'm going to show here is actually inside the 8base console, which is this little area up here which is a drop-down called Master or with the select option Master. Now in any professional plan workspace, you should see a little button up here called Enable CI/CD. That button, once you click it, will give you this exact interface that I'm looking at and that essentially just turns on CI/CD as a feature of your workspace.
Now, by default, the workspace that you create is the master environment as soon as you enable CI/CD. However, off that, we can create as many different environments as we require.
Now, what's important to understand about CI/CD is that there's an implied hierarchy. For example, if I branch an environment off master, that is a child environment to master, just as if then I branch another environment off staging, that would then be a child environment to staging. In this example, we're going to create three environments which are master, staging, and development. In order to do that, we're going to jump into our command line.
Here in my command line, I've taken a few steps. The first one being that I initialized an 8base project using 8base init. Then inside that project, I ran 8base configure to select the workspace that I want to interact with. In this case, it was the SuperTasks Backend. Now that I'm inside here, I can start running my different commands which are environment, migration, and commit commands. All these are the commands I'm using when interacting with the CI/CD system.
The first thing we're going to want to do is create our environments. Let's just first run 8base environment show and we see that we are in our master environment. The next thing that we're going to run is 8base environment branch -n for name and give the environment name that we want, in this case staging.
Now, the next thing that's important to note is that we can specify whether or not, when branching an environment, we want to bring all the data with it or leave the data and only the system parts such as data model and stuff like that. In this case, we're going to use mode full so that everything is copied over to staging. Now our staging environment was created.
I'm also going to go ahead and just increase the size of my text here so it's a little easier to read. Cool. Now what we're going to do is we're going to switch environments and switch into our staging environment. I'm going to run 8base environment set and this is going to let me select between the environments I've created. I'm going to now go down to staging and set staging.
Keep in mind that that change in environments there was only the change in the environment locally. The console, it's a completely separate interface that we are dealing with. This is just for our local development environment. Now that I'm in the staging environment, I'm going to run the exact same command again and I'm going to change the name to Dev.
Now we are branching a new environment called Dev off of our staging environment. And instead of full, I'm going to say system, meaning that we're not copying into our development environment any data from the parent environment, just schema data model, roles, permissions, all that type of stuff, and run that. Once that's done, he will be back. We've now gone through all the steps of setting up our three environments, master, staging, and Dev.
Now what's really cool is if we go back to the console, we can see that after reloading the page, our environment selector now reflects all those different environments, staging, master, and dev. When we cloned the staging environment from master, we said that we wanted to bring everything full clone. If I go to my staging environment now, and let's take a look at my list table, I can see that actually cloned my data in that table over.
However, we said system only when we cloned our Dev environment. If I click into my Dev environment, that same table is empty because we left all the data in its parent environment. Now, inside this Dev environment, this is the only environment now that we can actually make changes to as its parent environments are locked.
This is to protect against anything being broke or anything getting broken in those parent environments, as you're usually relying on those parent environments to be stable environments or stable testing environments, while development or the youngest child branch is the one that you can update your data model, deploy new functions to, all that type of stuff.
What we're going to do is we're going to go into the task table and add a new field to our task table, something simple. This field is going to be called priority and we're going to make it a switch. The priority options of the switch are low, medium, or med, and high. Say it's a mandatory field and low is the default. Create that field. Now that's part of our schema. Now that's added to our tasks table.
But what's cool is that if we go back to staging now, we can see that that field doesn't exist on our staging environment because we haven't committed it or we haven't migrated it to that environment. It only exists on the development environment, which is the one that we are allowed to actually go in and make changes to.
Now we could be creating new tables, we could be configuring new roles, we could be doing a lot of different things here, right? However, what's really important is how do we actually now take that change and migrate it to a parent environment?
For that, we're going to jump right back into the command line. The first thing I'm going to do is make sure that I'm in the right context or the right environment in my local environment. I'm going to run 8base environment show and it shows me I am in Dev and that's exactly where I want to be.
The next thing I'm going to do is I'm actually going to generate the migrations that need to then be run to propagate that change to our data model up to its parent environment, which would be staging. We can see if I list out the directory structure that I currently have, it's normal the 8base.yml file, node modules, and some package.json files or the package.json lock file.
However, if I now run the command 8base migration, generate -e for environment and then the name of the environment which is Dev, it's going to go ahead and generate those migration files for me, which now if I list out my directory, I can see that there's a new directory inside there or a new folder in there called migrations. Now I'm just going to go ahead and log out the contents of one of the files in there, which if I go to migrations, we can see that there's a typing file which is generated. Don't worry about it for now. But then a timestamp-schema-create-field-priority.ts file that was generated.
If I cut that out, we can see that that file here has a pretty simple little script in it. It has some imports, has a version number, and then it runs a function which has an object in here which essentially declares all the changes that we did to our data model.
After looking at that, now we know that our migration was successfully generated. We're going to go ahead and actually commit that migration to the new environment. To do that we're going to run 8base migration commit environment name, which is staging, and mode which is only migrations.
Now, you don't have to specify the mode because it will always default to full. However, just so I can mention it, essentially you have two options when doing a migration. Or three options. You can say that you want to migrate everything which is your custom functions and your schema migrations, or one or the other. I only want to migrate my migrations or I only want to migrate my functions.
In this case, we don't have any functions so it wouldn't make a difference. However, know that you have those two options to where maybe you are working on some custom functions that you're not ready to deploy or ready to migrate to the new environment whereas you have some schema that you do need to do, you can differentiate between the two. I'm going to run that now.
This should take about a minute so I'll be right back when it is finished up. Awesome. That ran pretty quickly. Also, too, it's just telling us the migrations which it applied, which was that file that we looked at. Now I'm going to jump back into the 8base console. Here if we now move over to our staging environment, we can see that our new priority field has been added to the staging data model.
Now, this workspace has been updated so we can leverage that new feature or in this case that new field. However, master is still protected and no changes have been propagated up to that, but still a stable branch that has not had those changes propagated up to it yet. However, if we did want to move those changes from staging to master at this point, we would follow the exact same workflow that we just did from development to staging.
Now the last thing to mention here is that this is not something that you have to always do manually by jumping into your command line and going step by step. All these commands can be run in any script that your repository or chosen repository allows you to run, for example, action scripts in GitHub. So if you wanted these types of changes to be made whenever a certain code was committed to a branch in your Git repository, you could absolutely do that and then have these commands execute automatically.
I hope this gave you a good understanding of the power of CI/CD and how to get started with it. If you have any questions, please throw some comments in the video or go to community.8base.com and we will be happy to help you work through anything that comes up along the way. Thank you so much for watching and looking forward to seeing you in future videos.