Đây chỉ là những thông tin cơ bản về CI/CD để giúp những người chưa làm việc với nó sẽ có một chút kiến thức mới để phát triển bản thân trong ngành công nghệ thông tin này. Vậy chúng ta hãy cùng bắt đầu từ khởi điểm, CI/CD là gì?
CI/CD là gì?
CI là viết tắt của Continuous Integration (tích hợp liên tục), CD là viết tắt của Continuous Delivery (chuyển giao liên tục) hoặc Continuous Deployment (triển khai liên tục).
CI/CD thường được đề cập tới trong việc tự động hoá trong quy trình phát triển phần mềm và triển khai sản phẩm, giúp cho việc tích hợp diễn ra nhanh hơn và sản phẩm hoàn thiện sẽ tới tay người dùng sớm nhất.
Hiện CI/CD được áp dụng khá rộng rãi vào quy trình làm việc trong lĩnh vực IT, song hành với DevOps và Agile. Một quy trình CI/CD hoàn chỉnh sẽ là:
- Các dev đẩy code lên server.
- Quy trình CI/CD sẽ tự động chạy build, test và deploy sản phẩm.
- Chuyển giao sản phẩm đến người dùng.
Một ví dụ dễ thấy cho CI/CD là Jenkins – một ứng dụng Web mã nguồn mở được viết bằng Java, đóng vai trò máy chủ build & test của hệ thống tích hợp liên tục. Việc cấu hình cho CI và CD trên Jenkins cũng rất dễ để có thể tìm đọc và tham khảo trên mạng.
Vậy CI/CD khác biệt gì với một quy trình phát triển phần mềm thủ công?
Sự khác biệt khi phát triển phần mềm áp dụng CI/CD là gì?
Thường thì việc phát triển phần mềm kiểu cũ sẽ khá thủ công và mất nhiều thời gian. Ví dụ như các developer sau khi code xong thì sẽ build trực tiếp trên máy tính cá nhân, chờ build hoàn tất. Sau đó, họ lại phải upload thủ công lên một phần mềm để thử nghiệm bản beta, qua vài ba bước thao tác rồi lại chờ đến khi upload xong hoàn toàn. Khi đó developer mới thông báo đến team Tester và bắt đầu thực hiện kiểm thử cho toàn bộ sản phẩm.
Nếu trong quá trình trên có gì sai sót thì quy trình gần như sẽ quay lại từ đầu. Và việc delay giữa hai bên sẽ tương đối dài, khiến cho dự án bị delay theo như một hiệu ứng domino vậy. Thêm nữa là, khi developer phát triển một tính năng mới mà gây ảnh hưởng xấu hay nói cách khác là hỏng tính năng cũ đang chạy, việc “thủ công” như vậy sẽ làm tiêu tốn rất nhiều thời gian, tiền bạc, sức lực của cả doanh nghiệp nói chung và các nhân viên nói riêng.
Áp dụng CI/CD là cách loại bỏ triệt để các vấn đề trên. Những gì developer cần làm chỉ là commit code, còn lại tất cả quy trình bao gồm chạy build, test, deploy sẽ được tự động thực hiện hoàn toàn bởi công cụ CI/CD. Và nếu có thể kết hợp thêm với automation test nữa thì tuyệt vời ông mặt trời luôn, quy trình phát triển phần mềm sẽ trở nên chặt chẽ và hạn chế được tối đa các lỗi phát sinh hơn (ví dụ như lỗi tính năng mới ảnh hưởng tới tính năng cũ đã đề cập bên trên).
Qua hai phần trên, ta đã biết CI/CD là gì và sự “Khác biệt to lớn – Trịnh Thăng Bình” của nó ra sao. Giờ hãy cùng tìm hiểu một chút về cách vận hành của CI/CD nhé.
Cách thức hoạt động của CI/CD
Theo như những gì mình đã tìm hiểu, quy trình CI/CD sẽ có sự phối hợp của Git repository và CI/CD tool.
Khi developer tạo ra bất kì sự thay đổi trên Git repository (ví dụ: tạo pull request) thì Git repository sẽ phát đi thông báo đến CI/CD tool là có thay đổi như thế nào. Sau khi nhận thông báo, CI/CD tool sẽ tự động thực hiện các thao tác đã được cấu hình trước đó cho hành động này.
Sau khi thực hiện tất cả các lệnh đã được cấu hình ở trên, CI/CD tool sẽ gửi cho Git repository một “thông điệp vũ trụ” để biết được rằng hành động đó có pass hết các quy trình bên phía CI/CD hay không.
Khi này, Reviewer chỉ cần nhìn vào trạng thái cuối cùng của hành động đó (passed hay failed) để biết hành động đó đã đáp ứng được chất lượng, đã tối ưu hay chưa.
Giờ thì ta cùng tìm hiểu những ưu nhược điểm của CI/CD nào.
Ưu điểm và nhược điểm của CI/CD là gì?
Những ưu điểm của CI/CD có thể kể đến là:
- Tránh được những lỗi không đáng có như lỗi compile hay các lỗi liên quan tới môi trường build sản phẩm (ví dụ như cùng một source code nhưng môi trường build của máy A và máy B khác nhau, dẫn tới conflict).
- Đảm bảo logic (nếu có config automation test trong CI/CD tool), tức là khi làm một tính năng mới sẽ không ảnh hưởng tới tính năng cũ.
- Giúp tập trung vào công việc bởi quy trình CI/CD đã tự động hoá nên developer không cần build và deploy phần mềm trên máy cá nhân nữa.
- Phát triển kĩ năng unit test cho developer thông qua các chỉ số ràng buộc về code coverage được cài đặt trong CI/CD tool, khiến các developer chú trọng việc unit test hơn.
- Tối ưu tốc độ phát triển sản phẩm thông qua việc theo dõi thời gian build pipeline (các bước chạy test, build, … đã được config trên CI/CD từ trước).
Bên cạnh những ưu điểm, nhược điểm của CI/CD cũng cần phải được lưu ý:
- CI/CD chỉ cover được một phần logic, vì vậy developer vẫn phải dành thời gian để review code thủ công nhằm đảm bảo sự phù hợp với tiêu chuẩn của team.
- Trong một dự án nếu có quá nhiều developer cùng tham gia, sẽ có thời điểm nhiều pull request được sinh ra cùng lúc và cần được merge vào branch. Lúc này các dev phải chờ pull request của người trước được merge hoàn tất, sau đó pull code mới về và update để fix conflict được thông báo trên Git repository và phải trải qua các bước test lại từ đầu. Hệ quả là làm gián đoạn thời gian phát triển sản phẩm.
- Vì sử dụng phần mềm thứ 3 chính là CI/CD tool nên nếu service đó gặp vấn đề và bị crash, bị khai tử, như vấn đề của DigitalOcean mới bị gần đây thì những dự án áp dụng tool này cũng bị ảnh hưởng khá nghiêm trọng.
Lời kết
Hiện đây mới là những thứ cơ bản về CI/CD. Nếu có thiếu sót hay muốn có thêm những vấn đề chuyên sâu hơn về CI/CD, mong mọi người để lại những bình luận đóng góp ở bên dưới để mình bổ sung và có thể sẽ có phần 2 về CI/CD. Thank all.
