GitLab CI/CD là gì? Pipeline tự động hóa build, test và deploy

GitLab CI/CD là hệ thống tự động hóa pipeline được tích hợp sẵn trong nền tảng GitLab — không cần cài thêm công cụ bên ngoài, chỉ cần một file .gitlab-ci.yml trong repository là toàn bộ quy trình build, test và deploy được kích hoạt tự động mỗi khi có commit mới.

GitLab CI/CD là gì?

GitLab CI/CD là nền tảng Continuous Integration / Continuous Delivery được xây dựng trực tiếp vào GitLab, hoạt động hoàn toàn tự động dựa trên file cấu hình .gitlab-ci.yml đặt tại thư mục gốc của repository. Mỗi khi developer push code hoặc tạo merge request, GitLab tự động đọc file này, tạo ra một pipeline gồm nhiều stage chạy tuần tự, mỗi stage chứa một hoặc nhiều job thực thi song song.

Pipeline là chuỗi bước tự động hóa theo mô hình: test → build → deploy. Nếu bất kỳ job nào thất bại, pipeline dừng ngay và thông báo về developer — nguyên tắc "fail fast" giúp phát hiện lỗi sớm nhất có thể, trước khi code lỗi được đưa lên môi trường production.

Điểm khác biệt lớn của GitLab so với các công cụ CI/CD rời rạc (như Jenkins): GitLab tích hợp sẵn Container Registry, Package Registry, Security Scanning (SAST, DAST), Environments và Deployment tracking trong cùng một nền tảng — giảm đáng kể số lượng công cụ bạn cần quản lý.

CI/CD là gì? Tổng quan về tích hợp và triển khai liên tục

Cấu trúc .gitlab-ci.yml

Toàn bộ pipeline được định nghĩa trong một file YAML duy nhất. Dưới đây là ví dụ thực tế cho ứng dụng Python triển khai lên Kubernetes:

 1stages:
 2  - test
 3  - build
 4  - deploy
 5
 6variables:
 7  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
 8
 9# ── Stage 1: Test ─────────────────────────────────────────────
10test:
11  stage: test
12  image: python:3.11
13  script:
14    - pip install -r requirements.txt
15    - pytest tests/ -v
16  cache:
17    key: ${CI_COMMIT_REF_SLUG}
18    paths:
19      - .cache/pip
20
21# ── Stage 2: Build Docker image và push lên GitLab Registry ───
22build:
23  stage: build
24  image: docker:24
25  services:
26    - docker:dind
27  script:
28    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
29    - docker build -t $DOCKER_IMAGE .
30    - docker push $DOCKER_IMAGE
31  only:
32    - main
33
34# ── Stage 3: Deploy lên Kubernetes (manual gate) ──────────────
35deploy:
36  stage: deploy
37  script:
38    - kubectl set image deployment/myapp app=$DOCKER_IMAGE
39  environment:
40    name: production
41  when: manual
42  only:
43    - main

Giải thích các khái niệm chính:

• stages — khai báo thứ tự các giai đoạn. Job thuộc cùng stage chạy song song; stage sau chỉ bắt đầu khi stage trước hoàn thành thành công.
• variables — biến môi trường dùng trong toàn pipeline. GitLab cũng cung cấp sẵn các predefined variables như $CI_COMMIT_SHA, $CI_REGISTRY_IMAGE, $CI_COMMIT_REF_SLUG.
• image — Docker image dùng làm môi trường thực thi job. Mỗi job có thể dùng image khác nhau.
• services — container phụ trợ chạy cùng job (ví dụ: docker:dind cho phép build Docker image bên trong container).
• cache — thư mục được lưu lại giữa các lần chạy pipeline để tăng tốc (.cache/pip, node_modules/).
• artifacts — file output của job được truyền sang job tiếp theo hoặc download sau pipeline.
• only / rules — điều kiện chạy job (chỉ chạy trên nhánh main, chỉ khi có tag...).
• when: manual — job không tự động chạy, cần người có quyền bấm nút xác nhận — phù hợp cho bước deploy production.
• environment — liên kết job với một môi trường trong GitLab Environments, cho phép tracking deployment history và rollback.

GitLab Runner

GitLab Runner là agent phần mềm cài trên máy chủ (hoặc chạy trong container/Kubernetes pod), có nhiệm vụ nhận job từ GitLab server và thực thi chúng. Runner liên tục polling GitLab server, nhận job được assign, tải source code về, thực thi script trong executor đã cấu hình, rồi gửi log và exit code về GitLab.

Shared Runner vs Specific Runner

Docker Executor — lựa chọn phổ biến nhất

Docker executor chạy mỗi job trong một Docker container mới, đảm bảo môi trường hoàn toàn cô lập và sạch sẽ sau mỗi lần chạy. Đây là executor được khuyến nghị cho hầu hết các trường hợp.

Đăng ký một specific runner với Docker executor:

 1# Cài GitLab Runner trên Ubuntu/Debian
 2curl -L --output /usr/local/bin/gitlab-runner \
 3  "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"
 4chmod +x /usr/local/bin/gitlab-runner
 5
 6# Đăng ký runner (lấy token trong Settings → CI/CD → Runners)
 7gitlab-runner register \
 8  --url "https://gitlab.com/" \
 9  --registration-token "YOUR_REGISTRATION_TOKEN" \
10  --executor "docker" \
11  --docker-image "alpine:latest" \
12  --description "my-docker-runner" \
13  --tag-list "docker,production"

