Separating development and production environments for your sample membership site
Overview
This tutorial explains how to separate the development environment from the production environment. Doing so allows you to verify any updates or modifications before they are published to the production site.
What you'll learn
The following process will be used to separate the development and production environments.
- Custom domain configuration
- GitHub settings
- Modifications to the GitHub Actions build file
- npm script verification
.env
file verification and modification- Activity verification
Before you start
To begin this tutorial, you should have built a site by copying the open-source sample membership site (NuxtAuth-based KurocoFront template site). If you have not done so, see Tutorial: Building a membership website on Kuroco from the sample site template.
For this tutorial, we will create two types of environments:
- Development
- Production
You will be verifying and publishing your code step by step from the development to the production environment.
We will create a branch on GitHub for each environment, and the relevant GitHub Actions will be executed each time the branch is updated. We will also set up a flow that automatically updates the front-end of the corresponding environment.
Custom domain configuration
Refer to Tutorial: Using your own custom domain name on KurocoFront on how to set up your domain.
Also, modify the front-end domain
and API domain
so that they form a subdomain relationship (i.e., matching domains or first-party cookies).
Due to third-party cookie restrictions, the sample membership site may not be able to store cookies using the cookie login method for certain browser/usage environments.
See: Tutorial: Display topic data with Security: Cookie
GitHub settings
For this tutorial, you need to split the GitHub repository into two branches as follows.
Item | Branch |
---|---|
Production environment | main |
Development environment | develop |
For more on branch splitting, refer to GitHub Docs: Managing branches.
We recommend protecting your main branch to prevent releases to unexpected production environments. For more information on this topic, see GitHub Docs: Managing a branch protection rule.
.env
file verification and modification
First let's verify and update the current env file.
The ./env.${environment}.js
files for both development and production environments already exist:
env.development.js
env.production.js
Modify these files for each Kuroco environment you have created. In this tutorial, we are modifying them as follows:
module.exports = {
META_TITLE: 'Nuxt Auth',
ROBOTS: 'index',
BASE_URL: 'https://[Original-domain]'
};
module.exports = {
META_TITLE: '[Dev] Nuxt Auth',
ROBOTS: 'noindex',
BASE_URL: 'https://[Original-domain]'
};
The original API domain should match the one you set up in Custom domain configuration.
These modifications lead to the following dynamic changes:
- Production environment META_TITLE: Nuxt Auth
- Development environment META_TITLE: [Dev] Nuxt Auth
npm script verification
The next step is to verify the npm script, a simple command using Node.js.
In NuxtAuth, the contents are pre-defined in package.json
.
An excerpt from package.json
shows the configuration below.
{
...,
"scripts": {
...
"build": "cross-env NODE_ENV=development nuxt build",
"generate": "cross-env NODE_ENV=development nuxt generate",
"build-prod": "cross-env NODE_ENV=production nuxt build",
"generate-prod": "cross-env NODE_ENV=production nuxt generate",
...
},
...
}
Currently, build
and build-prod
have different values of NODE_ENV=...
:
Command | Value | Purpose |
---|---|---|
build | cross-env NODE_ENV=development nuxt build | build command for developmen |
generate | cross-env NODE_ENV=development nuxt generate | generate command for development |
build-prod | cross-env NODE_ENV=production nuxt build | build command for production |
generate-prod | cross-env NODE_ENV=production nuxt generate | genereta command for production |
This value affects nuxt.config.js
, the configuration file for the build.
It should contain the following code:
const environment = process.env.NODE_ENV; // <- (*1)
const envSettings = require(`./env.${environment}.js`);
export default {
env: envSettings,
...
head: {
htmlAttrs: {
lang: 'en'
},
titleTemplate: '%s - ',
title: envSettings.META_TITLE, // <- (*2)
...
(*1) specifies the value of NODE_ENV=...
, which changes dynamically depending on the npm script.
- For
build
:require('./env.develop.js')
- For
build-prod
:require('./env.production.js')
In (*2), the META_TITLE
values are defined in the respective env.${environment}.js
files.
Modifications to the GitHub Actions build file
Modify the existing /.github/workflow/build.yml
file as needed on the develop
and main
branches, respectively.
Make the following changes:
- Create build definitions for
develop
andmain
- Update build file events
- Set build and deploy locations for each environment
- Create
kuroco_front.json
for the development environment
Create build definitions for develop
and main
Make two build files, one for the production environment and one for the development environment:
- For production:
.github/workflows/build.yml
. - For development:
.github/workflows/develop.yml
.
Since .github/workflows/build.yml
already exists, you can simply copy it. However, .github/workflows/develop.yml
needs to be created from scratch.
Set build and deploy locations for each environment
Modify the build behavior to fit each environment.
In this tutorial, we will modify the following npm scripts:
- For production:
build-prod
andgenerate-prod
- For development:
build
andgenerate
First, in .github/workflows/build.yml
for the production environment, modify run: npm run build
and run: npm run generate
to run: npm run build-prod
and run: npm run generate-prod
.(There are two places each.)
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build-prod
- name: Generate
run: npm run generate-prod
- name: Archive Production Artifact
uses: actions/upload-artifact@v2
with:
Next, modify .github/workflows/develop.yml
for the development environment.
Click [KurocoFront] -> [GitHub] and copy the content in the GitHub Actions workflow file staging site
text area.
Overwrite the .github/workflows/develop.yml
file with the copied contents.
Update build file events
Next, modify each build file such that events are triggered only by updates to the following branches:
- For production:
main
- For development:
develop
Paste the code below into .github/workflows/develop.yml
.
on:
push:
branches:
- develop
workflow_dispatch:
branches: [ develop ]
jobs:
build:
name: Build
Create kuroco_front.json
for the development environment
Copy the kuroco_front.json
file in the /src/static
directory to create kuroco_front_dev.json
.
Also, you need to apply kuroco_front_dev.json
only to develop.yml
. Insert the code below into develop.yml
.
- name: Checkout Repo
uses: actions/checkout@v2
with:
ref: ${{ steps.get_branch.outputs.branch }}
+ - name: Copy kuroco_front.json
+ run: cp src/static/kuroco_front_dev.json src/static/kuroco_front.json
- name: Use Node.js
uses: actions/setup-node@v2
with:
steps:
- name: Checkout Repo
uses: actions/checkout@v2
+ - name: Copy kuroco_front.json
+ run: cp src/static/kuroco_front_dev.json src/static/kuroco_front.json
- name: Use Node.js
uses: actions/setup-node@v2
with:
For more information, see FAQ: What is kuroco_front.json?
.
Activity verification
Confirmation of file configuration
Let us verify the contents we have set so far.
The YAML file and kuroco_front.json are separated for the production environment and the development environment, so the main branch and the development branch both have the following file structure.
.github\workflows
- build.yml
- develop.yml
src
- static
- kuroco_front_dev.json
- kuroco_front.json
Confirmation of build
Once the push for each environment is completed, access the respective repository on GitHub and click on [Actions].
You should see a list of active or completed Actions.
When the build is completed, verify that the META_TITLE of the development environment reads **[Dev] Nuxt Auth**
.
Support
If you have any other questions, please contact us or check out Our Slack Community.