Hướng dẫn Setup Jenkins cho hệ thống Monolith - Bài 8: Khám phá Jenkinsfile và cú pháp Declarative Pipeline cơ bản

Sau khi đã làm quen với Freestyle Job ở Bài 7, bạn sẽ nhận ra một điểm yếu chết người: toàn bộ cấu hình nằm ẩn sâu trong giao diện web của Jenkins, rất khó quản lý phiên bản (Version Control), khó chia sẻ và không thể review code trước khi thay đổi quy trình.

Đó là lúc Jenkinsfile ra đời.

1. Jenkinsfile và tư duy "Pipeline-as-Code" là gì?

• Bản chất: Jenkinsfile là một tệp văn bản thuần túy (text file), định nghĩa toàn bộ quy trình CI/CD của ứng dụng Monolith.

• Đặt ở đâu: Tệp này sẽ được lưu trực tiếp tại thư mục gốc (root directory) trong kho chứa mã nguồn Git của hệ thống Monolith, đi song hành cùng code của bạn.

• Lợi ích tuyệt đối:

  • Khi lập trình viên sửa đổi quy trình build, họ tạo Pull Request giống như sửa code bình thường.

  • Nếu Jenkins server bị hỏng, toàn bộ cấu hình CI/CD vẫn được bảo toàn nguyên vẹn trên Git.

2. Hai cú pháp Pipeline chính trong Jenkins

Jenkins hỗ trợ 2 loại cú pháp viết Pipeline:

1. Scripted Pipeline: Viết dựa trên ngôn ngữ Groovy truyền thống, rất linh hoạt, uyển chuyển nhưng đòi hỏi kỹ năng lập trình cao và khó đọc hơn cho người mới.

2. Declarative Pipeline: Cú pháp hiện đại, chuẩn hóa, có cấu trúc rõ ràng, dễ đọc, dễ viết và được khuyến nghị sử dụng rộng rãi nhất hiện nay.

(Trong series này, chúng ta sẽ tập trung hoàn toàn vào Declarative Pipeline).

3. Cấu trúc chuẩn của một Declarative Pipeline cho hệ thống Monolith

Một Jenkinsfile chuẩn chỉnh cho ứng dụng Monolith thường có cấu trúc cơ bản như sau:

Groovy

pipeline {
    agent any // Xác định môi trường chạy (có thể chỉ định Docker agent cụ thể)

    environment {
        // Khai báo các biến môi trường dùng chung toàn cục
        APP_NAME = "monolith-backend"
        DOCKER_REGISTRY = "registry.yourcompany.com"
    }

    stages {
        stage('1. Checkout Code') {
            steps {
                echo "Đang kéo mã nguồn từ kho chứa Git..."
                checkout scm
            }
        }

        stage('2. Install Dependencies') {
            steps {
                echo "Cài đặt các thư viện phụ thuộc cho Monolith..."
                // Ví dụ cho Node.js: sh 'npm install'
                // Ví dụ cho Java: sh 'mvn dependency:resolve'
            }
        }

        stage('3. Run Unit Tests') {
            steps {
                echo "Chạy hệ thống kiểm thử tự động..."
                // sh 'npm test' hoặc sh 'mvn test'
            }
        }

        stage('4. Build Artifact') {
            steps {
                echo "Đóng gói ứng dụng thành file JAR/ZIP hoặc Docker Image..."
                // sh 'mvn clean package -DskipTests'
            }
        }
    }

    post {
        always {
            echo "Dọn dẹp workspace sau khi build xong."
        }
        success {
            echo "Pipeline chạy thành công rực rỡ!"
        }
        failure {
            echo "Pipeline gặp lỗi! Gửi thông báo khẩn cho đội ngũ."
        }
    }
}

4. Giải mã các thành phần cốt lõi

• pipeline { ... }: Khối lệnh bao trùm toàn bộ tệp, bắt buộc phải có.

• agent: Nơi chỉ định máy chủ hoặc container sẽ thực thi pipeline này.

• stages: Chứa danh sách các bước lớn (stage) cần thực hiện tuần tự.

• steps: Các câu lệnh cụ thể (sh, echo,...) sẽ được chạy bên trong mỗi stage.

• post: Khối xử lý hậu kỳ, chạy tự động ở cuối pipeline tùy thuộc vào kết quả thành công hay thất bại.