Sau khi đăng ký, runner xuất hiện trong Settings → CI/CD → Runners của project và sẵn sàng nhận job. Bạn có thể dùng tag để chỉ định job nào chạy trên runner nào — ví dụ job deploy production chỉ chạy trên runner tagged production đặt trong network nội bộ.

Kubernetes là gì? Điều phối container ở quy mô lớn

GitLab vs GitHub Actions vs Jenkins

Khi nào chọn GitLab CI/CD?

• Dự án cần tự host toàn bộ stack (code + CI/CD + registry) trong môi trường on-premise.
• Team cần tích hợp security scanning, compliance và audit trail trong cùng nền tảng.
• Fintech, ngân hàng, healthcare cần kiểm soát dữ liệu 100% trên server nội bộ.

Khi nào chọn GitHub Actions?

• Repository đang trên GitHub và muốn pipeline zero-config.
• Open-source project cần nhiều phút CI miễn phí.
• Cần kết hợp với hệ sinh thái GitHub (Dependabot, CodeQL, GitHub Packages).

Khi nào chọn Jenkins?

• Legacy enterprise đã đầu tư nhiều vào Jenkins plugin và Groovy pipeline.
• Cần tích hợp với nhiều SCM khác nhau (Bitbucket Server, Perforce, SVN).

Best Practices

1. Cache dependencies để tăng tốc build

 1# Python — cache pip packages
 2cache:
 3  key: ${CI_COMMIT_REF_SLUG}-pip
 4  paths:
 5    - .cache/pip
 6  policy: pull-push
 7
 8# Node.js — cache node_modules
 9cache:
10  key:
11    files:
12      - package-lock.json
13  paths:
14    - node_modules/

Dùng policy: pull cho các job chỉ đọc cache (không cần ghi lại) để tránh upload không cần thiết sau mỗi job.

2. Song song hóa với needs: (DAG pipeline)

 1test-unit:
 2  stage: test
 3  script: pytest tests/unit/
 4
 5test-integration:
 6  stage: test
 7  script: pytest tests/integration/
 8
 9build:
10  stage: build
11  needs: [test-unit]  # Không cần chờ test-integration xong
12  script: docker build .

needs: phá vỡ mô hình stage tuần tự truyền thống, cho phép job build bắt đầu ngay khi test-unit xong mà không cần chờ test-integration — giảm tổng thời gian pipeline đáng kể.

3. Bảo vệ môi trường production

Trong Settings → CI/CD → Environments → production, cấu hình:

• Required approvals: deploy production cần ít nhất 1-2 người approve.
• Protected branches: chỉ nhánh main hoặc release/* mới trigger deploy production.
• Deployment freeze: block deploy trong giờ cao điểm hoặc dịp lễ Tết.

4. SAST scanning tích hợp sẵn

1include:
2  - template: Security/SAST.gitlab-ci.yml
3
4sast:
5  stage: test
6  variables:
7    SAST_EXCLUDED_PATHS: "tests/, docs/"

GitLab SAST tự động chọn analyzer phù hợp với ngôn ngữ của project (Bandit cho Python, Semgrep cho JS/TS, SpotBugs cho Java...) mà không cần cấu hình thêm.

5. Manual gate cho production deploy

Luôn dùng when: manual cho job deploy production kết hợp với environment: production. Điều này tạo ra một nút bấm xác nhận rõ ràng trong GitLab UI, có audit trail ghi lại ai đã bấm deploy lúc nào.

Microservices là gì? Kiến trúc phân tán và ứng dụng thực tế

Use Cases thực tế

Startup — bắt đầu nhanh, không cần ops team

Startup có thể dùng GitLab.com miễn phí (400 phút/tháng) với pipeline 3 stage cơ bản: test → build Docker → deploy lên VPS bằng SSH. Toàn bộ cấu hình nằm trong một file .gitlab-ci.yml, không cần DevOps chuyên trách từ ngày đầu. Khi scale lên, tự nhiên nâng cấp lên Kubernetes deploy mà không thay đổi cơ bản cấu trúc pipeline.

Ngân hàng & Fintech Việt Nam — self-hosted cho compliance

Các tổ chức tài chính tại Việt Nam (tuân thủ Thông tư 09/2020/TT-NHNN về an toàn thông tin) thường deploy GitLab CE self-managed trên hạ tầng nội bộ:

• Không giới hạn CI minutes — pipeline chạy thoải mái trên server nội bộ.
• Dữ liệu không rời khỏi datacenter — source code, artifact và log đều trên server nội bộ.
• Audit trail đầy đủ — GitLab EE (hoặc CE với plugin) log toàn bộ: ai commit, ai approve MR, ai bấm deploy, lúc nào.
• Tích hợp SAST/Secret Detection — phát hiện credential bị commit lên repository ngay trong pipeline.

Pipeline điển hình cho core banking system: sast → unit-test → integration-test → build-image → push-to-internal-registry → deploy-staging (auto) → deploy-production (manual, requires 2 approvals).

Kết luận: GitLab CI/CD là lựa chọn mạnh mẽ khi bạn cần một nền tảng all-in-one — từ source code management đến CI/CD, container registry và security scanning — đặc biệt cho dự án self-hosted đòi hỏi kiểm soát dữ liệu nghiêm ngặt. Bắt đầu với một file .gitlab-ci.yml đơn giản, dần bổ sung cache, parallel jobs và manual gates khi team trưởng thành.

Câu hỏi thường gặp