CICD viết tắt của Continuous Integration Continuous Delivery là một quy trình hỗ trợ cho việc phát triển phần mềm. Hiện nay CICD đang được nhắc tới như là một chủ đề khá hot trong chủ đề cải thiên chất lượng phát triển phần mềm. Nhưng nhìn lại bản chất sự việc, có phải CICD là một quy chuẩn vàng bắt buộc phải hướng tới ? Có những ưu khuyết điểm gì bạn phải đối mặt khi cân nhắc áp dụng CICD ?
1. CICD là gì ?
Vì thế cần phải có sự tích hợp liên tục, nghĩa là ngay khi lâp trình viên commit source code lên Git hoặc SVN, thì các tác vụ tự động tích hợp (integratiọn) lập tức được trigger (kích hoạt), thực hiện biên dịch và chạy test tích hợp các module lại với nhau. Nếu có lỗi (biên dịch hay logic) trong đoạn code vừa được đẩy lên thì dự án sẽ được thông báo ngay, để thực hiện việc fix lỗi càng nhanh càng tốt. Điều này hướng đến mục tiêu là các lỗi được fix ngay khi được phát hiện, hướng tới việc Delivery - hay triển khai trên môi trường Production được diễn ra suôn sẻ nhất có thể.
Khái niệm CD là bước tiếp theo sau quá trình CI. au khi Test tích hợp mọi thứ suôn sẻ trên môi trường development thì bước tiếp theo chính là Delivery cho khách hàng - hay deploy sản phẩm lên Server.
Tóm lại , CICD là việ tự động hoá các quy trình kiểm tra Tích hợp các Module, tự động triển khai phần mềm.
2. CICD có cần thiết ?
Thoạt nghe qua, nếu chúng ta có thể tự động hoá những quy trình nói trên thì công sức thủ công của lập trình viên sẽ được giảm đi rất nhiều cho những việc lặp đi lặp lại có thể gây nhàm chán thậm chí là nhầm lẫn trong quá trình thao tác, thì thật là tuyệt vời. Tuy nhiên mọi thứ có đúng như vậy. Chúng ta sẽ lần lượt xem xét những khía cạnh sau:
2.1 Tự động hoá có thật sự cần thiết với công việc của bạn ?
Nghe qua điều này thì có vẻ giống những người bảo thủ không thích với những xuất hay cải tiến mới. Nhưng với góc nhìn là ngưởi có kinh nghiệm với những dự án đã được triển khai CICD, người viết xin được nêu 5 điểm sau - có thể xem như 1 check list, để cân nhắc trước khi áp dụng CICD vào dự án:
- Công việc kiểm tra có phải thực hiện thường xuyên không ? Bao nhiêu lần 1 ngày, 1 tuần ?
- Những ai đang thực hiện tích hợp và kiểm tra lỗi (thường là Dev và Tester), nếu áp dụng CICD thì có khó khăn gì cho những người này không ?
- Nếu áp dụng CICD, khi xảy ra lỗi thì quy trình sửa lỗi như thế nào ? Có làm gián đoạn công việc của team hay ảnh hưởng ?
- Nếu dùng CICD thì tiết kiệm được bao nhiêu thời gian ?
- Những cải thiện thực tế là gì nếu áp dụng CICD vào dự án ? Và câu hỏi ngược lại, nếu vẫn làm bằng tay thì có ảnh hưởng gì về mặt thời gian hay tinh thần của thành viên dự án hay không ... ?
3. Một số phát biểu (câu hỏi) trong thực tế khi bắt đầu áp dụng CICID:
Dưới đây, người viết sẽ tổng hợp và nêu lại những câu hỏi cũng như là những trải nghiệm của một số lập trình viên hoăc là quản lý dự án, những người đã từng thực hiện áp dụng CICD vào trong dự án. Mời các bạn hãy đọc qua truớc khi có câu trả lời cho chính mình và dự án.
- Khi phát hiện xảy ra lỗi tích hợp thì tất cả thành viên dự án phải sửa cho bằng được lỗi đó trước khi quay lại công việc ?
Chỉ việc phải analyze lỗi đó để đưa ra quyết định có fix hay không cũng đã tốn một khoảng thời gian, vậy nếu trong ngày xảy ra vài lần như thế thì không những mất thời gian mà công việc lại bị gián đoạn. Vậy nên việc xây dựng quy trình phân loại lỗi cũng phải được tiến hành song song để đưa ra một chuẩn chung cho tất cả thành viên dự án có thể follow dễ dàng, tránh công việc bị gián đoạn.
3.1 Vấn đề Resource (Nhân sự, chi phí) có thích hợp để làm CICD ?
Cần chú ý rằng: để triển khai được CICD dự án sẽ cần một hay nhiều thành viên có khả năng làm devops, hiểu cấu trúc và cách sử dụng các hệ điểu hành khác nhau (Windows, các phiên bản Linux khác nhau), vững về Network, biết sử dụng nhiều công cụ, ... Có thể tận dụng được developer trong dự án không ? Hay phải tuyển thêm từ bên ngoài ?
Một phương diện nữa của CICD là quá trình Automation Test, hay nói đúng hơn là Integration Test. Ví dụ rằng: Dự án hiện tại không có người nào có kinh nghiệm làm automation testing hay đơn gỉan là tuyển mãi mà không được, các công đoạn kiểm tra sau cùng vẫn phải thực hiện bằng manual (thủ công).
3.2 Nghiệp vụ Hệ thống của dự án có quá phức tạp ?
Có những dự án đặc thù nặng về business, đặc biệt là các Hệ thống về Quản lý Nhân sự, Tài chính, Ngân hàng, ... Và những Hệ Thống này rất phổ biến trong thực tế, và việc xây dựng tự động hoá không đơn thuần là việc chỉ nhập con số vào các ô và chờ kết quả mà người thực hiện test phải có kiến thức về nghiệp vụ của Doanh nghiệp về những mốc thời gian khác nhau trong năm hay đối với những loại hợp đồng khác nhau tương ứng với những loại khách hàng khác nhau, ... Và cũng chính những lập trình viên trực tiếp phát triển Hệ thống đó cũng không thể nhớ hết được toàn bộ chức năng tổng quan mà hầu như chỉ nhớ và làm việc tốt nhất trên những module họ đã và đang làm. Qua đó ta có thể thấy rằng, việc tự động hóa không phải lúc nào cũng có thể áp dụng dễ dàng,
Từ đó có thể thấy rằng việc xây dựng một bộ chuẩn tự động hoá kiểm tra những chức năng cho các quy trình này có chi phí cũng không thua kém gì việc phát triển, việc gì sẽ xảy ra nếu như bộ tự động kiểm tra cũng bị bug ? Nếu như chức năng bị lỗi mà kiểm tra lại không có lỗi ? Lúc đó thời gian và công sức lại hao tốn nhiều hơn cho việc fix bug của bộ tự động hoá, nghĩa là chúng ta phải kiểm tra và fix bug của chức năng hệ thống và thêm cho bộ kiểm tra nữa. Vậy có nên áp dụng ?
3. Lời kết:
Áp dụng tự động hoá hay không áp dụng phụ thuộc vào rất nhiều yếu tố của dự án: chi phí, con ngừoi, đặc thù của dự án. Điều này đòi hỏi người quản lý dự án, là leader hay là PM, Scrum Master, ... phải có cách nhìn và sự đánh giá toàn diện cho trên toàn bộ khía cạnh của dự án. Không nên chạy theo xu hướng mà thiếu đi sự nhìn nhận và đánh giá.
Chúc các bạn thành công.
AutoCode. VN