Reading Time: 8 minutes

GitLab là một nền tảng DevOps toàn diện, cung cấp nhiều công cụ hỗ trợ quá trình phát triển phần mềm. Một trong những tính năng nổi bật của GitLab là hệ thống CI/CD (Tích hợp liên tục/Triển khai liên tục) mạnh mẽ, giúp tự động hóa quá trình kiểm thử và triển khai ứng dụng. Bài hướng dẫn này sẽ giúp bạn hiểu rõ cách thiết lập và tận dụng tối đa sức mạnh của GitLab CI/CD, từ đó nâng cao hiệu suất làm việc và chất lượng sản phẩm.

CI/CD là gì?

Trong những năm gần đây, quy trình tích hợp và triển khai phần mềm đã có những bước tiến đáng kể. Một xu hướng nổi bật là việc áp dụng quy trình sau:

• Tạo image cho app
• Chạy bộ kiểm thử trên image vừa tạo
• Đẩy image này lên registry (kho lưu trữ Docker image)
• Deploy lên hệ thống

Với các dự án lớn với nhiều dev và số lượng commit hàng ngày lên đến hàng chục hoặc hàng trăm, việc tự động hóa các công đoạn này sẽ giúp tiết kiệm đáng kể thời gian và công sức. Điều này đảm bảo code luôn được kiểm tra kỹ lưỡng và các tính năng mới có thể được đưa vào sử dụng nhanh chóng.

Bằng cách tận dụng các công cụ CI/CD có sẵn trên các nền tảng như GitLab, toàn bộ quy trình này sẽ được tự động hóa.

CI/CD là sự kết hợp giữa tích hợp liên tục (Continuous Integration) và triển khai liên tục (Continuous Delivery/Deployment). Giải pháp này tự động hóa phần lớn các bước trong quá trình phát triển phần mềm, từ việc viết mã nguồn cho đến khi đưa vào môi trường production.

Cụ thể, GitLab CI/CD trong trường hợp này bao gồm:

• GitLab CI: Quá trình tự động xây dựng và kiểm thử code trước khi tích hợp vào repository chung. GitLab Continuous Integration có thể được áp dụng cho mọi commit đưa lên repository.
• GitLab CD: Quá trình diễn ra sau CI, bao gồm việc triển khai code lên các môi trường thực tế như staging hoặc production.

Toàn bộ quá trình từ khi code được đưa vào CI/CD cho đến khi kết thúc được gọi là một pipeline. Trong pipeline này có nhiều job, mỗi job thực hiện một nhiệm vụ cụ thể. Sau khi commit code, các bước kiểm thử, xây dựng image, đẩy image và triển khai đều được thực hiện tự động mà không cần sự can thiệp thủ công.

Với CI/CD, các nhóm dev có thể liên tục cập nhật code cho project một cách thuận tiện. Những thay đổi code sẽ được tự động kiểm tra và triển khai liên tục. Khi áp dụng CI/CD hiệu quả, các đội có thể giảm thiểu thời gian chết của hệ thống và tăng tốc độ phát hành phiên bản mới.

Tìm hiểu phương pháp bảo mật CI/CD tối ưu hóa quy trình devops.

Triển khai CI/CD trên Gitlab

Tạo runner

GitLab runner là một agent có nhiệm vụ nhận các job CI, thực thi chúng theo cấu hình trong file pipeline, và gửi kết quả trở lại cho GitLab.

Để xem các runner khả dụng, vào Settings > CI/CD và xem phần Runners. Nếu chưa có runner, trước tiên hãy cài đặt GitLab Runner trên máy bạn, sau đó đăng ký runner cho project của bạn.

Khi đăng ký một runner, bạn đang thiết lập một kết nối giữa máy chủ GitLab và máy tính đã cài đặt runner đó.

Tạo file .gitlab-ci.yml

File này nằm ở ở thư mục gốc của project. Chúng ta dùng nó để định nghĩa các stage, job và script sẽ được thực thi trong một pipeline CI/CD. Bản chất nó là một dạng file YAML với một cú pháp riêng.

