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
featurethường sống quá lâu. Khi gom code lại vàodevelop, 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
developrồi mới tạo nhánhreleaseđ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ánhfeaturehoặcbugfixđể 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
mainluô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?
-
Á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).
-
-
Tự động sinh Tag (Automated Release): Sử dụng các công cụ như
semantic-releasetrong 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. -
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