CI/CD là gì? CI/CD là viết tắt của Continuous Integration và Continuous Delivery/Deployment, được xem như một quy trình kiểu mới, phối hợp tự động hóa hoá giúp đẩy nhanh tiến độ phát triển sản phẩm và đưa sản phẩm đến người dùng cuối cùng.

Bạn Đang Xem: CI/CD là gì? Lợi ích và các nguyên tắc triển khai CI/CD vào quy trình phát triển phần mềm

Để làm rõ hơn về CI/CD, các nguyên tắc triển khai cũng như mối liên hệ giữa CI/CD với Agile trong toàn cảnh thực tế, ITviec đã có buổi san sớt thú vị với những thông tin đầy hữu ích cùng anh Nguyễn Trường Giang – Mobile Tech Lead tại Amanotes qua nội dung bài viết sau đây.

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).

Khái niệm CI/CD thường đề cập đến việc tự động hóa hóa trong quy trình phát triển phần mềm và chuyển giao sản phẩm, hỗ trợ cho việc tích hợp diễn ra nhanh hơn và sản phẩm hoàn thiện được chuyển đến người dùng trong thời kì ngắn nhất.

Hiện nay, CI/CD đã được ứng dụng rộng rãi vào quy trình thao tác làm việc của những doanh nghiệp làm trong ngành IT, song hành cùng với DevOps và Agile. Một quy trình CI/CD hoàn chỉnh có thể được hình dung như sau:

1. Developer commit code (đẩy code lên server).
2. Quy trình CI/CD sẽ tự động hóa chạy build, chạy test và deploy sản phẩm.
3. Tiếp tục chuyển giao sản phẩm đến người dùng.

Sự khác biệt khi phát triển phần mềm ứng dụng CI/CD là gì?

Với một quy trình phát triển phần mềm, tất cả những bước thao tác làm việc của Developer có phần thủ công và mất khá nhiều thời kì. Anh Giang đưa ra ví dụ:

Developer sau khoản thời gian code xong thì sẽ build trực tiếp trên máy tính/máy tính cá nhân member, sau đó chờ code được build hoàn thành. Tiếp Từ đó, họ phải upload thủ công file này lên TestFlight và trải qua 3,4 bước thao tác, rồi lại tiếp tục chờ cho đến lúc kết thúc. File được upload xong hết thì Developer mới thông tin đến team Tester/QA QC và lúc này, team mới mở màn thực hiện công việc kiểm thử cho toàn bộ sản phẩm.

Nếu xẩy ra sơ sót thì quy trình gần như sẽ quay trở về từ trên đầu, thời kì chờ giữa phía hai bên Developer và Tester/QA QC tương đối dài, khiến cho dự án cũng sẽ trì hoãn theo. Đó là chưa tính đến việc Developer khi phát triển một tính năng mới có thể làm hỏng tính năng cũ đang hoạt động trên ứng dụng, mà chỉ khi deploy mới phát hiện ra.

Ứng dụng CI/CD là cách triệt tiêu hiệu quả các bước thủ công trong quy trình phát triển phần mềm/ứng dụng. Việc của Developer chỉ là commit code, còn sót lại tất cả quy trình gồm có chạy build, test, deploy sẽ tiến hành tự động hóa thực hiện hoàn toàn bởi dụng cụ (tool) CI/CD. Nếu có thể phối hợp thêm với automation test thì quy trình sẽ chặt chẽ và hạn chế được tối đa các lỗi phát sinh (ví dụ: lỗi phát triển tính năng mới làm hỏng tính năng cũ).

Phương pháp hoạt động của CI/CD

Theo ông Giang san sớt thì trong quy trình CI/CD tại Amanotes sẽ có được sự phối hợp của (1) là Git repository và (2) là 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 tin đến CI/CD tool là có thay đổi như vậy. Phản hồi với thông tin, phía CI/CD sẽ tự động hóa thực hiện các thao tác đã được setup trước đó cho hành động pull request.

Sau khoản thời gian thực hiện tất cả những lệnh đã được setup kể trên thì CI/CD sẽ update kết quả trái lại cho Git repository biết là pull request được tạo có vượt qua (pass) hết các quy trình (gồm có testing) phía CI/CD hay là không.

Xem Thêm : Pick up là gì? Thuật ngữ trong ngành xuất nhập khẩu thông dụng