Bạn có thể đặt tên file này tùy ý, nhưng .gitlab-ci.yml là tên phổ biến nhất. Trong file này, bạn cần định nghĩa:

• Cấu trúc và thứ tự các job mà runner sẽ thực thi.
• Các quyết định mà runner cần đưa ra khi gặp các điều kiện cụ thể.

Để tạo file .gitlab-ci.yml trong project của bạn:

1. Ở thanh bên trái, chọn Search hoặc truy cập vào project của bạn.
2. Chọn Code > Repository.
3. Phía trên danh sách file, chọn branch bạn muốn commit. Nếu không chắc chắn, hãy để nguyên master hoặc main. Sau đó chọn biểu tượng dấu cộng và New file.

1. Đặt tên file là .gitlab-ci.yml, sa đó điền nội dung file vào.

Tạo pipeline

Pipeline là những gì bạn định nghĩa trong file .gitlab-ci.yml. Khi một runner chạy, nó sẽ đọc và thực thi nội dung file này.

Pipeline bao gồm các job và stage:

• Stage xác định thứ tự thực hiện. Các stage điển hình có thể là build, test và deploy.
• Job chỉ định các tác vụ cần thực hiện trong mỗi stage. Ví dụ, một job có thể biên dịch hoặc kiểm tra mã.

Pipeline có thể được kích hoạt bởi nhiều sự kiện khác nhau, như commit hoặc merge, hoặc theo lịch trình nào đó. Nhiều job trong cùng một stage có thể chạy song song nếu có đủ runner.

Nếu tất cả job trong một stage thành công, pipeline sẽ chuyển sang stage tiếp theo. Nếu bất kỳ job nào trong stage thất bại, stage tiếp theo thường sẽ không chạy và pipeline sẽ kết thúc sớm ngay lúc đó.

Nhìn chung trong phần lớn trường hợp, pipeline sẽ chạy hoàn toàn tự động và bạn sẽ không cần can thiệp thủ công.

Một pipeline điển hình có thể gồm bốn stage, được thực hiện theo thứ tự sau:

1. Stage build, với một job tên là compile.
2. Stage test, với hai job tên là test1 và test2.
3. Stage staging, với một job tên là deploy-to-stage.
4. Stage production, với một job tên là deploy-to-prod.

Sau đây là một ví dụ:

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
  environment: production

Ví dụ này minh họa bốn job: build-job, test-job1, test-job2 và deploy-prod. Các comment trong lệnh echo sẽ hiển thị trên giao diện khi bạn xem các job. Giá trị của các biến có sẵn $GITLAB_USER_LOGIN và $CI_COMMIT_BRANCH sẽ được điền khi các job chạy.

Nội dung liên quan: GitOps là gì? Nên lựa chọn GitOps hay DevOps?

Dùng biến khi định nghĩa pipeline

Biến trong CI/CD là các cặp khóa-giá trị dùng để lưu trữ các cài đặt cấu hình và thông tin nhạy cảm như mật khẩu hoặc khóa API vào các job trong pipeline.

Bạn có thể sử dụng biến CI/CD để tùy chỉnh job bằng cách giá trị được định nghĩa ở nơi khác vào job. Có nhiều cách để thiết lập biến CI/CD:

• Khai báo trực tiếp trong file .gitlab-ci.yml
• Cài đặt trong phần cài đặt project
• Tạo động trong quá trình chạy

Biến có thể được định nghĩa ở cấp độ project, group hoặc instance.

Có hai loại biến chính:

1. Biến tùy chỉnh (custom) do người dùng tự định nghĩa. Bạn có thể tạo và quản lý chúng qua giao diện GitLab, API hoặc trong file cấu hình.
2. Biến được định nghĩa sẵn (predefined): được GitLab tự động thiết lập để cung cấp thông tin về job, pipeline và môi trường hiện tại.

