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, kết hợp tự động 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.
Để hiểu 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 bối cảnh thực tế, ITviec đã có buổi chia sẻ thú vị với các thông tin đầy bổ ích cùng anh Nguyễn Trường Giang – Mobile Tech Lead tại Amanotes qua bài viết sau đây.
Tham khảo Việc làm CI CD trên ITviec
Tham khảo Việc làm Amanotes trên ITviec
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 trong quy trình phát triển phần mềm và chuyển giao 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 được chuyển đến người dùng trong thời gian ngắn nhất.
Hiện nay, CI/CD đã được áp dụng rộng rãi vào quy trình làm việc của các doanh nghiệp làm trong lĩnh vực 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:
- Developer commit code (đẩy code lên server).
- Quy trình CI/CD sẽ tự động chạy build, chạy test và deploy sản phẩm.
- 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 áp dụng CI/CD là gì?
Với một quy trình phát triển phần mềm, tất cả các bước làm việc của Developer có phần thủ công và mất khá nhiều thời gian. Anh Giang đưa ra ví dụ:
Developer sau khi code xong thì sẽ build trực tiếp trên máy tính/laptop cá nhân, sau đó chờ code được build hoàn tất. Tiếp theo đó, 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 khi kết thúc. File được upload xong hết thì Developer mới thông báo đến team Tester/QA QC và lúc này, team mới bắt đầu thực hiện công tác kiểm thử cho toàn bộ sản phẩm.
Nếu xảy ra sai sót thì quy trình gần như sẽ quay lại từ đầu, thời gian chờ giữa 2 bên Developer và Tester/QA QC tương đối dài, khiến cho dự án cũng bị trì hoãn theo. Đó là chưa kể đế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 chạy trên ứng dụng, mà chỉ khi deploy mới phát hiện ra.
Áp 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 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ụ (tool) CI/CD. Nếu có thể kết 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ũ).
Cách thức hoạt động của CI/CD
Theo anh Giang chia sẻ thì trong quy trình CI/CD tại Amanotes sẽ 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 báo đến CI/CD tool là có thay đổi như thế. Phản hồi với thông báo, phía CI/CD sẽ tự động thực hiện các thao tác đã được cài đặt trước đó cho hành động pull request.
Sau khi thực hiện tất cả các lệnh đã được cài đặt kể trên thì CI/CD sẽ cập nhật kết quả ngược 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 (bao gồm testing) phía CI/CD hay không.
Theo đó, khi review code, Reviewer chỉ cần 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, đã 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 gian để review code thủ công nhằm đảm bảo sự phù hợp với tiêu chuẩn của cả team, và vì thực tế vẫn có một số lỗi mà quá trình tự động (automation) vẫn chưa cover hết được.
Việc làm IT Developer tại TP.HCM trên ITviec
Việc làm IT Developer tại Hà Nội trên ITviec
Ưu điểm và nhược điểm của CI/CD là gì?
Theo trải nghiệm của bản thân, anh Giang chia sẻ một số ưu điểm mà quy trình CI/CD mang lại cho Developer bao gồm:
- Tránh được những lỗi không đáng có: chẳng hạn 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 build sản phẩm. Ví dụ: khi làm thủ công, cùng 1 source code nhưng sẽ có sự khác biệt khi bạn 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 gây ả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 cao nên Developer không cần phải thực hiện việc build và deploy phần mềm/ứng dụng trên máy cá nhân nữa.
- Nâng cao chất lượng code thông qua quy trình, Developer có thể cài đặt những ràng buộc ngay từ đầu. Ví dụ: pull request khi được tạo ra thì không được quá lớn, không được vượt quá X thay đổi…, điều này góp phần giúp chất lượng 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 cài đặt trong quy trình CI/CD. Nghĩa là khi 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à 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 gian 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 để áp 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ó thời điểm 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 tất, sau đó thực hiện update (cập nhật) lại source code (trong trường hợp có thông báo conflict từ 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 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 áp dụng CI/CD cũng bị ả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 áp 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. Quan điểm của anh là khi có quy trình tốt thì chất lượng công việc của Developer cũng tối ưu hơn. Kể cả khi thực hiện dự án theo cá nhân 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 đủ khả năng 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 sao để đả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 đủ kiến thức chuyên môn để xử lý thì sẽ mất rất nhiều thời gian, gây ra nhiều gián đoạn không cần thiết.
CI/CD và Agile có mối liên hệ ra sao?
Theo anh Giang thì CI/CD giống như một quy trình bổ sung, giúp 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), giúp 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?
- Không bắt buộc toàn bộ các team trong tổ chức áp dụng quy trình CI/CD, nếu thấy team nào phù hợp thì có thể triển khai đầu tiên.
- Nên bắt đầu càng sớm càng tốt (lúc team ít người hoặc lúc mới bắt đầu 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 chọn ra được service phù hợp nhất vì sẽ 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 cho phép hỗ trợ build được trên iOS/Android, còn team Backend sẽ có những yêu cầu khác.
- Nên lựa chọn service phù hợp với nhiều team, có thể chia sẻ tài nguyên để tối ưu chi phí hơn.
Khó khăn hoặc thách thức khi triển khai quy trình CI/CD là gì?
Điều đáng mừng 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ù hợp 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 thời gian đầu thì các team phải tốn thời gian test trên nhiều service để 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 gian 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 báo 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 không quen và có phần hơi gò bó. Tuy nhiên, sau khi 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ó thể đạt được khi áp 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 bạn sẽ tốt hơn, áp dụng CI/CD thì đỡ mất thời gian build vì đã có hệ thống tự động…
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 gian 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 anh Giang, trước khi lựa chọn được service CI/CD phù hợp nhất thì cầ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 các yếu tố được sắp xếp như sau:
- Phải đáp ứng được những nhu cầu mình cần.
- Nếu nhân sự không quá chuyên về CI/CD thì tool mà phía service cung cấp yêu cầu phải dễ sử dụng.
- 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.
- Lựa chọn service càng phổ biến càng tốt vì nhiều người biết cách sử dụng. Chẳng hạn: Circle CI, Bitrise, Gitlab, TeamCity, Github Actions, TravisCI…
- Chi phí phù hợp với ngân sách của tổ chức. (Ở Amanotes, chi phí 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 làm việc điển hình theo mô hình CI/CD
Anh Giang chia sẻ rằng một quy trình 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 khi 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ó thông báo 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ề quan điểm “Bắt buộc phải test thử tool CI tiềm năng trong một dự án nhỏ trước khi quyết định sử dụng và đưa vào toàn bộ hệ thống”, anh Giang cho rằng anh hoàn toàn đồng tình với việc nên test trên một (hoặc thậm chí 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ỏ để áp dụng cho toàn bộ tổ chức thì chưa 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à điểm cộng giúp đẩy nhanh tiến độ và hạn chế sai sót khi triển khai trên các dự án lớn hơn.
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 anh, việc phân chia testing từng team dựa trên ngôn ngữ 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 biết 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 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ó thể tham khảo trước để có thêm nhận định. Anh đánh giá cao tài liệu được chuẩn bị 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 bên dưới:
- https://devcenter.bitrise.io/
- https://circleci.com/docs/migrating-from-buildkite
- https://docs.gitlab.com/ee/ci/
Thông tin về anh Nguyễn Trường Giang
Anh Giang đã có hơn 10 năm kinh nghiệm trong lĩnh vực phát triển ứng dụng Mobile (Mobile development) và hiện tại đang giữ vị trí Mobile Tech Lead tại Amanotes kể từ năm 2020. Trước đó, anh cũng từng gắn bó với nhiều công ty lớn như TIKI, Umbala, eSoftHead ở nhiều cương vị như Android Lead, Senior Android Developer…
Tính đến nay anh đã 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 gian đã đúc kết nên những chia sẻ trong bài viết.
Bạn thấy bài viết hay và cần thiết với nhiều người? Đừng ngại nhấn nút Share bên dưới nhé.
Và đừng quên tham khảo việc làm CI CD trên ITviec!