Từ đó, khi review code, Reviewer chỉ có nhìn vào trạng thái cuối cùng của pull request (passed hoặc failed) để biết pull request đã đáp ứng được chất lượng sản phẩm và dịch vụ, đã tối ưu hay chưa.

Anh Giang nhận định thêm rằng quy trình CI/CD chỉ có thể cover một phần logic, Developer vẫn phải dành thời kì để review code thủ công nhằm đảm bảo sự phù phù hợp với tiêu chuẩn của tất cả team, và vì thực tế vẫn có một số lỗi mà quá trình tự động hóa (automation) vẫn chưa cover hết được.

Ưu điểm và nhược điểm của CI/CD là gì?

Theo trải nghiệm của họ, anh Giang san sớt một số ưu điểm mà quy trình CI/CD mang lại cho Developer gồm có:

• Tránh khỏi những lỗi không đáng có: ví như lỗi compile (khi đẩy code lên) hoặc các lỗi phát sinh liên quan đến môi trường thiên nhiên build sản phẩm. Ví dụ: khi làm thủ công, cùng 1 source code nhưng sẽ có được sự khác biệt khi chúng ta A build trên máy bạn A, bạn B build trên máy bạn B.
• Đảm bảo logic (vì quy trình CI/CD có phần automation test), khi Developer xây dựng tính năng mới sẽ không khiến tác động ảnh hưởng đến tính năng cũ.
• Giúp tập trung vào công việc bởi quy trình CI/CD mang tính tự động hóa cao nên Developer không cần thiết phải thực hiện việc build và deploy phần mềm/ứng dụng trên máy member nữa.
• Nâng cao chất lượng sản phẩm và dịch vụ code thông qua quy trình, Developer có thể setup những ràng buộc ngay từ trên đầu. Ví dụ: pull request khi được tạo ra thì không được quá to, không được vượt quá X thay đổi…, điều này góp phần giúp chất lượng sản phẩm và dịch vụ pull request ngày càng tốt hơn.
• 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 (% code đã được cover) được setup trong quy trình CI/CD. Nghĩa là lúc phát triển tính năng mới, để không làm giảm chỉ số code coverage, Developer phải ý thức được tầm quan trọng của unit test và dữ thế chủ động học hỏi, nâng cao các kỹ năng liên quan.
• Tối ưu tốc độ phát triển của sản phẩm thông qua việc theo dõi thời kì build pipeline (các bước chạy test, build, chạy static code analytics (lint check)).

Bên cạnh những ưu điểm giúp quy trình CI/CD đáng được cân nhắc để ứng dụng trong tổ chức thì CI/CD vẫn có những hạn chế cần phải lưu ý như:

• Trong một dự án nếu có quá nhiều Developer cùng tham gia phát triển sản phẩm, sẽ có được thời khắc phát sinh nhiều pull request cần được merge vào branch. Lúc này, các thành viên phải chờ pull request của người trước được merge hoàn thành, sau đó thực hiện update (update) lại source code (trong trường hợp có thông tin conflict từ Git repository) và phải trải qua các bước test lại từ trên đầu. Hệ quả là làm gián đoạn thời kì phát triển sản phẩm.
• Vì sử dụng dịch vụ CI/CD của bên service thứ 3 nên nếu service đó gặp vấn đề và bị crash, bị khai tử thì những dự án ứng dụng CI/CD cũng sẽ tác động ảnh hưởng khá nghiêm trọng.

Khi nào nên dùng và khi nào không nên dùng quy trình CI/CD?

Anh Giang khuyến khích các tổ chức nên ứng dụng quy trình CI/CD và việc tích hợp nên thực hiện càng sớm càng tốt. Ý kiến của anh là lúc có quy trình tốt thì chất lượng sản phẩm và dịch vụ công việc của Developer cũng tối ưu hơn. Kể cả khi thực hiện dự án theo member thì vẫn nên tích hợp CI/CD (có thể lựa chọn những service miễn phí) để tận dụng những ưu điểm đã được liệt kê.

Tuy nhiên, trong một số trường hợp như: tổ chức không có người đủ sức vận hành quy trình CI/CD, Developer chưa làm chủ và chưa nắm rõ về tool hoặc không biết làm thế nào để đảm bảo quy trình CI/CD… thì có thể cân nhắc chưa sử dụng. Vì nếu có vấn đề không mong muốn xẩy ra nhưng lại không có người đủ tri thức kinh nghiệm tay nghề để xử lý thì sẽ mất rất nhiều thời kì, gây ra nhiều gián đoạn không cấp thiết.

