GitLab CI không phải câu chuyện mới, nhưng một khi bạn đã biết đến và sử dụng nó, bạn sẽ bị “nghiện” và không thể từ bỏ nó đâu.
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 GitLab. 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, Code Tốt 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.
Bắt đầu từ 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 để 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 GitLab CI. 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 .gitlab-ci.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 GitLab hiển thị trong giao diện của mình.
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à GitLab 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.
Như các bạn thấy, ngay cả designer và tester cũng có thể tham gia vào bước này, đưa ra các đánh giá và gợi ý cải thiện. Và thật tuyệt rằng nó rất dễ nhìn trong GitLab.
Pipelines là gì?
Giờ, ta sẽ tìm hiểu một khái niệm khác. Đó là pipeline. Hãy tưởng tượng mỗi commit được đưa lên GitLab đồng thời sẽ được gắn một món hàng đính kèm. Nếu nhiều commit được đẩy lên đồng thời, món hàng này sẽ chỉ được gắn vào commit mới nhất. Đấy chính là pipeline, tức một bản thu thập các công việc được chia nhỏ ra ở những giai đoạn khác nhau. Nôm na, nó giống như một miếng tem dán vào commit gần nhất của mỗi lần bạn đẩy code lên GitLab.
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.
Pipeline có một số nguyên tắc bạn nên biết:
- 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ó.
Giờ, ta sẽ cùng quan sát cách thức GitLab CI trong giao diện ứng dụng hoạt động như thế nào nhé?
Hình ảnh về cách thức Pipeline thực thi:
Hình ảnh về thực hiện deploy nhiều bước:
Mô phỏng về một file .gitlab-ci.yml cho các bước tuần tự thực hiện:
stages:
- test
- build
- deploy
test:
stage: test
script: echo "Running tests"
build:
stage: build
script: echo "Building the app"
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging environment"
environment:
name: staging
url: https://staging.codetot.com
only:
- master
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.
Cấu hình GitLab CI
Trong phạm vi bài viết này, Code Tốt sẽ không giải thích cụ thể các bước thiết lập .gitlab-ci.yml mà chỉ tập trung đưa ra các định nghĩa đầu tiên về các thành phần của nó.
Các bạn có thể tìm hiểu qua cấu hình YAML trong GitLab CI.
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.
Đừng quên comment để có thể chia sẻ cùng các độc giả của Code Tốt nhé.
Giám đốc tại Công ty CP CODE TỐT. Quản lý ngôn ngữ bản địa tiếng Việt tại WordPress. Là tác giả chính tại codetot.net, Khôi muốn ghi lại một sốvấn đề kỹ thuật trong quá trình phát triển các dự án website với khách hàng.
