[CI/CD] - Tổng quan về Jenkins

Hế lô anh em, lâu lâu rồi nhỉ!

Bài viết hôm mình sẽ cùng anh em tìm hiểu về một công cụ hỗ trợ CI/CD khá phổ biến hiện nay - nói đến đây chắc anh em cũng biết là công cụ gì rồi.

Yepp chính là Jenkins! Cơ mà phổ biến thì có đầy tài liệu, hướng dẫn rồi cần gì làm nữa cho mất công 🤔

Thực ra chia sẻ cũng là một cách để học hỏi vậy nên mình sẽ cố gắng truyền đạt kiến thức dựa trên ý hiểu của mình và hi vọng anh em có thể vừa đọc vừa phản hồi để bài viết được hoàn thiện hơn!

Ngoài ra như mình đề cập bên trên Jenkins có rất nhiều tài liệu tham khảo nên mình cũng sẽ đính kèm ở cuối bài viết. 

Okay, bắt đầu thôi!

1. Đặt vấn đề?

Trước khi trả lời câu hỏi Jenkins là gì mình nghĩ chúng ta nên bắt đầu với câu hỏi  CI/CD là gì và nó đóng vai trò gì trong quá trình phát triển phần mềm?

CI/CD là gì? 

Thực ra anh em Google là ra ngay! Nhưng để bài viết đầy đủ và anh đỡ phải lọ mọ đi tìm thì mình sẽ giải thích cơ bản luôn tại đây.

Tổng quan mô hình CI/CD

CI - Continuous Integration: Mình thấy nhiều tài liệu dịch là quá trình "tích hợp liên tục". Nghe nó sao sao á😅. Vì vậy mình sẽ không dịch và giải thích theo cách hiểu cùa mình như sau:

Ví dụ anh em được giao phát triển một tính năng X và để hoàn thiện tính năng X này anh em sẽ phải hoàn thiện các tính năng A, B, C nhỏ hơn nhưng độc lập nhau.

Với cách làm truyền thống anh em chỉ có cách làm xong toàn bộ sau đó merge code (giả sử anh em code trên một nhánh riêng) vào nhánh chính sau đó đẩy lên server git và build ở các môi trường. 

Cách làm này có nhiều nhược điểm ví dụ như việc anh em tách ra một nhánh riêng trong khi những người khác vẫn code nhánh của họ => lúc merge code vào thì ối giờ ơi luôn nếu lâu không merge. Chưa kể đội kiểm thử (testers) sẽ phải chờ rất lâu để có thể test vì anh em không release được các bản built có chức năng nhỏ A, B, C trước.

Và để giải quyết vấn đề đó khái niệm CI ra đời để giúp quá trình cập nhật mã nguồn liên tục hơn, tự động hơn, giảm thiểu bugs và tăng hiệu năng của lập trình viên.

👉 Vậy cụ thể quá trình CI là làm gì?

Đầu tiên là anh em có một chức năng đã code xong, unit test các thứ thấy ổn rồi. Tiếp theo anh em merge code đó vào nhánh cần build (nếu conflic thì ngồi fix). Okay, sau khi merge xong anh em đẩy code lên server git => code sẽ được build tự động => anh em vào kiểm tra => nếu có bugs quay lại fix

CD - Continuous Delivery: Tương tự thì nhiều tài liệu cũng dịch thuật ngữ này là "phân phối liên tục". Và mình không thích cách dịch này lắm nên sẽ lại giải thích theo cách hiểu của mình.

Nếu như CI thiên về việc build source code thì CD là quá trình chúng ta deploy source code lên các môi trường non-production một cách tự động.

Thế nào là deploy source code? Sau quá trình CI chúng ta đã có source code với những cập nhật mới nhất. Nhưng source code này mới chỉ được unit test (mình thấy nhiều anh còn chả thèm unit test😅)

Và còn rất nhiều nội dung khác như UI testing, loading testing, integration testing, API testing... chưa được kiểm thử.

👉 Vậy cụ thể quá trình CD là làm gì?

CD chính là quá trình sẽ giúp lập trình viên triển khai source code lên các môi trường khác nhau. Có thể tự động hoặc thủ công tùy vào bài toán, dự án cụ thể. Khi mọi môi trường đã ngon lành cành đào rồi thì việc triển khai source code lên môi trường production sẽ được làm thủ công bởi lập trình viên hoặc system admin - đây chính là Continuous Delivery

Có một khái niệm nữa của CD đó là Continuous Deployment. Quy trình này khác với Continuous Delivery ở chỗ source code sẽ được triển khai lên môi trường production tự động thay vì thủ công.

Chà! bảo nói cơ bản thôi mà nói nhiều quá nhỉ! Hi vọng anh em hiểu ha😊

2. Jenkins là gì, làm được gì?

Thời đại 4.0 làm gì mà chả có tool, không những thế tool xịn mới xài còn tool lởm thì có mà lâu mới động đến.

Và anh em đoán đúng rồi đấy! Jenkins chính là một công cụ hỗ trợ CI/CD thuộc loại "hịn" và phổ biến nhất hiện nay!

Jenkins có thể làm gì?

Anh em hãy tưởng tượng quy trình phát triển phần mềm tính từ thời điểm anh em code xong chức năng sẽ như sau: merge code => resolve conflict nếu có => đẩy lên server git => build trên môi trường test => kiểm thử (unit test, intergration test, end to end test...) => build lên môi trường production...

Tất nhiên thực tế có thể còn nhiều giai đoạn nữa nhưng cơ bản sẽ là như vậy. Và... Jenkins nó có thể giúp anh em làm hết những điều này một cách tự động.

