GitLab's unconventional journey to CI/CD and Kubernetes

Bài tóm tắt GitLab 2019 3. Quy mô lớn Độ khó: Dễ

GitLab · 2019 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bối cảnh

  • Release theo tháng:

    • feature freeze từ ngày 7, release ngày 22;
    • dev "panic merge" sát hạn, còn bản sửa lỗi gấp phải chờ.
  • Release manager (luân phiên giữa các dev) làm tay:

    • đồng bộ nhiều repo;
    • tạo branch, gắn version;
    • deploy lên GitLab.com rồi publish package cho bản self-managed.

    Mỗi lần mất từ nửa ngày tới vài ngày.

  • Khảo sát 2018: trong 14 ngày trước release, team Delivery dành 60% thời gian trông deploy và 26% làm việc release thủ công.

Thay đổi chính

  • Lập team Delivery với hai nhiệm vụ: chuyển GitLab.com sang continuous delivery, và sau đó migrate lên Kubernetes.
  • Con đường "khác thường": không đổi nền tảng trước. Họ dùng công cụ đang có (CI của chính GitLab) để tự động hoá và "stress test" hệ thống tĩnh cũ, rồi mới tiến sang hệ động.
  • Quy trình CD:
    1. CI đọc label trên MR đã merge, tự sync repo, tạo branch/tag/version;
    2. deploy tự động lên môi trường non-prod, chạy QA tự động;
    3. rollout cho một nhóm nhỏ user production, song song dev kiểm tra tay;
    4. lỗi nặng thì dừng deploy; ổn thì Delivery mở cho mọi user;
    5. bản self-managed cắt từ deployment tốt gần nhất trên GitLab.com.
  • 90% quy trình release được tự động hoá; 10% còn lại là phối hợp giữa các bên.
  • Thay đổi văn hoá:
    • "done" giờ nghĩa là đã chạy đúng trên production chứ không chỉ qua review;
    • dev trực on-call;
    • review app trên Kubernetes, feature flag.

Kết quả

  • Khảo sát 2019: 82% thời gian của team được giải phóng.
  • Số deploy tăng từ khoảng 7 (5/2019) lên 35 (8/2019), đều trên hệ thống "cũ".
  • Registry là service đầu tiên chạy hẳn trên Kubernetes.

Vì sao (theo GitLab)

Theo trưởng team Delivery, "chờ chuyển sang nền tảng mới mới là kẻ thù": hầu hết hệ thống đều sửa được để quay vòng nhanh hơn. Tốc độ release tăng lại mua thêm thời gian cho migration.

Bài học cho SWE

  • Đổi quy trình trước, đổi nền tảng sau: CD trên hạ tầng cũ phơi ra điểm yếu và đổi thói quen của dev, nên Kubernetes migration ít rủi ro hơn.
  • Release theo lịch kèm freeze tạo hành vi dồn cục; deploy nhỏ và thường xuyên giảm áp lực.
  • Rollout cho nhóm nhỏ user và có điểm dừng là khung chung với GitHub, Monzo (Deploy và release an toàn).

Liên quan