Software CI/CD pipeline thường hoạt động theo một logic đơn giản: code thay đổi → build image → deploy. Với ML pipeline, logic này chỉ đúng một phần — vì có thêm một chiều thay đổi quan trọng hơn: model và data. Một model mới có thể được deploy mà không có bất kỳ thay đổi code nào; ngược lại, code thay đổi không phải lúc nào cũng cần retrain model. Đây là lý do áp dụng software CI/CD trực tiếp vào ML thường dẫn đến pipeline hoặc quá chặt (rebuild everything) hoặc quá lỏng (deploy bằng tay).

GitOps cho ML cần tách biệt hai vòng lặp độc lập: code lifecycle (viết bởi engineer, deploy qua git commit) và model lifecycle (tạo ra bởi training pipeline, deploy khi metric pass). Argo CD là công cụ phù hợp để điều phối cả hai — nhưng cần thiết kế manifest và trigger strategy đúng cách ngay từ đầu.

Tại sao software CI/CD không đủ cho ML

Khi team ML dùng pipeline CI/CD thuần software, một số pattern phổ biến gây vấn đề đặc thù cho ML workflow. Nhận ra những pattern này giúp tránh lặp lại chúng:

Model artifact trong Docker image: pack model vào image vừa làm image phình to (vài GB), vừa coupling model lifecycle với code lifecycle. Mỗi lần retrain phải rebuild và repush image — CI pipeline chạy 15–30 phút cho một thay đổi chỉ liên quan đến model weight
Không có model validation gate: pipeline deploy khi test pass — nhưng test thường kiểm tra code logic, không kiểm tra model performance trên test set thực tế. Model có thể được deploy dù accuracy giảm nếu không có evaluation step trong pipeline
Rollback bằng git revert: với software, rollback = revert code commit. Với ML, rollback thường cần revert về model version cũ — hai thứ này độc lập và rollback code không tự động rollback model
Feature store và training data không được version: model mới train trên data mới có thể kém hơn model cũ train trên data cũ — nhưng nếu data không được version cùng với model artifact, không thể reproduce kết quả cũ để debug

ML CI/CD cần ít nhất hai pipeline riêng biệt: training pipeline (data → model artifact, trigger theo lịch hoặc khi data mới) và deployment pipeline (model artifact → production, trigger khi model mới pass evaluation). Hai pipeline này giao tiếp qua model registry, không phải git branch.

Tách model artifact khỏi deployment pipeline

Nguyên tắc quan trọng nhất trong ML GitOps: model artifact không đi qua git và không ở trong Docker image. Model artifact sống trong model registry (MLflow, hoặc object storage với metadata DB) và được reference bằng version ID trong Kubernetes manifest:

Deployment manifest chỉ chứa model version reference: `model_name: product-recommendation`, `model_version: v2.3` — không chứa path hay checksum của file weight. Init container trong Pod spec pull model từ registry về emptyDir khi Pod khởi động
Model registry là source of truth cho model lifecycle: training pipeline đăng ký model mới vào registry cùng với metrics (accuracy, F1, latency benchmark). Deployment pipeline chỉ promote model version từ `staging` sang `production` khi metrics pass threshold
Image build chỉ trigger khi serving code thay đổi: serving code (FastAPI handler, preprocessing logic, postprocessing) sống trong git. Khi code thay đổi → rebuild image → deploy. Khi chỉ model thay đổi → update model version trong manifest → Argo CD sync → Pod restart với model mới, không rebuild image

Argo CD cho multi-environment deployment

Argo CD quản lý Kubernetes manifest theo mô hình GitOps: trạng thái mong muốn của cluster được lưu trong git repo, Argo CD liên tục sync cluster về trạng thái đó. Thiết kế cho ML có một số điểm cần lưu ý:

App-of-apps pattern: một Argo CD Application root quản lý nhiều Application con — một cho mỗi model service (recommendation, fraud-detection, churn-prediction). Khi thêm model service mới, chỉ cần thêm một Application vào root thay vì config Argo CD từ đầu
Environment promotion qua git: staging và production là hai git branch hoặc hai thư mục trong repo manifest. Promote từ staging sang production = merge PR từ staging branch sang production branch → Argo CD tự sync. Không dùng manual kubectl apply trong production
Sync policy: với production, dùng `manual` sync (không auto-sync) để deployment cần review trước. Với staging, dùng `automated` sync với `prune: true` để staging luôn phản ánh commit mới nhất. Đặt `selfHeal: true` để Argo CD rollback nếu có ai thay đổi cluster ngoài git
Health check cho ML service: Argo CD kiểm tra `Deployment.status.availableReplicas` để xác định sync thành công. Với ML model serving, cần thêm custom health check: gọi `/health` endpoint kiểm tra model đã load xong chưa — Pod `Running` không có nghĩa là model đã sẵn sàng serve

Training pipeline và trigger strategy

Training pipeline chạy độc lập với deployment pipeline và không trigger bởi git commit. Hai trigger strategy phổ biến:

Scheduled trigger: train lại model theo lịch cố định (hàng tuần, hàng tháng) với data mới nhất từ data warehouse. Phù hợp với model ít nhạy cảm với data drift, training cost cao. Dùng Airflow DAG hoặc Argo Workflows để orchestrate training steps
Event-based trigger: training pipeline trigger khi phát hiện data drift vượt ngưỡng (từ monitoring pipeline — xem bài về drift monitoring), hoặc khi lượng data mới tích lũy đủ ngưỡng. Phù hợp hơn cho model cần adapt nhanh với thay đổi của thế giới
Sau khi training xong: pipeline tự động chạy evaluation trên held-out test set, đăng ký model và metrics vào registry. Nếu metrics pass threshold — tự động tạo PR vào staging branch của manifest repo để deploy. Nếu fail — alert và dừng pipeline, không deploy model kém hơn model cũ

Rollback và progressive delivery

Rollback trong ML GitOps cần xử lý hai chiều độc lập: rollback code (revert git commit, Argo CD sync) và rollback model (update manifest về model version cũ hơn trong registry). Kết hợp với progressive delivery để giảm risk:

Canary deployment: route 5–10% traffic sang model version mới trong vài tiếng đầu. So sánh business metric (CTR, conversion, error rate) giữa canary và stable. Nếu metric của canary tốt hơn hoặc bằng → promote toàn bộ. Nếu kém hơn → rollback về stable version tự động. Argo Rollouts hoặc Flagger tích hợp với Argo CD để tự động hóa logic này
Rollback tự động theo metric: định nghĩa `AnalysisTemplate` trong Argo Rollouts với threshold (error rate không vượt 2%, P99 latency không quá 500ms trong 15 phút đầu sau deploy). Nếu vi phạm, Argo Rollouts tự động rollback mà không cần human intervention

Kết luận

GitOps cho ML không phải là áp dụng lại software CI/CD với một bước training thêm vào — mà là thiết kế lại hai lifecycle độc lập (code và model) với điểm giao tiếp rõ ràng qua model registry. Argo CD làm tốt phần deployment orchestration và rollback, nhưng cần training pipeline và evaluation gate hoạt động đúng để vòng lặp khép lại. Trong lớp Development của KonexForge, GitOps là nguyên tắc vận hành mặc định cho mọi Pilot Build — không phải tùy chọn thêm sau.

GitOps và CI/CD cho ML pipeline: từ notebook experiment đến production deployment với Argo CD