Skip to main content

Deploy application

This page describes the work steps required on the back-end side when the front-end application is deployed.

Registration work

  1. Prepare a Github account for Deploy
  2. Tell Hexabase your Deploy information
  3. (Add Github account to Hexabase repository)
  4. Create a sub-repository for Front-end applications
  5. Inform Hexabase of the sub-repository and delivery URL
  6. (Hexabase registers sub repository and delivery URL in DNS)

Template of Deploy information

- application_name: test
- repository_URL: ?
- framework: nuxtjs/nextjs/sveltekit
- server port: 3000
- (sub)domain_name: test.hexabase.com
- api_servers:
- deployments
- test:
- staging: e.g: https://api.hexabase.com
- production:
- environment_variable:
- buildtime: required?
- yes: .env_stg/env_prod please prepare
- runtime: required?
- yes: .env_stg/env_prod please prepare -> infra will register to k8s
- circleCI (CI):
- deploy_branch:
- staging:
- production:
- approval: required?
- notifications: required?
- channel_to_notify:
- deadline
- date:
- others:
- pre-build-check:
- frameworks:
- nuxt:
- local:
- build: `nuxt build` or `nuxt export` command has no error?
- IP whitelist:
- environment: stg/prod
- address:
- reference project:

Deploy to Production Environment:

  1. Developer commit/merge working branch to master (partner only)
  2. CircleCI catches the changes
  3. CircleCI build the container and push to container registry (next within this month, push container to dockerhub)
  4. dockerhub performs vulnerability scanning to the container and detect threats (to support within this month)
  5. CircleCI deploy to linker-prod

Base Pipeline (Hexabase internal work)

  1. Kubernetes settings preparation and installation
  2. Project and Repo installation to CircleCI
  3. CircleCI configuration file settings
  4. CircleCI automated notifications of build+deploy to necessary channels (partner and internal slack channels)
  5. CircleCI apply automated rolling update to selected cluster

Caution or operation risks!!

  1. Any member of partners can commit/merge to deploy or master branches
  2. Hexabase will deploy to staging and production cluster anytime 24/7
  3. Hexabase has no control to any partner used libraries and their source codes.
  4. Hexabase has no control to any resources (cpu/ram/disk. being used from any partner application/server. (if cpu/ram/disk/network is High, server crash is imminent including other partner staging/production applications)
  5. Hexabase does not detect any vulnerable source code or libraries from partner
  6. Hexabase has limited management to source code deployed.. old or new code, success or fail, hard to watch all.

Refer: Deploy to Staging Environment:

  1. Developer commit/merge working branch to deploy (partner only)
  2. CircleCI catches the changes
  3. CircleCI build the container and push to container registry (next within this month, push container to dockerhub)
  4. dockerhub performs vulnerability scanning to the container and detect threats (to support within this month)
  5. DDircleCI deploy to linker-stg

Note

Do not use process.env when developing front-end applications. It can be a problem when deploying your application. If you want to switch the execution environment of the front-end application, use something other than process.env. For example, for Nuxt.js you can use nuxt.config.js.