CI/CD và Agile có mối liên hệ ra sao?

Theo ông Giang thì CI/CD giống như một quy trình bổ sung, hỗ trợ cho việc thực hiện Agile tốt hơn. Nếu như Agile thiên về quy trình quản lý công việc thì CI/CD lại thiên về technical (kỹ thuật), hỗ trợ cho việc phát triển sản phẩm nhanh chóng hơn.

Các nguyên tắc khi triển khai quy trình CI/CD cho tổ chức?

Tuỳ thuộc vào từng tổ chức, nhưng theo anh Giang san sớt thì ngày nay Amanotes đang ứng dụng những nguyên tắc như sau:

• Không bắt buộc toàn bộ các team trong tổ chức ứng dụng quy trình CI/CD, nếu thấy team nào phù hợp thì có thể triển khai trước nhất.
• Nên mở màn càng sớm càng tốt (lúc team ít người hoặc lúc mới mở màn dự án) thì khi đưa vào ứng dụng rộng rãi sẽ gặp ít khó khăn hơn.

• Đừng ngại thử nhiều bên service để lựa lựa chọn ra được service phù thống nhất vì sẽ có được service phù hợp cho team này nhưng không đáp ứng được nhu cầu của team khác. Ví dụ: team Mobile sẽ yêu cầu bên service được chấp nhận tương trợ build được trên iOS/Android, còn team Backend sẽ có được những yêu cầu khác.
• Nên lựa chọn service phù phù hợp với nhiều team, có thể san sớt tài nguyên để tối ưu ngân sách hơn.

Khó khăn hoặc thử thách khi triển khai quy trình CI/CD là gì?

Điều đáng vui với anh Giang và team khi triển khai quy trình CI/CD tại Amanotes là hầu như không có khó khăn gì cả. Mỗi team có quyền tự quyết định service tốt nhất và phù thống nhất với team mình nên cũng không có ràng buộc, quá trình đề xuất với cấp trên cũng nhanh chóng và được chấp thuận dễ dàng. Chủ yếu ở khoảng tầm thời kì đầu thì những team phải tốn thời kì test trên nhiều service để lựa chọn ra được “ứng cử viên” xuất sắc nhất.

Ví dụ: Lúc đầu team anh Giang test trên CircleCI và App Center của Microsoft nhưng CircleCI thì khó sử dụng còn App Center thì cấu hình yếu và không có lựa chọn cấu hình, dẫn đến thời kì build lâu. Sau đó team chuyển sang test trên Bitrise và lựa chọn sử dụng lâu dài.

Ngoài ra, anh Giang cũng lưu ý rằng khi anh lần đầu thông tin về việc triển khai quy trình CI/CD, một số thành viên trong team anh cảm thấy lạ lẫm và có phần hơi gò bó. Tuy nhiên, sau khoản thời gian anh diễn giải về các ưu điểm cũng như những lợi ích mà các bạn cũng có thể đạt được khi ứng dụng quy trình CI/CD thì team cũng dần cởi mở hơn và hào hứng với tool mới.

Chẳng hạn: Theo quy trình CI/CD thì kỹ năng code của các bạn sẽ tốt hơn, ứng dụng CI/CD thì đỡ mất thời kì build vì đã có mạng lưới hệ thống tự động hóa…

Tất nhiên khi mọi người đều đồng thuận với việc triển khai quy trình CI/CD thì cả team cũng phải bỏ thêm thời kì tìm tòi, học hỏi, hoàn thiện dần quy trình và học thêm về unit test…

Tiêu chí để lựa chọn service CI/CD tốt nhất?

Theo ông Giang, trước lúc lựa chọn được service CI/CD phù thống nhất thì nên phải cân nhắc dựa trên nhiều yếu tố. Với anh, mức độ ưu tiên của những yếu tố được sắp xếp như sau:

1. Phải đáp ứng được những nhu cầu mình cần.
2. Nếu nhân sự không thật chuyên về CI/CD thì tool mà phía service cung cấp yêu cầu phải dễ sử dụng.
3. Có nhiều lựa chọn cấu hình vì cấu hình có liên quan đến build time – yếu tố quan trọng trong quy trình, build pipeline phải càng nhanh càng tốt.
4. Lựa chọn service càng phổ thông càng tốt vì nhiều người biết phương pháp sử dụng. Chẳng hạn: Circle CI, Bitrise, Gitlab, TeamCity, Github Actions, TravisCI…
5. túi tiền phù phù hợp với ngân sách của tổ chức. (Ở Amanotes, ngân sách sử dụng service CI/CD quan trọng nhưng không phải là yếu tố tiên quyết).