Để tạo biến CI/CD trong file .gitlab-ci.yml, bạn cần định nghĩa biến và giá trị của nó bằng từ khóa variables. Các biến này sẽ được hiển thị với tất cả người dùng có quyền truy cập vào repository. Vì vậy, chỉ nên lưu trữ các thông tin không nhạy cảm ở đây.

Ví dụ:

variables:
GLOBAL_VAR: "A global variable"
job1:
variables:
JOB_VAR: "A job variable"
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"
job2:
script:
- echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

Trong ví dụ này, chúng ta đã định nghĩa 2 biến GLOBAL_VAR và JOB_VAR:

• job1 sẽ in ra: Variables are ‘A global variable’ and ‘A job variable’
• job2 sẽ in ra: Variables are ‘A global variable’ and ”

Xem pipeline

Để xem tất cả các pipeline của một project:

1. Ở thanh bên trái, chọn Search hoặc tìm project của bạn.
2. Chọn Build > Pipelines.

 Ở góc trên bên phải, bạn có thể chọn hiển thị Pipeline ID hoặc pipeline IID trong danh sách thả xuống. Nhấp vào một pipeline để mở trang chi tiết. Tại đây bạn sẽ thấy tất cả các job trong pipeline đó. Bạn có thể hủy pipeline đang chạy, chạy lại các job thất bại, hoặc xóa pipeline từ trang này.

Trang chi tiết pipeline còn hiển thị sơ đồ các job trong pipeline dưới dạng đồ thị:

Những câu hỏi thường gặp

Tôi có thể sử dụng CI/CD cho project không dùng container không?

Tất nhiên là được. CI/CD không chỉ giới hạn cho các project sử dụng container. GitLab CI/CD linh hoạt và có thể được cấu hình để hoạt động với nhiều loại dự án khác nhau.

Tôi có thể sử dụng CI/CD bên ngoài GitLab không?

Các nền tảng tương tự như GitLab như GitHub hay Bitbucket đều cung cấp các tính năng CI/CD. Thậm chí bạn còn có thể tích hợp giải pháp CI/CD bên ngoài như Jenkins, Travis CI, hoặc CircleCI vào dự án GitLab hay GitHub.

Có bao nhiêu loại pipeline?

GitLab có 4 loại pipeline chính:

• Pipeline cho branch (branch pipeline): Loại này chạy mỗi khi bạn commit thay đổi vào một branch. Nó giúp kiểm tra code mới ngay khi được đẩy lên.
• Pipeline cho merge request (merge request pipeline): Những pipeline này chạy mỗi khi có thay đổi ở branch nguồn trong một merge request. Nó giúp kiểm tra xem code mới có tương thích và hoạt động tốt với branch đích hay không.
• Pipeline kết quả merge (merge result pipeline): Đây là một dạng pipeline merge request đặc biệt. Nó chạy trên kết quả của việc merge branch nguồn và branch đích lại với nhau. Điều này giúp phát hiện sớm các vấn đề có thể xảy ra sau khi merge.
• Merge train: Đây là giải pháp cho các dự án có nhiều merge thường xuyên vào branch chính. Nó đặt các merge request vào một queue và so sánh chúng với nhau để đảm bảo tất cả tương thích với nhau.

Xem thêm nội dung tương tự:

• [Hướng dẫn] Jenkins CI/CD: Full kiến thức cơ bản từ A – Z
• Cách tạo CI/CD Pipeline với Jenkins trên Amazon ECS
• Hướng dẫn tối ưu vòng phản hồi Ci/CD chi tiết

Lời kết

GitLab CI/CD mang lại nhiều lợi ích to lớn cho quy trình phát triển phần mềm. Nó không chỉ giúp tăng tốc độ phát triển và triển khai, mà còn nâng cao chất lượng sản phẩm thông qua việc phát hiện và sửa lỗi sớm.

Locker hy vọng bài hướng dẫn này đã cung cấp cho bạn một cái nhìn tổng quan về cách triển khai CI/CD với GitLab. Đừng ngần ngại để lại bình luận nếu bạn vẫn còn thắc mắc nào đó. Chúng tôi sẵn sàng giải đáp chúng cho bạn.