CI-CD in gitlab

Chắc hẳn mọi người đã từng nghe tới CI-CD, rồi thắc mắc không biết nó là gì và chúng ta có thể làm gì với nó? Mình cũng như vậy, thắc mắc ấy đưa mình đến việc viết chuỗi bài này để chia sẻ về những gì mình đã học được về CI-CD.

Trong bài này thì mình sẽ tập trung vào CI, cũng như cách config file .gitlab-ci.yml và chạy trên share runner của gitlab.

I. Vậy CI-CD là gì?

CI (Coutinous Integration) – tích hợp liên tục, là quá trình mà code của chúng ta được build và test trước khi tích hợp vào nhánh chính.

CD (Continous Delivery) – truyền tải liên tục, là quá trình mà code được triển khai lên môi trường như development hoặc production, và nó diễn ra ngay sau CI

II. Triển khai CI như thế nào?

1. Thành phần

Để có thể triển khai được CI thì trước hết, chúng ta cần biết về 2 thành phần chính cấu thành nên nó. Đó là file gitlab-ci.yml và gitlab runner.

Mọi người có thể hiểu nôm na nếu gitlab runner như một anh tài xế mà bạn thuê, anh ta rất nhiệt tình, sẵn sàng lái xe đi bất cứ nơi đâu thay cho bạn, nhưng khổ nỗi anh lại không biết đường. Hmm… Làm sao bây giờ? File gitlab-ci.yml lúc ấy xuất hiện như một tấm bản đồ vạn năng.

File này sẽ được gitlab tự động nhận diện khi bạn commit code lên từ local, và sẽ cấp cho bạn một anh "tài xế" shared runner để đi làm những việc bạn đã vạch sẵn ở trong gitlab-ci.yml.

Lưu ý:

Mặc định, gitlab có một số share runner mà người dùng có thể dùng ngay lập tức. Vì vậy, đối với một project vừa và nhỏ, số lượng job cho runner còn ít, thì bạn có thể tận dụng luôn những runner đã có sẵn này. Nhưng với một project lớn hơn, khi mà số lượng cũng như tần suất chạy job ngày càng tăng lên, thì chúng ta nên config riêng một gitlab-runner trên server của mình.

2. Template

stages:          
  - build
  - test
  - deploy

build-job:      
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test-job:
  stage: test   
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"

lint-test-job:   
  stage: test   
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-job:     
  stage: deploy  
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

Templete cho một file gitlab-ci.yml

Chúng ta sẽ cùng nhau đi qua một lượt xem nó có ý nghĩa gì nhé!

Đầu tiên là stages: đây sẽ là khi chúng ta định nghĩa ra các giai đoạn mà trong pipeline, hay nói cách khác là các job mà runner sẽ phải thực hiện. Như đa số project, workflow sẽ bao gồm 3 giai đoạn, đầu tiên chúng ta sẽ tạo ra một bản build của project, tiếp sau đó sẽ test, và khi đã qua được các bước trên thì sẽ deploy lên môi trường development, staging hay production.

stages:    
  - build
  - test
  - deploy

Tiếp theo, chúng ta sẽ đi cụ thể tới các build stage nha (Các giai đoạn sau cũng tương tự).

• build-job là tên của job, cái này các bạn có thể tự thay đổi theo ý mình nhé.
• stage chỉ ra job này đang nằm trong giai đoạn nào trong 3 stages mà chúng ta đã định nghĩa trước ở trên.
• script là những câu lệnh mà chúng ta sẽ chạy trong job này.

build-job:      
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

Ngoài ra thì còn rất nhiều những thông tin config khác mà các bạn có thể tìm ở đây nha!

Và như bạn đã thấy ở templete trên, thì một pipeline có thể có nhiều giai đoạn và một giai đoạn có thể chứa nhiều job khác nhau và các job đó có thể được thực hiện song song.

3. Ví dụ

Mình sẽ lấy ví dụ từ bẳng việc check lint của một project nodejs nha!

Bước 1: Chúng ta sẽ phải cài đặt eslint và babel-eslint cho project của mình.

npm install eslint babel-eslint --dev

Bước 2: Tạo file .eslintrc để config lint rule mà mình muốn:

{
  "env": {
    "node": true,
    "es6": true,
    "mocha": true
  },
  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaVersion": 2017
  },
  "extends": "eslint:recommended",
  "rules": {
    "comma-spacing": [
      "error",
      {
        "before": false,
        "after": true
      }
    ],
    "indent": [
      "error",
      2,
      {
        "SwitchCase": 1
      }
    ],
    "linebreak-style": [
      "error",
      "unix"
    ],
    "quotes": [
      "error",
      "double"
    ],
    "semi": [
      "error",
      "always"
    ],
    "no-unused-vars": [
      "off"
    ],
    "no-console": 0
  }
}

Bước 3: Thêm script cho việc check lỗi và fix lỗi lint trong file package.json

Trong dấu "{}" ở câu lệnh lint là các folder mà mình muốn check lint, các bạn có thể để folder khác cho phù hợp với project của mình nhé!

Bước 4: Chạy lần lượt hai câu script trên và đẩy code lên git.

Bước này là để trước khi các bạn check xem những nhánh phụ merge vào có đúng theo rule lint mình đã định nghĩa không, thì nhánh chính của mình đã thỏa mãn những rule đó từ trước.

Bước 5: Tạo file .gitlab-ci.yml

stages:   
  - checklint

lint-test-job: 
  stage: checklint    
  image: node:12.18-alpine 
  only:           
    refs:
      - merge_request
  script:
    - npm install eslint babel-eslint
    - npm run lint

Ở đây sẽ có 2 từ khóa mới:

image: dùng base image là node:12.18-alpine để tạo một node instance chạy các câu lệnh mình định nghĩa ở phần script

only và refs: giới hạn việc chạy job này chỉ khi có merge request

Bước 6: Tách nhánh mới, đẩy lại code lên gitlab và tạo merge request

• Đây là ở merge request trước khi chúng ta đẩy file gitlab-ci.yml lên remote repo