The three types of environments
At Chainstarters we stick with three core environments to deploy code that has been developed, tested, and ready for production. This convention and the separation of environments is vital to ensuring that code contributions from multiple sources fits standards set for quality and are run through the QA process. At every stage of development to production are protected against breaking changes and/or collisions.
Chainstarters sticks to this convention by deploying resources in these three environments:
- Dev (development)
- Test (testing/QA)
- Prod (production)
This improves workflow by allowing teams to first develop features, allowing them to query and mutate the database, add integrations, and develop freely without affecting any part of production. Then, once a new feature is settled upon, it can enter testing/QA, where integration testing, QA of features, and other unit tests can execute safely. If all new features, bug fixes, patches, and other changes pass tests, the code can then be pushed to production and engage end users for feedback and future dev cycles.
Each of these environments has access to the bundle of resources, but with some small configuration differences. Identity management is configurable dependent on team member(s) who can affect change on a particular environment (teams working on the dev environment may not necessarily have the same authority to approve testing changes, or deployment to production). Environment variables are configured based on the environment that they are in (read the next section for a detailed view into environment variables).
These separate environments should be able to share many of the same resources and data, with the exception of where they are deployed to and who would have access to the deployments.
Chainstarters out of the box provides you with an easy to use dashboard for all resources under a particular environment. The only thing you would have to do is click on the environment you want to work in:
When you click on an environment to switch, you will always get an alert to make sure you want to switch:
Understanding that these environments are separated, helps guide a dev team to protect the process of pushing code and testing it.
Set up an environment locally
Before we can bring in the repos with the code that you can start playing with, we need to use SSH to clone the repos. If you want an explainer as to why we use SSH instead of HTTPS, please check out our Gitlab guide.
The first thing needed is to add your local SSH key to Gitlab. To do so, you must first find your SSH key, by running:
cat ~/.ssh/id_rsa.pub on Linux/MacOS, or
type C:\Users\USERNAME\.ssh\id_rsa.pub on Windows.
Once you run the command, copy the key and then paste it in Gitlab as instructed below.
If you do not have an SSH key, you can generate one by following this guide. After generating the SSH Key, you can take the steps as mentioned earlier to copy the key.
In Gitlab, navigate to the user icon in the upper right corner on your avatar and select settings. From there, choose SSH keys (found on the left hand side).
There you will find an input area where you can paste the SSH key you copied from the terminal. You can then name it (based on which machine you are using would work best, but name it however you like), and once you have the key pasted in and named, click Add key.
You have now added the key! You should be ready to clone the repo using SSH!
Cloning The Repo
Now it's time to clone the repo so you can develop and push code on your local machine. First, let's look at our projects. Click on projects in the upper nav of the Chainstarters Gitlab interface.
From this modal click on Your Projects, and you will see your project repos that you created!
Now let's click on the repo with
graphql at the end of the name. When you do, you will see the repo page and be able to clone the repo to your local machine.
Click on "Clone"
Once you do, you will see a few options. We want to use SSH. Click on the clipboard icon next to the SSH url.
While it may be tempting to click on open in your IDE, (if you are using Visual Studio Code) don't. We want to use SSH, and using this built in option would go through an https link, and we don't want that.
Now that we have the SSH url in our clipboard, let's go into our terminal and finish the setup.
In your terminal of choice (unix/linux) make a folder in whatever directory you use for your projects
mkdir yourProjectName or
After making the directory, go to it to receive the cloned project
Now, type out
git clone and then paste in the url, it should look like this:
git clone email@example.com:chainstarters-cloud/testtest123/timber_social/timber-social-graphql.git
If this looks right, then press return and it should only take a few seconds to receive the code.
Confirm that you have the code by going to the directory, you can also verify contents of your folder with the
It should appear in the folder under the repo name, with the project example here, it would be this:
From here you can start up with your chosen code editor or IDE. We recommend Visual Studio Code, as it is the most robust and feature rich editor going with easy to implement git management and plenty of packages to aid with linting, code tooltip completion, etc.
Migrating data through the environments
While we have separate environments for code in different stages of the production pipeline, we want to be able to persist data across these environments, so that regardless of the app controllers and views we have the same database.
Let's start by going to the Chainstarters Dashboard Project View, and under Data & Schemas click on Database, you should now see the database screen:
The dropdown on the upper left side of the interface are your tables. Next to that is the Database in your current environment, in this case the
dev environment, and next to that is Past Migrations.
To do a migrate, let's go to the Test environment, click Test above the database interface
You should now see a Migration Tool tab next to Database on the interface
Click on Migration Tool tab
This will start at an up Migration (from
For this exercise, let's select all of the fields for migration, which will
CREATE TABLE, then alter the sequence and table to complete the migration.
Now we will see the fields for down migration
Let's select only
SET search_path = your_database_name, pg_catalog
Now we get to compare the migrations