GitLab CI là gì?

  • Wednesday 01/09/2021

GitLab CI là gì?

Trong chu trình của một project, ta thường trải qua nhiều bước khác nhau cho tới khi ra được hoàn chỉnh sản phẩm cuối cùng. Những bước này thường là các bước đồng bộ hoặc xen kẽ, và ta có khái niệm “Continous Integration” tức CI để thực hiện các bước này tự động sau khi ta xây dựng kịch bản cho nó.

GitLab CI được triển khai như một tính năng quan trọng và mang tới sự tiện dụng dành cho những ai đang sử dụng . Bạn không phải trả tiền, nó có sẵn miễn bạn lên kịch bản đúng. Trong bài viết này, Chúng tôi sẽ đưa ra các khái niệm và cùng giải thích cho các bạn hiểu để có kiến thức về “món hàng” thú vị này.

gitlab CI

Tìm hiểu về Git Flow

Mỗi khi một lập trình viên tạo ra các thay đổi trong code, người đó thường lưu lại nó trong một commit. Sau đó, người này đẩy code lên (gọi là  push) lên GitLab CI để những người khác trong đội nhóm của mình có thể thấy nó và đánh giá.

GitLab cũng bắt đầu làm những việc mà nó được giao, khi commit đó lên, nếu mà bạn cấu hình . Những thao tác nó làm, ta gọi là “runner”. Hãy tưởng tượng “runner” thực ra là một máy chủ, tương tự như máy tính của bạn, nhưng thực thi các hướng dẫn có trong file yml nằm ngay trong project của bạn, và nó sẽ bao gồm các báo cáo gửi lại và được hiển thị trong giao diện của mình.

gitflow

Khi lập trình viên nào đó hoàn thành việc làm một tính năng mới hay fix bug (những thao tác đòi hỏi nhiều commit), họ có thể tạo yêu cầu nhập vào cây nhánh chính (Merge Request), nơi mà Git cung cấp giao diện trực quan để đánh giá và tiếp tục đưa ra các cải thiện cho tới khi hoàn tất và được “merged” vào nhánh chính.

Pipelines là gì?

Pipeline bao gồm :

Jobs : Các công việc được giao thực thi. ( Ví dụ : biên dịch mã hoặc chạy test )
Stage : Xác định các thời điểm và cách thực hiện. ( Ví dụ : test chỉ chạy sau khi biên dịch thành công )

Pipeline hoạt động theo nguyên tắc sau :

  • Tất cả các công việc (job) trong cùng một lượt sẽ chạy đồng thời (nếu có đủ số runner cho phép), và lượt tiếp theo sẽ chỉ được bắt đầu nếu lượt trước nó kết thúc và thành công.
  • Khi một công việc nào đó bị fail, lập tức pipeline của nó sẽ dừng lại (Ta sẽ lấy ví dụ ở sau đây). Có một ngoại lệ, đó là nếu một công việc được đánh dấu làm thủ công, thì kể cả khi nó bị fail thì pipeline vẫn tiếp tục.
  • Rõ ràng, nếu bạn có các lượt khác nhau, chẳng hạn như “build” và “deploy“, thì việc tuần tự thực hiện nó sẽ phù hợp hơn thay vì chạy song song. build đã fail thì không thể và không có lý do gì để deploy, đúng không?
  • Mỗi công việc sẽ chỉ làm việc của nó và không bị phụ thuộc vào bất kỳ lượt nào khác ngoài chính nó.

Bên dưới là ví dụ về đồ thị Pipeline thông thường :

pipeline

Tóm lại, các bước để GitLab CI hoạt động như sau :

  • Thêm.gitlab-ci.yml vào thư mục gốc của repo.
  • Cấu hình Runner

Rút gọn lại:

  • Job: là các công việc được giao thực thị
  • Pipeline: chìa khoá để kiểm tra (trong một lượt commit)
  • Stages: các lượt thực hiện.

Config gitlab-ci.yml

Tạo file .gilab-ci.yml

.gitlab-ci.yml được viết theo định dạng YAML. Bạn có thể tìm hiểu thêm tại đây.

Như đã đề cập ở trên, .gitlab-ci.yml cho Runner biết những công việc cần phải làm. Mặc định, nó sẽ chạy một pipeline với 3 stage :

  • build
  • test
  • deploy

Tuy nhiên, bạn không cần phải sử dụng cả 3 stage, các stage không được giao việc sẽ được bỏ qua.

Dưới đây là ví dụ cấu hình đơn giải:

image: php:latest

cache:
paths:
– vendor/

before_script:
– apt-get update -yqq
– apt-get install -yqq git libpq-dev libcurl4-gnutls-dev libicu-dev libvpx-dev libjpeg-dev libpng-dev libxpm-dev zlib1g-dev libfreetype6-dev libxml2-dev libexpat1-dev libbz2-dev libgmp3-dev libldap2-dev unixodbc-dev libsqlite3-dev libaspell-dev libsnmp-dev libpcre3-dev libtidy-dev libonig-dev libzip-dev
# Install PHP extensions
– docker-php-ext-install mbstring pdo_pgsql curl intl gd xml zip bz2 opcache
# Install & enable Xdebug for code coverage reports
– pecl install xdebug
– docker-php-ext-enable xdebug
# Install and run Composer
– curl -sS https://getcomposer.org/installer | php
– php composer.phar install

