Automating Code Migrations at Scale
Bài tóm tắt Allegro 2024 3. Quy mô lớn Độ khó: Dễ
Allegro · 2024 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc
Bối cảnh
- Allegro có hơn 2.000 service (mỗi cái một repo). Khi thư viện nội bộ dùng chung (ví dụ Spring Boot starter của Allegro) ra bản có breaking change, mỗi team phải đọc hướng dẫn migrate rồi sửa tay: tốn thời gian, dễ sai, đổ nhiều câu hỏi vào kênh hỗ trợ.
Thay đổi chính
- Ghép công cụ có sẵn: Dependabot (mở PR nâng version) + một GitHub App nội bộ
@allegro-rewritechạy OpenRewrite (công cụ biến đổi code theo "recipe"). - Luồng: Dependabot mở PR nâng major version → app nhận webhook → comment báo đang migrate tự động → workflow clone repo, chạy các recipe ứng với breaking change → commit (ký bởi app) vào chính nhánh của Dependabot → build xanh thì approve.
- Mục tiêu đặt ra: giảm việc tay trên hàng nghìn repo; không bắt developer học công cụ mới; mọi migration audit được và đảo ngược được; có quy trình hạn chót; chạy lại được; tự động khoảng 90% là đủ, không cố hoàn hảo.
- Mở rộng: lệnh qua comment PR (giống lệnh
@dependabot), bản CLI phân phối qua brew tap nội bộ, recipe dùng được cả ngoài luồng Dependabot. - Migration có hạn chót: ví dụ lỗ hổng bảo mật trong thư viện dùng khắp nơi; tới hạn thì force-merge các PR migrate đã build thành công. Theo Allegro, không lấy trách nhiệm của người giữ repo nhưng biết họ khó ưu tiên migrate.
Khó khăn (theo Allegro)
- Niềm tin: một lần thử gỡ cấu hình G1GC thừa (đã mặc định từ JDK 9) trên toàn bộ YAML deploy gặp khó vì quá nhiều cách khai báo; nhiều PR tự động chồng nhau, giải thích kém làm người ta mất tin vào tự động hoá.
- Trường hợp biên: annotation Groovy bị bỏ qua, parse Kotlin không nhất quán, định dạng YAML vỡ. Xoá một property trong YAML mà giữ nguyên định dạng cũng cần mẹo.
- Thêm việc cho người giữ thư viện: phải học OpenRewrite, viết và test recipe; có lần phải viết lại cả recipe; release thư viện bị lùi lại. Theo Allegro, đổi lại họ hiểu rõ người khác dùng thư viện thế nào, và việc này hợp với mô hình sở hữu: ai gây breaking change thì viết cách sửa.
Bài học cho SWE
- Chuyển chi phí migrate từ N team dùng sang một team gây ra thay đổi: tổng chi phí giảm khi N lớn (Nền tảng nội bộ cho service (đường ray chung)).
- Gắn việc migrate vào luồng có sẵn (PR của Dependabot) thay vì bắt người dùng đến một công cụ mới.
- Tự động 90% kèm PR review được và đảo ngược được tốt hơn chờ công cụ hoàn hảo; hạn chót + force-merge là đuôi của danh sách ngoại lệ co dần (Migration không downtime).
- Tự động hoá mất niềm tin rất nhanh khi PR khó hiểu hoặc chồng chất; giải thích trong PR là một phần của sản phẩm.
Liên quan
Nền tảng nội bộ cho service (đường ray chung)Migration không downtimeQuản lý fleet và migrate code hàng loạt
Được nhắc tới trong
Chủ đề (3)
Công ty (1)