Một bạn dev mới vào nghề nhắn tin hỏi về CI/CD lúc tối muộn thứ Sáu. Sếp bảo phải làm gấp, mà bạn ấy chưa hiểu nó là cái gì. Câu hỏi đó không hiếm gặp trong nghề này. Rất nhiều người mới học lập trình nghe cụm CI/CD trong buổi phỏng vấn, gật đầu cho qua, rồi về tra Google lúc nửa đêm. Bài này viết lại đúng như cách vẫn giải thích cho các bạn junior trong đội, không màu mè. Đọc xong, bạn sẽ hình dung được luồng việc thật, không chỉ thuộc lòng định nghĩa.
CI/CD là gì, sao dân code nhắc hoài?
CI là viết tắt của continuous integration, tức tích hợp liên tục. Nói dễ hiểu, đây là cách nhiều lập trình viên cùng gộp code vào một nhánh chung, làm vậy vài lần một ngày thay vì dồn code lại rồi gộp một lần vào cuối tuần. CD thường được hiểu là continuous delivery hoặc continuous deployment, tức triển khai liên tục. Nghĩa là mỗi lần code được duyệt, hệ thống tự động đóng gói và đưa bản cập nhật ra môi trường thực tế, không cần một người ngồi bấm tay từng bước như trước.
Nhìn từ ngoài vào, một pipeline CI/CD cơ bản thường chạy qua ba bước: build, test, rồi deploy. Build là lúc mã nguồn được đóng gói thành bản chạy được. Test là lúc máy tự kiểm tra xem bản đó có lỗi rõ ràng nào không. Deploy là bước đưa bản đã qua kiểm tra lên môi trường thật, thường sẽ qua môi trường thử nghiệm trước, rồi mới tới môi trường khách hàng dùng.
Cái hay nằm ở chỗ lỗi được bắt sớm. Khi code của bạn vừa đẩy lên, một loạt kiểm thử tự động chạy ngay trong vài phút. Có chỗ sai, bạn biết liền, sửa liền, không phải đợi đến lúc khách hàng report bug mới tá hỏa. Có một dự án web bán hàng từng mất nguyên hai ngày để dò ra lỗi giỏ hàng, đơn giản vì lúc đó chưa có bước kiểm thử tự động. Sau khi ráp CI/CD vào, một lỗi tương tự phát sinh lần sau chỉ mất chưa đầy nửa buổi sáng để phát hiện và vá xong.
Sai lầm phổ biến nhất ở người mới ráp CI/CD lần đầu là gộp cả ba bước build, test, deploy vào một khối duy nhất, không có gì tách rõ ràng cả. Khi pipeline báo lỗi, không ai biết lỗi nằm ở bước nào để sửa cho nhanh. Cách khắc phục là luôn tách riêng từng bước, đặt tên rõ ràng. Nhìn vào log là đoán được ngay lỗi rơi ở đâu, khỏi mò mẫm cả buổi.
CI/CD chỉ là một mảnh nhỏ trong bức tranh lớn hơn. Bức tranh đó chính là tư duy DevOps mà người mới học lập trình nên biết sớm mà dân trong nghề hay nhắc tới. Ở đó, việc viết code, kiểm thử và vận hành hệ thống gắn chặt với nhau, không tách rời như kiểu làm cũ. Hiểu được mối liên hệ này, bạn sẽ đỡ bỡ ngỡ hơn nhiều khi bước vào một đội dev thật.
Đội mình đổi khác thế nào từ ngày có quy trình này
Trước khi có CI/CD, gộp code là nỗi ám ảnh với nhiều nhóm. Hai người cùng sửa một file suốt tuần, đến lúc merge thì đụng nhau tá lả, ngồi gỡ conflict cả buổi chiều. Tích hợp liên tục giải quyết đúng chỗ đau đó, bởi code được gộp thường xuyên nên từng khác biệt nhỏ được phát hiện ngay, không dồn thành một mớ rối tinh vào cuối kỳ như trước. Kinh nghiệm rút ra là luôn giữ nhánh chính ở trạng thái chạy được, không ai được đẩy code chưa test lên đó. Ai lỡ vi phạm, cả đội cùng dừng lại giúp sửa ngay, không để lỗi trôi qua ngày hôm sau.
Việc kiểm thử và triển khai cũng được máy làm thay. Không còn cảnh một bạn ngồi copy file lên server bằng tay lúc nửa đêm nữa. Có lần vừa hoàn thành một dự án thiết kế website bán hàng cho khách, khách phát hiện lỗi giỏ hàng ngay lúc đang chốt đơn cao điểm. Nhờ pipeline CI/CD đã dựng sẵn, bản vá được đẩy lên production trước khi khách kịp gọi điện phàn nàn lần hai. Trước đây việc này chắc chắn phải đợi qua hôm sau mới xử lý xong.
Tốc độ ra tính năng mới cũng khác hẳn. Ngày trước, một bản cập nhật lớn có khi cả tháng mới lên được, vì ai cũng sợ làm hỏng chỗ khác. Giờ nhóm dev có thể đẩy vài bản nhỏ mỗi tuần, mỗi bản chỉ sửa đúng một việc, rủi ro thấp hơn hẳn so với gộp một cục to rồi thả ra một lần.
Phần kiểm thử tự động trong CI/CD cũng liên quan mật thiết tới công việc kiểm định chất lượng. Muốn hiểu rõ hơn, bạn xem thêm bài viết về cách phân biệt QA và QC trong một công ty lập trình, hai vai trò này vốn làm việc song song với pipeline. Sai lầm hay gặp nhất ở giai đoạn này là viết pipeline chạy quá lâu, có dự án build xong mất gần nửa tiếng. Khi đó dev sẽ ngại đẩy code thường xuyên, mất luôn cái hay của CI/CD. Cách xử lý là tách nhỏ bước kiểm thử, cho chạy song song thay vì chạy tuần tự, nhờ vậy cả pipeline rút ngắn đáng kể, chỉ còn vài phút mỗi lần chạy.
Mới học lập trình thì nên mó vào đâu trước
Nếu bạn đang mới học lập trình và nghe CI/CD thấy choáng, đừng lo. Thứ tự học không khó, chỉ cần đi đúng bước. Bước đầu tiên và quan trọng nhất là nắm chắc Git, tức công cụ quản lý phiên bản code. Bạn cần hiểu rõ khái niệm nhánh, commit, pull request và merge trước khi động vào bất cứ pipeline nào. Bỏ qua bước này mà nhảy thẳng vào CI/CD thường khiến người mới rối, do không hiểu sao pipeline lại báo lỗi conflict, có sửa cũng không biết sửa đâu.
Một sai lầm dễ gặp là copy nguyên file cấu hình pipeline của người khác trên mạng, dán thẳng vào dự án mình rồi chạy thử, kiểu gì cũng lỗi. Cách này thường lỗi lên lỗi xuống, do mỗi dự án có cấu trúc thư mục và câu lệnh build khác nhau. Cách làm đúng là đọc kỹ từng dòng cấu hình mẫu, hiểu nó đang làm gì, rồi mới chỉnh theo dự án của mình, thay vì bê nguyên xi.
Sau khi quen Git, bạn có thể thử nghịch ngay với vài công cụ CI/CD miễn phí. Đây là vài cái tên khá phổ biến trong cộng đồng lập trình viên Việt Nam:
- GitHub Actions — tích hợp sẵn trong GitHub, phù hợp để tập chạy pipeline đầu tiên vì không cần cài thêm gì.
- GitLab CI/CD — mạnh về cấu hình, hay được các công ty vừa và nhỏ chọn khi cần tự quản lý server.
- Jenkins — ra đời lâu hơn nhưng vẫn phổ biến ở nhiều công ty lớn, đáng học vì cộng đồng hỗ trợ rất rộng.
Học công cụ không khó bằng học tư duy phía sau nó. Bạn nên tự dựng một dự án cá nhân nhỏ, viết vài dòng test đơn giản, rồi cấu hình để mỗi lần đẩy code lên là pipeline tự chạy. Cảm giác thấy pipeline chuyển từ đỏ sang xanh sau khi sửa lỗi, thật sự rất đã. Nó dạy bạn nhiều hơn cả chục bài lý thuyết suông.
Song song đó, việc chọn đúng ngôn ngữ để luyện tay cũng đáng cân nhắc. Có bài tổng hợp một số ngôn ngữ lập trình website đáng học cho người mới, bạn tham khảo trước khi chọn dự án cá nhân đầu tay. Ngôn ngữ nào cũng được, miễn bạn thực hành đều và ráp được pipeline chạy tự động cho nó.
Bước cuối, quan trọng không kém, là tham gia một dự án nhóm dù nhỏ. Có thể là dự án mã nguồn mở, có thể là bài tập nhóm ở lớp. Chỉ khi làm việc chung với người khác, bạn mới thấy hết giá trị của CI/CD, vì lúc đó conflict thật sự xảy ra, lỗi thật sự phát sinh từ code của người khác, không phải tình huống giả định. Một mẹo nhỏ hay dặn các bạn junior là đừng ngại pipeline báo lỗi màu đỏ, hãy xem đó là cơ hội học, không phải sự cố đáng xấu hổ.
Điều muốn bạn nhớ nhất
Suy cho cùng, CI/CD không phải công nghệ cao siêu chỉ dành cho công ty lớn. Đó là thói quen làm việc giúp code an toàn hơn, ra mắt nhanh hơn. Quan trọng nhất, nó giúp cả nhóm ngủ ngon hơn, vì không còn cảnh vá lỗi lúc nửa đêm trước ngày ra mắt. Nếu bạn mới học lập trình, đừng chờ đến lúc đi làm mới đụng tới quy trình này.
Cứ dựng một pipeline be bé cho dự án cá nhân ngay từ bây giờ. Chạy thử vài lần cho quen tay, sai đâu sửa đó. Để lần đầu đi phỏng vấn và nghe câu hỏi về CI/CD, bạn trả lời bằng trải nghiệm thật của chính mình. Đó mới là thứ nhà tuyển dụng muốn nghe, không phải một định nghĩa học thuộc lòng.
