Is jenkins Dead?

Đã thực sự tới hồi kết của Jenkins?
Câu trả lời có lẽ thực sự phụ thuộc vào người dùng. Nếu bạn còn sử dụng Jenkins, còn thấy Jenkins cập nhật, phát hành các phiên bản mới, Jenkins hẳn vẫn phát triển. Nếu bạn không còn sử dụng Jenkins, không cập nhật tin tức về công cụ CI/CD này, Jenkins hẳn chỉ còn là quá khứ.
Nhưng mình sẽ thực sự đưa tới các bạn các con số không biết nói dối về sự sống còn của Jenkins. 54% là con số về số lượng lập trình viên có đang sử dụng Jenkins với tính năng CI/CD, theo báo cáo Developer Ecosystem Survey by JetBrains. Bạn có thể nghi ngờ về tập mẫu các lập trình viên tham gia khảo sát cũng như sự trung thực về kết quả của cuộc khảo sát. Nhưng những từ khóa Jenkins trong các Job Description hẳn sẽ vẫn xuất hiện rất nhiều. Báo cáo Kubernetes job trends report có đề cập rằng Jenkins là công cụ CI/CD phổ biến nhất trong các tin tuyển dụng.
Điều này cho thấy Jenkins vẫn là một công cụ CI/CD quan trọng trong bối cảnh công nghệ hiện tại, giữa sự phát triển vũ bão của các công cụ CI/CD cloud-native như GitLab CI, GitHub Actions, AWS CodePipeline,…

Lược sử Jenkins

Trước cả khi cái tên Jenkins được ghi chép trong sử sách, Hudson phiên bản đầu tiên được ra mắt trong nằm 2004 bởi huyền thoại sáng tạo Kohsuke Kawaguchi. Nếu đã từng sử dụng Jenkins, gặp lỗi và debug, bạn hẳn đã gặp từ khóa hudson trong các dòng log. Biến cố thực sự bắt đầu xảy ra trong những năm 2010 và 2011. Khi Oracle mua lại Sun Mircrosystems - công ty phát hành Hudson - đã có vấn đề nảy sinh giữa Oracle và cộng động Hudson - những người cống hiến vào dự án - liên quan tới cơ sở hạ tầng được sử dụng, vấn đề này cũng bao gồm các câu hỏi về khả năng quản lý và kiểm soát của Oracle. Tranh chấp đã diễn ra triền miên, kết quả là vào ngày 11/1/2011, một cuộc kêu gọi bỏ phiếu đã được thực hiện để đổi tên dự án từ “Hudson” thành “Jenkins”. Đề xuất này đã được cộng đồng chấp thuận với số phiếu áp đảo vào ngày 29/1/2011, tạo ra dự án Jenkins.

Học Jenkins liệu có đáng không?

Nếu bạn bắt đầu chập chững trên hành trình trở thành DevOps, sẽ là hoàn hảo để học Jenkins.
Một khi đã hiểu về Jenkins, bạn có thể dễ dàng thích ứng với bất kỳ công cụ CI/CD khác. Workflow vẫn sẽ là workflow, chỉ có sự khác biệt về cú pháp và cấu hình để xây dựng nên Workflow mong muốn của bạn. Chúng ta hãy xem bảng dưới đây để thấy sự tương tự về mặt ý tưởng của các công cụ.

Nếu chỉ cần xây dựng pipeline, những khái niệm trên là cần và đủ để bạn tạo nên bất kỳ workflow trên bất kỳ công cụ CI/CD. Nhưng mỗi công cụ sẽ có những ưu điểm và yếu điểm hay đơn giản là không phù hợp với môi trường làm việc. Ví dụ, bạn sử dụng Bitbucket làm kho lưu trữ source code, bạn sẽ không sử dụng công cụ CI/CD của các nhà cung cấp kho lưu trữ Git khác như GitLab CICD hay GitHub Actions, bạn có thể sử dụng Bitbucket Pipeline hoặc Jenkins. Một ví dụ khác về ưu điểm của Jenkins, với yêu cầu về chi phí tiết kiệm nhất, môi trường của bạn là on-premises và yêu cầu hạn chế đẩy mã nguồn ứng dụng ra bên ngoài internet, chắc hẳn công cụ mà bạn sẽ nghĩ tới đầu tiên chính là Jenkins.

Hơn cả những gì mà chúng ta thường nghe về Jenkins: là một công cụ CI/CD. Jenkins ở thuở sơ khai, gốc rễ là một công cụ tự động hóa, phục vụ cho đa dạng các mục đích khác nhau:

• Run CI/CD pipeline: thực thi các CI/CD pipeline với đa dạng tích hợp và khả năng mở rộng.
• Run Automation test: kết nối các agent và chạy các kịch bản automation test.
• Infrastructure as Code: tự động tạo và cấu hình cơ sở hạ tầng thông qua các tích hợp Terraform, Ansible, CloudFormation và quản lý các thay đổi nhằm đảm bảo sự nhất quán giữa các môi trường.
• Data pipeline: Tự động thực thi các bước trong data pipeline và quản lý hoạt động các pipeline trực tiếp trên Jenkins.
• Batch job, schedule job: rất nhiều tác vụ tự động đều có thể hoạt động trên Jenkins, như backup, clean up, event trigger,…