Yeppp, có thể hơi quá nếu dùng từ "làm hết" mà không đề cập tới tính chính xác nhưng về lý thuyết Jenkins có thể làm các công việc được mô tả trong ảnh trên.

3. Ý nghĩa sự ra đời của Jenkins 

Nghe hơi to tát nhỉ! Nhưng mà nếu anh em nào làm CI/CD với sự hỗ trợ của Jenkins rồi sẽ hiểu Jenkins đã giúp anh em dev nhiều như thế nào?

Để hiểu rõ hơn vai trò của Jenkins trong mô hình CI/CD hiện nay thì chúng ta lật ngược về quá khứ chút nhỉ - cái thời mà còn chưa có hoặc chưa phổ biến Jenkins hay các công nghệ CI/CD khác.

Mô hình CI/CD truyền thống

(1) - Khi đó quy trình sẽ là anh em dev code xong một chức năng, thực hiện merge code với anh em khác 

(2) - Sau khi code ok rồi, chạy không có lỗi thì sẽ đẩy lại lên server git (shared repository)

(3) - Lúc này server môi trường test sẽ lấy code về và build sau đó deploy. Đội kiểm thử có thể tham gia test ở giai đoạn này. 

(4) - Sau khi test các thể loại ngon lành rồi nếu ổn thì triển khai lên môi trường production.

(4) - Nhưng đời không như là mơ, anh em dev mà code phát ăn luôn thì đã mừng! Đằng này bảo ok rồi nhưng test vẫn có bugs và thế là... ối giời ơi luôn!

Code merge mất rồi, giờ xem lỗi của ông nào thôi cũng lác hết cả mắt chưa kể còn đi fix bugs nữa. Thực ra có thể khắc phục điều này bằng cách tách nhánh (branch) ra khi code nhưng vẫn không triệt để

Kết Luận: Cách làm này phù hợp với các dự án cũ, khi các giai đoạn phân tích thiết kế được làm rất rất kỹ và chiếm nhiều thời gian trong toàn bộ vòng đời của phần mềm. Đội phát triển không cần release các bản build sớm cho khách hàng, người dùng... 

Thế có CI/CD và Jenkins vào thì sao?

Tiện hơn là rõ! Nhưng tiện và hiểu quả hơn như thế nào?

Mô hình CI/CD ứng dụng Jenkins

Hạn chế lỗi: Hạn chế tối đa được việc phải merge code. Tại sao? Vì dev có thể đẩy code liên tục chứ không nhất thiết phải xong cả một chức năng như mô hình cũ.

Tự động: Việc built - test - deploy có thể hoàn toàn tự đồng bằng Jenkins. Điều này giúp dev và quản trị hệ thống giảm được rất nhiều công sức. 

Fix bugs nhanh: Nếu có lỗi Jenkins sẽ báo ngay và báo cụ thể lỗi gì (lỗi code không phải lỗi logic nghiệp vụ nha 😅). Dev chỉ cần tìm đúng commit lỗi và sửa chứ không phải đi soi lại toàn bộ code của cả các thành viên khác. 

Ngon!!!! 

4. Kiến trúc tổng quan của Jenkins

Để hiểu hơn về cách hoạt động của Jenkins thì mình sẽ cùng anh em tìm hiểu về một chút về kiến trúc của Jenkins. 

Kiến trúc tổng quan của Jenkins

Jenkins được xây dựng theo mô hình client - server hay còn gọi là master - slave trong đó server (master) giao tiếp với client (slave) thông qua giao thức TCP/IP

(1) - Jenkins Master đảm nhiệm chức năng chính như sau:

+ Theo dõi và cập nhật source code từ repositories

+ Lập lịch cho các bản build

+ Lưu trữ các thông tin cấu hình liên quan đến users, credentials...

+ Phân phối và gửi các bản build đến các máy client (slave)

+ Tổng hợp và hiển thị kết quả trả về từ các máy client (slave)

(2) - Jenkins Slave thực chất là một file .java được lưu trữ ở các máy client

+ Jenkins slave sẽ theo dõi Jenkins master để ngay khi có yêu cầu sẽ thực thi một bản build nào đó và trả về kết quả.

+ Trường hợp nếu chúng ta cấu hình một project nào đó trên một Jenkins slave cụ thể thì chỉ có project đó chạy trên slave đó. Nếu không thì Jenkins master sẽ tự động lấy các Jenkins slave có thể build để chạy project đó. 

Okay, đó là một vài điểm cơ bản về kiến trúc của Jenkins. Sở dĩ Jenkins hoạt động theo mô hình client - server là cũng có nguyên nhân. 

Đầu tiên là việc nhiều project lớn với tần suât build thường xuyên không thể để mỗi mình server gánh được. Thứ hai là đẩy việc build cho các máy client và nhận về kết quả giúp quá trình build nhanh hơn.

5. Lời kết

Vậy là trong bài viết hôm nay mình đã cùng anh em tìm hiểu về Jenkins - một công cụ hỗ trợ CI/CD khá phổ biến hiện nay.

Ngoài Jenkins còn có rất nhiều công cụ CI/CD khác có thể kể đến như: CircleCI, TeamCity, Bamboo, GitLab, Travis CI...

Hẹn gặp lại anh em trong các bài viết tiếp theo về CI/CD và Jenkins nhé 

Tài liệu tham khảo:

https://www.jenkins.io/doc/developer/architecture/

https://www.toolsqa.com/jenkins/what-is-jenkins/

https://devopscube.com/jenkins-architecture-explained/

https://www.baeldung.com/ops/jenkins-performance