services:
– mysql:5.7

# Set any variables we need
variables:
# Configure mysql environment variables (https://hub.docker.com/r/_/mysql/)
MYSQL_DATABASE: mysql_database
MYSQL_ROOT_PASSWORD: mysql_strong_password

# Run our tests
# If Xdebug was installed you can generate a coverage report and see code coverage metrics.
test:
script:
– vendor/bin/phpunit –configuration phpunit.xml –coverage-text –colors=never

Đây là cấu hình đơn giản nhất có thể hoạt động với hầu hết các ứng dụng php

Trước mỗi job, các lệnh được xác định bởi before_script được thực thi.

Push .gitlab-ci.yml to GitLab

Sau khi tạo file .gitlab-ci.yml, thêm nó vào git repos và push nó lên.

  • git add .gitlab-ci.yml
  • git commit -m “Add .gitlab-ci.yml”
  • git push origin master

commit

Trở về Pipeline page, bạn sẽ thấy pipeline đang ở trạng thái pending. Bạn cũng có thể tới page Commits, để ý icon tạm dừng nhỏ bên cạnh commit SHA.

Gitlab Runner

Gitlab Runner là thành phần cực kỳ quan trọng trong workflow. Nếu không có Runner thì sẽ không có lệnh test, deploy nào được thực thi. Runner có nhiều loại, phân biệt dựa vào cái gọi là executor. Khi khởi tạo runner, bạn sẽ phải chọn nó là loại executor nào, và nó sẽ quyết định môi trường thực thi các câu lệnh trong file config ở trên. Bạn có thể tham khảo link https://docs.gitlab.com/runner/executors/ để biết sự khác nhau của các executor cũng như cách cài đặt, cấu hình chúng.

Một Runner có thể là một máy ảo (VM), một VPS, một bare-metal, một docker container hay thậm chí là một cluster container. Gitlab và Runners giao tiếp với nhau thông qua API, vì vậy yêu cầu duy nhất là máy chạy Runner có quyền truy cập server.

Một Runner có thể xác định cụ thể cho một dự án nhất định hoặc phục vụ cho nhiều dự án . Nếu nó phục vụ cho tất cả project thì được gọi là Shared Runner.

Để xác định xem Runner nào được chỉ định cho project của bạn. Vào Settings -> CI/CD.

Để Runner hoạt động được, bạn cần thực hiện 2 bước :

1. Cài đặt Runner:

2. Đăng ký Runner:

REGISTRATION_TOKEN sẽ được lấy thông tin như trong hình :

code

Sau khi registration thành công :

success

Kiểm tra trạng thái của các pipeline & jobs trên GitLab CI

Sau khi cấu hình thành công, bạn có thể thấy trạng thái của commit cuối cùng đã chuyển từ pending thành running or success or failed…

Bạn có thể theo dõi tất cả pipeline trong project :

status jobs

GitLab CI giúp gì trong lập trình?

Bạn sẽ có nhiều thứ không cần làm nữa, mà thay vào đó, nó được thực hiện tự động bởi CI.

Chẳng hạn, chu trình thực thi một ứng dụng web ví dụ sẽ là:

  • Kiểm tra code CSS/SCSS/LESS/postCSS xem có đúng syntax không.
  • Kiểm tra Javascript xem có đáp ứng ESLint hay không.
  • Kiểm tra PHP xem có đáp ứng Code Standard hay không.
  • Kiểm tra JSON xem đã viết đúng cấu trúc không.
  • Kiểm tra file image đã được compress chưa.

Nếu thông thường, bạn phải chờ đợi từ trình soạn thảo code (nhưng đôi khi chính lập trình viên lại cố tình bỏ qua), thì nay, với GitLab CI , mọi thứ có thể dễ dàng được kiểm soát và qua kiểm thử.

Thêm vào nữa, với những phần build và deploy khác nhau, bạn sẽ cần tách ra, chẳng hạn:

  • Bước 1: Chạy npm run build
  • Bước 2: Commit code đã compile
  • Bước 3: Sau đó lại chạy npm run deploy để đẩy code lên trên site

Thì nay, toàn bộ thao tác đó sẽ được auto thực hiện qua GitLab CI , bằng cách bạn cứ đẩy code lên branch develop thì sẽ tự build và đẩy lên. Vậy là bớt được việc làm đi làm lại hàng ngày rồi.

Kết luận

GitLab CI không chỉ có ứng dụng thực tiễn mà còn trở thành một món hàng quí giá không thể bỏ qua để bạn tận dụng khi sử dụng tại GitLab. Với vài chia sẻ ngắn ở trong bài viết này, hi vọng bạn sẽ cất công tìm hiểu thêm về GitLab CI và sử dụng nó thành thạo.

———————————

Xem thêm trang hỗ trợ tại link

Tham khảo dịch vụ VPS – Server tại P.A Việt Nam
https://www.pavietnam.vn/vn/vps-server.html

Nhận nhiều thông tin khuyến mãi – ưu đãi tại P.A Việt Nam
https://www.pavietnam.vn/vn/tin-tuc-chuong-trinh-khuyen-mai-ten-mien-hosting.html

5/5 - (1 bình chọn)