Master Frontend Automation: Deploy with GitLab CI from Scratch

This comprehensive guide walks frontend developers through the concepts, benefits, and step‑by‑step implementation of automated deployment using GitLab CI, covering pipeline mechanics, runner configuration, YAML syntax, practical .gitlab-ci.yml examples, common pitfalls, and advanced features to streamline continuous integration and delivery.

GF Securities FinTech
GF Securities FinTech
GF Securities FinTech
Master Frontend Automation: Deploy with GitLab CI from Scratch

Introduction

Automated deployment and continuous integration have become indispensable for frontend development teams. This article explains how to achieve frontend automation using GitLab CI.

1. Concept Overview

GitLab CI runs pipelines defined in a .gitlab-ci.yml file. When a push or merge occurs, GitLab scans the file and executes stages such as install, eslint, build, and deploy. The pipeline is visualized in the GitLab UI, and each job can be triggered manually.

The process is isolated per push, allowing parallel pipelines without interference.

GitLab Runner is a command‑line tool that binds a machine (or Docker container) to the CI process via a token.

1.2 Benefits of Automated Deployment

Higher development efficiency – developers no longer need to manually deploy after fixing bugs.

Improved code quality – linting and tests run automatically on each push.

2. Knowledge Preparation

Key abstract concepts in GitLab CI:

Pipeline & Job – a pipeline consists of multiple jobs, each assigned a stage.

Runner – executes jobs on a specific machine. Two types:

Shared Runner (provided by GitLab, limited minutes for private projects).

Specific Runner (self‑hosted, fully configurable).

Executor – the environment in which a runner runs (Shell, Docker, Kubernetes, etc.).

YAML is the configuration language used for .gitlab-ci.yml. It relies on indentation, supports comments with #, and can represent objects and arrays similarly to JSON.

install-job: # comment
  tags:
    - sss
  stage: install
  script:
    - npm install

3. Practical Implementation

Step 1: Install GitLab Runner (macOS example)

sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner

Step 2: Initialize the runner

cd ~
gitlab-runner install
gitlab-runner start

Step 3: Register the runner sudo gitlab-runner register Provide the token, URL, and tags (e.g., sss) as prompted.

Define Pipeline Stages

Typical frontend pipeline stages:

install – npm install eslint – linting, fail pipeline on errors

build – compile with Webpack or react-scripts build deploy – copy build output to a server (e.g., via scp with sshpass).

Example .gitlab-ci.yml:

stages:
  - install
  - eslint
  - build
  - deploy

cache:
  paths:
    - node_modules
    - build

install-job:
  tags:
    - sss
  stage: install
  script:
    - npm install

eslint-job:
  tags:
    - sss
  stage: eslint
  script:
    - npm run eslint

build-job:
  tags:
    - sss
  stage: build
  script:
    - npm run build

deploy-job:
  tags:
    - sss
  stage: deploy
  script:
    - sshpass -p $PASSWORD scp -r ./build $CUSTOM_USERNAME@$CUSTOM_IP:/var/www/html

Relevant package.json scripts:

{
  "scripts": {
    "start": "react-scripts start",
    "build": "npx react-scripts build",
    "eslint": "eslint ./src"
  }
}

4. Common Pitfalls

Runner not activated – run sudo gitlab-runner verify and sudo gitlab-runner restart.

Jobs hanging – ensure the runner is active and tags match.

Shared Runner stealing jobs – disable shared runners in project settings if you prefer specific runners.

5. Advanced Topics

5.1 YAML Reuse and Modularity

Define reusable snippets with anchors ( &) and merge them with <<: *anchor. Use include to import external YAML files.

.common-config: &commonConfig
  only:
    refs:
      - develop
      - release

install-job:
  <<: *commonConfig
  script:
    - npm install

5.2 Additional Keywords

cache – reuse dependencies between jobs.

artifacts – upload build output as downloadable assets.

image / services – run jobs in Docker containers.

only / except – limit jobs to specific branches or tags.

allow_failure – let a job fail without stopping the pipeline.

retry – set automatic retry attempts (0‑2).

timeout – define maximum job duration.

when – control execution based on previous job results ( on_success, on_failure, always).

Conclusion

By mastering GitLab CI concepts, YAML configuration, runner management, and advanced features, frontend teams can achieve reliable, automated deployment pipelines that boost efficiency and code quality.

deploymentcontinuous integrationGitLab CIYAMLfrontend automationGitLab Runner
GF Securities FinTech
Written by

GF Securities FinTech

Dedicated to sharing the hottest FinTech practices

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.