Quy trình thao tác làm việc tiêu biểu theo mô hình CI/CD

Xem Thêm : Lúp bê là gì ? Cấu Tạo, Phân loại và Báo Giá

Anh Giang san sớt rằng một quy trình thao tác làm việc với CI/CD tại Amanotes sẽ gồm 2 workflow chính:

(1) Development

Khi Developer phát triển một tính năng nào đó thì họ sẽ tạo một branch. Sau khoản thời gian làm xong thì sẽ tạo pull request để merge branch này vào development branch tổng. Trong trường hợp pull request được khởi tạo, quy trình CI/CD được thiết lập sẵn sẽ chạy build, chạy test, chạy lint check và report.

(2) Deployment

Khi pull request được merge vào branch thì sẽ thực hiện build sản phẩm, sau đó upload lên Test Flight cho iOS hoặc Fire App Distribution cho Android. Khi quy trình upload thành công, sẽ có được thông tin hiển thị qua Slack để các bạn QC biết và lên TestFlight tải về, tiếp tục thực hiện manual test.

Có nên test tool CI/CD trên dự án nhỏ?

Nhận định về ý kiến “Cần phải test thử tool CI tiềm năng trong một dự án nhỏ trước lúc quyết định sử dụng và đưa vào toàn bộ mạng lưới hệ thống”, anh Giang nhận định rằng anh hoàn toàn tán đồng với việc nên test trên một (hoặc thậm chí còn nhiều) dự án để chọn được tool và service phù hợp cho dự án. Tuy nhiên, việc dựa trên kết quả test từ dự án nhỏ để ứng dụng cho toàn bộ tổ chức thì chưa phù hợp lý lắm vì độ phức tạp và yêu cầu của từng dự án khác nhau. Mặc dù vậy, tính nhanh chóng và kinh nghiệm test trên dự án nhỏ vẫn là vấn đề cộng giúp đẩy nhanh tiến độ và hạn chế sơ sót khi triển khai trên các dự án to ra nhiều thêm.

Anh Giang gợi ý nên chia theo team để test các tool và service CI/CD (ví dụ: team Mobile, team NodeJS, team Java…). Theo ông, việc phân chia testing từng team dựa trên tiếng nói lập trình sẽ khả thi và ít xẩy ra lỗi hơn so với việc chỉ dựa vào quy mô dự án để quyết định.

Anh Giang cùng các đồng nghiệp tại Amanotes

Tài liệu CI/CD tham khảo

Anh Giang đã cho chúng ta thấy các bên service CI/CD sẽ cung cấp tài liệu, kèm hướng dẫn đầy đủ, chi tiết cụ thể về các thao tác sử dụng liên quan nên trong quá trình tham khảo để lựa chọn service phù hợp cho tổ chức, bạn cũng có thể tham khảo trước để sở hữu thêm nhận định. Anh đánh giá và nhận định cao tài liệu được chuẩn bị sẵn sàng bởi Bitrise (service CI/CD mà Amanotes đang sử dụng) bởi UI UX thân thiện và dễ sử dụng. Ngoài ra, anh cũng gợi ý thêm một số tài liệu từ các service uy tín ngay phía bên dưới:

• https://devcenter.bitrise.io/
• https://circleci.com/docs/migrating-from-buildkite
• https://docs.gitlab.com/ee/ci/

tin tức về anh Nguyễn Trường Giang

Anh Giang đã có hơn 10 năm kinh nghiệm trong ngành phát triển ứng dụng Mobile (Mobile development) và ngày nay đang giữ vị trí Mobile Tech Lead tại Amanotes Tính từ lúc năm 2020. Trước đó, anh cũng từng gắn bó với nhiều tập đoàn như TIKI, Umbala, eSoftHead ở nhiều cương vị như Android Lead, Senior Android Developer…

Tính đến nay anh đã thao tác làm việc theo quy trình CI/CD được hơn 6 năm. Vốn hiểu biết phong phú cùng những trải nghiệm thực chiến qua thời kì đã đúc rút nên những san sớt trong nội dung bài viết.

Bạn thấy nội dung bài viết hay và cấp thiết với nhiều người? Đừng ngại nhấn nút Share phía bên dưới nhé.

Và nhớ là tham khảo việc làm IT trên ITviec!