0

Tối ưu CI/CD cho Hệ thống Microservices - Bài 2 - Chuẩn hóa Git Workflow & Chiến lược chia nhánh

I. Tại sao Git Flow truyền thống lại trở thành "gánh nặng" ở Microservices?

Git Flow (với các nhánh main, develop, release, hotfix, feature) đã từng là tiêu chuẩn vàng. Nhưng khi hệ thống phân tán thành nhiều services nhỏ viết bằng Node.js hay Go, Git Flow bộc lộ những điểm yếu chí mạng:

  • Xung đột mã nguồn (Merge Hell): Các nhánh feature thường sống quá lâu. Khi gom code lại vào develop, lượng conflict khổng lồ khiến team mất hàng giờ, thậm chí vài ngày để xử lý.

  • Tắc nghẽn Release: Việc phải chờ gom đủ tính năng trên nhánh develop rồi mới tạo nhánh release đi ngược lại triết lý "triển khai liên tục, độc lập" của microservices. Service A không thể chờ Service B hoàn thiện chỉ để được release chung.

II. Trunk-based Development: "Chân ái" cho Microservices

Để luồng CI/CD chạy trơn tru, vòng đời của một nhánh phải cực kỳ ngắn. Trunk-based Development là chiến lược tập trung vào một nhánh chính duy nhất (thường là main):

  • Từ nhánh main, tạo nhánh feature hoặc bugfix để xử lý một task rất nhỏ.

  • Nhánh này chỉ tồn tại trong vòng 1-2 ngày (thậm chí vài giờ).

  • Mở Pull Request (PR) -> Chạy CI kiểm tra (Unit Test, Linting) -> Review nhanh -> Merge thẳng lại vào main.

  • Lợi ích: Code trên main luôn ở trạng thái tươi mới nhất và sẵn sàng để build. Việc tích hợp liên tục được đảm bảo, phát hiện lỗi ngay tức thì sau mỗi thay đổi nhỏ.

III. Quy tắc Đánh phiên bản (Versioning) để điều phối Pipeline

Merge code vào main liên tục không có nghĩa là tự động deploy tất cả lên Production. Ở microservices, việc deploy lên môi trường thực tế nên được điều khiển bằng Tags kết hợp với Semantic Versioning (SemVer) (ví dụ: v1.2.0, v1.2.1).

Làm sao để tự động hóa việc sinh ra các version này mà không cần sửa file thủ công?

  1. Áp dụng Conventional Commits: Đưa toàn bộ team vào kỷ luật viết commit message theo chuẩn chung.

    • feat: thêm API tra cứu hành trình -> Hệ thống tự hiểu cần tăng Minor version (ví dụ v1.1.0 -> v1.2.0).

    • fix: xử lý lỗi mất kết nối Redis -> Tự động tăng Patch version (v1.2.0 -> v1.2.1).

    • BREAKING CHANGE: đổi core logic tính giá -> Tự động tăng Major version (v2.0.0).

  2. Tự động sinh Tag (Automated Release): Sử dụng các công cụ như semantic-release trong bước cuối của CI pipeline. Nó sẽ tự động quét lịch sử commit từ lần đánh tag trước, tự tính toán ra version mới, tạo Changelog và gắn Git tag.

  3. Trigger CD: Chỉ khi một Tag mới được tạo thành công trên repository, luồng CD (Continuous Deployment) mới được kích hoạt để build Docker Image (gắn đúng tag version đó) và tự động cập nhật lên server.

IV. Tổng kết bài học

Sự kết hợp giữa Trunk-based Development (giữ mạch code luôn liền mạch) và Automated Semantic Versioning (điều khiển điểm rơi deploy) sẽ tạo ra một bộ máy tự động hóa hoàn hảo. Bạn chỉ cần viết code và commit đúng chuẩn, CI/CD sẽ tự động phân loại, đóng gói và triển khai chính xác từng service mà không sợ chồng chéo.


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí