Hướng dẫn Setup Jenkins cho hệ thống Monolith - Bài 1: Tổng quan về CI/CD và lý do hệ thống Monolith cần tự động hóa triển khai

1. Đặt vấn đề: Nỗi đau "deploy thủ công" trong hệ thống Monolith

Hệ thống Monolith (kiến trúc nguyên khối) có đặc trưng là toàn bộ mã nguồn (Business Logic, UI, Data Access Layer) nằm chung trong một codebase duy nhất.

• Khi dự án còn nhỏ, việc deploy rất đơn giản: SSH vào server, git pull, build và restart lại service.

• Tuy nhiên, khi dự án lớn dần, mã nguồn phình to, số lượng lập trình viên tăng lên, cách deploy thủ công này trở thành một "cực hình" ẩn chứa vô số rủi ro:

  • Human Error: Lỗi do con người gõ nhầm lệnh trên Production, quên chạy lệnh migration database, hoặc sót một file cấu hình môi trường .env.

  • Thời gian downtime kéo dài: Việc build, test thủ công rồi copy file lên server mất nhiều thời gian, khiến hệ thống gián đoạn lâu hơn dự kiến.

  • Khó khăn khi tích hợp code: Nhiều dev cùng đẩy code lên nhánh main/master, dẫn đến xung đột phút chót (merge conflict) hoặc code của người này ghi đè code của người kia.

  • Thiếu sự minh bạch: Không ai nhớ rõ phiên bản nào đang chạy trên Production hoặc ai là người vừa deploy bản cập nhật đó.

2. CI/CD là gì và vị cứu tinh mang tên Jenkins?

Để giải quyết bài toán trên, CI/CD (Continuous Integration / Continuous Delivery - Tích hợp liên tục và Phân phối liên tục) ra đời như một quy trình tiêu chuẩn:

• Continuous Integration (CI): Khi dev push code lên Git, hệ thống sẽ tự động kéo code về, chạy linter, chạy unit test và build thử nghiệm để đảm bảo code mới không làm hỏng hệ thống hiện tại.

• Continuous Delivery / Deployment (CD): Sau khi vượt qua các bước kiểm tra ở CI, mã nguồn sẽ được tự động đóng gói và đẩy lên các môi trường (Staging, Production) mà không cần can thiệp thủ công quá nhiều.

Jenkins chính là công cụ mã nguồn mở mạnh mẽ và phổ biến nhất để hiện thực hóa quy trình này nhờ khả năng tùy biến vô hạn thông qua hệ thống Plugin khổng lồ.

3. Kiến trúc CI/CD tối ưu cho hệ thống Monolith với Jenkins

Đối với Monolith, vì toàn bộ ứng dụng đóng gói trong một cục (ví dụ: một file .jar của Spring Boot, một thư mục project Laravel/Node.js lớn), quy trình CI/CD chuẩn qua Jenkins sẽ diễn ra theo các bước khép kín sau:

[ Developer Push Code ] 
         │
         ▼
[ Git Repository (GitHub/GitLab) ] 
         │ (Trigger Webhook)
         ▼
[ Jenkins Server (CI/CD Pipeline) ]
   ├── Bước 1: Checkout Code & Cài đặt dependencies (npm install / composer install / maven clean)
   ├── Bước 2: Chạy Unit Test & Static Code Analysis (SonarQube)
   ├── Bước 3: Đóng gói Artifact (Build thành Docker Image hoặc nén file Tar/Jar)
   └── Bước 4: Deploy tự động lên Server (Staging / Production) qua SSH hoặc Docker Registry

4. Lợi ích mang lại khi áp dụng cho Monolith

• Chuẩn hóa quy trình: Mọi bản build đều trải qua các bước kiểm tra giống hệt nhau, loại bỏ hoàn toàn yếu tố "phụ thuộc vào tâm trạng của người deploy".

• Phát hiện lỗi sớm (Fail Fast): Lỗi được khoanh vùng ngay từ khâu CI (khi chạy test/build), tránh việc lỗi lọt đến tận tay khách hàng trên Production.

• Tăng tốc độ phát hành (Time-to-market): Thay vì mất cả buổi tối cuối tuần để deploy, giờ đây việc phát hành một tính năng mới chỉ mất vài phút bấm nút hoặc tự động hoàn toàn sau khi Merge Pull Request.