Required Environment⌗

Gitlab (you can refer to the previous article “DevOps: Quickly Setting Up Gitlab Service”)
Server running Gitlab Runner (you can refer to the previous article “DevOps: Registering Gitlab Runner”)
Server for deploying Vue projects (can be the same server running Gitlab Runner; if not, you need to add the public key of the server running Gitlab Runner to the server used for deploying Vue)
Gitlab Runner running in Docker mode

Writing CI Configuration File⌗

Cache and Artifacts⌗

Many people are not very clear about the functions of Cache and Artifacts. The official documentation provides some explanation. Cache is suitable for dependency files shared across multiple stages, such as NPM packages that Vue projects depend on, i.e., the node_modules directory. Artifacts, on the other hand, are data generated during building or testing, which often should not be overwritten and may even need to be uploaded to the Gitlab server.

Stages in the Pipeline⌗

Due to the nature of Vue SPA, it doesn’t depend on other services. We only need to install some dependencies, then package, and finally deploy to preview and production environments. Based on these requirements, we set the entire Pipeline to two Stages, as follows:

stages:
  - build   # Install dependencies and build the project
  - deploy  # Deploy to preview and production environments

Tasks for Each Stage⌗

Build Stage Tasks⌗

build:
  image: node:latest # Specify image
  stage: build # Specify the stage
  tags:
    - sonitus # Specify which Runner to run the task on
  only: # Define branches to monitor; when branches change, CI is triggered
    refs:
      - master
      - develop
      - tags
  script: # Scripts to execute
    - yarn install
    - yarn build
  artifacts: # Define files or directories to upload
    name: "$CI_COMMIT_REF_SLUG"
    when: on_success # Define to upload only when the task succeeds
    expire_in: 1 week # Define file expiration time, after which it will be automatically deleted
    paths: # Define files or directories to package and upload
      - dist/

Deploy Stage Tasks⌗

Since we have preview and production environments, we have two tasks in the deployment stage. The preview environment has the same trigger conditions as the build stage, meaning changes to master, develop, and tags all deploy to the preview server. The production environment deployment only monitors changes to tags and requires developers or operations personnel to manually trigger the deployment task on the Gitlab project page.

deploy:preview:
  image: alpine:latest # Specify image
  stage: deploy
  tags:
    - sonitus
  when: on_success
  script:
    - apk add --no-cache rsync openssh # Install rsync and openssh
    - mkdir -p ~/.ssh
    - echo "$PREVIEW_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # Output the private key environment variable set in Gitlab to ～/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - rsync -rav -e "ssh -p $PREVIEW_SERVER_PORT -o StrictHostKeyChecking=no" --delete dist/ "$PREVIEW_SERVER_USER"@"$PREVIEW_SERVER":"$PREVIEW_PROJECT_PATH" # Deploy the built dist to the server
  only:
    refs:
      - master
      - develop
      - tags
  dependencies: # Define dependencies, can only be executed after the build task is completed
    - build
  environment: # Define environment
    name: preview
    url: https://vue.betterde.com # Define access URL

deploy:production:
  image: alpine:latest
  stage: deploy
  tags:
    - sonitus
  script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$PRODUCTION_SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - rsync -rav -e "ssh -p $PRODUCTION_SERVER_PORT -o StrictHostKeyChecking=no" --delete dist/ "$PRODUCTION_SERVER_USER"@"$PRODUCTION_SERVER":"$PRODUCTION_PROJECT_PATH"
  when: manual # Define as manually triggered
  only:
    refs:
      - tags # Only show this Job when a tag is created
  dependencies:
    - build
  environment:
    name: production
    url: https://vue.betterde.com

It’s worth noting that the deployment stage involves many environment variables (the names of these environment variables can be defined by yourself), which need to be set in Gitlab. The access path is: Project > Settings > CI/CD > Variables.

Project > Settings > CI/CD > Variables

Also, you need to check if the project has available Runners. Similarly, go to: Project > Settings > CI/CD > Runners to check if the Runner with the specified tag is available.

Project > Settings > CI/CD > Runners

Complete CI Configuration File⌗

stages:
  - build
  - deploy

variables:
  GIT_STRATEGY: fetch

cache:
  paths:
    - node_modules/

build:
  image: node:latest
  stage: build
  tags:
    - sonitus
  only:
    refs:
      - master
      - develop
      - tags
  script:
    - yarn install
    - yarn build
  artifacts:
    name: "$CI_COMMIT_REF_SLUG"
    when: on_success
    expire_in: 1 week
    paths:
      - dist/

deploy:preview:
  image: alpine:latest
  stage: deploy
  tags:
    - sonitus
  when: on_success
  script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$PREVIEW_SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - rsync -rav -e "ssh -p $PREVIEW_SERVER_PORT -o StrictHostKeyChecking=no" --delete dist/ "$PREVIEW_SERVER_USER"@"$PREVIEW_SERVER":"$PREVIEW_PROJECT_PATH"
  only:
    refs:
      - master
      - develop
      - tags
  dependencies:
    - build
  environment:
    name: preview
    url: https://vue.betterde.com

deploy:production:
  image: alpine:latest
  stage: deploy
  tags:
    - sonitus
  script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$PRODUCTION_SSH_PRIVATE_KEY" >> ~/.ssh/id_dsa
    - chmod 600 ~/.ssh/id_dsa
    - rsync -rav -e "ssh -p $PRODUCTION_SERVER_PORT -o StrictHostKeyChecking=no" --delete dist/ "$PRODUCTION_SERVER_USER"@"$PRODUCTION_SERVER":"$PRODUCTION_PROJECT_PATH"
  when: manual
  only:
    refs:
      - tags
  dependencies:
    - build
  environment:
    name: production
    url: https://vue.betterde.com

Summary⌗

Next, we can test the entire CI process. When we push, merge, or tag a release, CI will be triggered as configured above. If you only operate on the master and develop branches, you will see two stages and two jobs in the Pipelines backend:

Jobs in Pipelines when PUSH to master branch

After we tagged the project as v1.0.1 and released it, the Jobs in the Pipeline are as follows:

Jobs after tagging

You can see that the deploy:production Job appears but is not triggered. At this point, we need to manually click the Run button to trigger this Job, thereby deploying to the production environment. Before manually triggering, you can click on this Job (not the button behind it) to enter the Job details page, set temporary environment variables, and then click the Trigger this manual action button below to trigger.

At this point, the entire project of Gitlab CI building and deploying Vue is complete. I hope everyone can also use Gitlab CI to replace manual work, thereby freeing up more time to do more valuable things.

I hope this is helpful, Happy hacking…

DevOps - Using Gitlab CI to Build and Deploy Vue Projects