Các vấn đề của Jenkins

Bây giờ, hãy tìm ra câu trả lời cho câu hỏi tại sao mọi người rời bỏ Jenkins.

1. Thiếu tính khả dụng cao
   Kiến trúc của Jenkins ngay từ đầu đã không hướng tới đảm bảo tính chất khả dụng cao. Trong Cluster Jenkins, chỉ có thể có 1 node master được phép điều khiển cấu hình và dữ liệu của cluster. Nếu có 2 node master cùng hoạt động, cấu hình và dữ liệu cluster ở 2 node là độc lập và không nhất quán. Tuy nhiên, có những cách thức có thể giúp giảm nhẹ vấn đề này, ví dụ như backup cấu hình và dữ liệu, sử dụng node backup master, tạo cluster disaster recovery.
2. Chi phí bảo trì
   Một vấn đề chung của các giải pháp open source đó là bảo trì và nâng cấp. Công việc này không phải là chờ và nhận thông tin về bản cập nhật mà nhà phát hành đã cập nhật. Công việc này cũng không dễ dàng như ấn nút cập nhật cho các ứng dụng trên Windows, MacOS,… Chúng ta sẽ cần một tá việc để cập nhật và nâng cấp khi có một bản vá hoặc phát hành mới. Việc duy trì Jenkins luôn được cập nhật mới nhất là công việc đòi hỏi khắt khe, liên quan đến việc quản lý thường xuyên các plugin, các bản cập nhật, duy trình tính tương thích giữa các thành phần, và cơ sở hạ tầng mà Jenkins được cài đặt.
3. Thách thức về mở rộng
   Mở rộng luôn luôn là một vấn đề cần nhắc tới cho tất cả các giải pháp muốn phục vụ số lượng lớn các yêu cầu. Jenkins có thể mở rộng thông qua các tích hợp được cài đặt như Docker, Kubernetes, AWS,… Nhưng đây có thể coi là một thách thức khi công việc đòi hỏi các công cụ thêm, các cấu hình phức tạp để đạt được khả năng mở rộng như ý.
4. Quan ngại bảo mật
   Kha khá các lỗ hổng bảo mật trong quá khứ đã làm dấy lên do ngại về mô hình bảo mật của Jenkins. Mặc dù những bản vá thường xuyên được phát hành, nhưng như đã đề cập ở ý số 2, chi phí để thiết lập bản vá cũng là một thách thức. Mối lo ngại về bảo mật cũng là một yếu tố chung của các open source, khi sự tham gia phát triển, đóng góp tới từ cộng đồng, và yêu cầu phi chức năng tính bảo mật được ưu tiên thấp hơn so với các yêu cầu về chức năng.

Có những vấn đề tồn động, những vẫn phải nói rằng, Jenkins vẫn có một số lợi thế đặc trưng:

• Open source và có hệ sinh thái plugins mở rộng, tích hợp với đa dạng các công cụ hiện đại.
• Cung cấp cấu hình, tùy chỉnh linh hoạt.
• Cộng đồng hỗ trợ lớn.
• Giao diện thân thiện.
• Là lựa chọn triển khai trên môi trường on-premises, có thể rất quan trọng với một số doanh nghiệp.

Các giải pháp thay thế

Hiện nay, các giải pháp về CI/CD có rất nhiều, bạn có thể tham khảo chi tiết tại Landscape CNCF.

Chúng ta cùng điểm qua một số các giải pháp nổi bật có thể thay thế Jenkins.
Các giải pháp sẽ gắn liền với kho lưu trữ Git gồm có:

• GitHub Actions
• GitLab CI
• Bitbucket Pipeline

Các giải pháp đến từ các nhà cung cấp dịch vụ Cloud như:

• AWS CodePipeline
• Google Cloud Build
• Azure DevOps

Các giải pháp enterprise, tập trung vào giải quyết bài toán liên quan tới CI/CD:

• CircleCI
• Harness
• TeamCity
• Bamboo

Giải pháp tiếp cận theo hướng cloud native và opensource khác:

• JenkinsX
• Tekton
• GoCD

Tổng kết

Trong khi Jenkins đương đầu với những khó khăn và thách thức trong bối cảnh công nghệ CI/CD hiện đại, nói rằng “Jenkins đã tới hồi kết” là không chính xác. Jenkins vẫn có một cơ sở người dùng đáng kể và cung cấp những lợi thế riêng biệt. Với nhiều tổ chức, đặc biệt là những tổ chức có quy trình xây dựng phức tạp, yêu cầu tùy chỉnh hoặc yêu cầu nghiêm ngặt về môi trường on-premises, Jenkins vẫn là một lựa chọn khả thi và mạnh mẽ.
Về tương lai, thị phần sử dụng Jenkins có thể sẽ ghi nhận sự giảm do có cạnh tranh của các giải pháp mới hơn, hướng cloud native ngày càng phổ biến hơn. Chúng ta hãy chờ đợi những gì diễn ra thực sự ở tương lai, nơi công nghệ vẫn sẽ phát triển, các yêu cầu trong lĩnh vực DevOps, hay cụ thể hơn yêu cầu về giải pháp CI/CD sẽ đòi hỏi nhiều hơn, khắt khe hơn ở các tính năng chức năng và phi chức năng.