Automating Frontend Build and Deployment with GitLab CI/CD

After establishing an internal GitLab platform, the frontend activity project moved from SVN to GitLab and adopted GitLab CI/CD for automated build and release. The article first outlines the benefits of using GitLab CI/CD, then compares the manual pre‑CI/CD workflow with the streamlined post‑CI/CD process.

Team benefits include reducing release time from an average of 5 minutes to 1.5 minutes and eliminating inconsistencies caused by local builds versus the packaged code deployed online.

The pre‑CI/CD workflow required at least eight manual steps: local build, committing built HTML, opening the release system, selecting project and environment, opening the release page, choosing files, filling release information, and confirming the release.

With GitLab CI/CD, releasing becomes a single step—merging the development branch into the release branch triggers an automatic pipeline that builds and publishes the project.

What is GitLab CI/CD? When code is pushed to GitLab, a pipeline defined in .gitlab-ci.yml is triggered. The pipeline can contain stages such as dependency download, build, test, and deployment, executed by a GitLab Runner (Docker, VM, or shell).

The article then walks through creating a new GitLab project, configuring a shared Runner, and adding a .gitlab-ci.yml file. An example snippet is shown below:

image: node
stages:
  - build
  - test
build:
  stage: build
  script:
    - echo "build stage"
  only:
    changes:
      - webpack@next/package.json
    refs:
      - test
      - master
test:
  stage: test
  script:
    - echo "test stage"

The detailed .gitlab-ci.yml used in the activity project defines three stages (pre_build, build, deploy), variables for paths, before_script steps to prepare the environment, and scripts that run yarn install , invoke Python build scripts, and use an internal dplt tool to deploy HTML via rsync.

Runner configuration notes include handling pending jobs caused by missing tags, choosing between Shared, Group, or Specific Runners, and using Docker executors for building images.

Practical issues encountered are listed, such as pipelines stuck in pending state, Docker usage for image building, and accessing host directories from the Runner.

Finally, the article identifies current problems—lack of automated testing, environment inconsistencies, and the need for branch naming and code‑review standards—and points to future directions and reference materials on CI/CD and GitLab.