Hola, I’m Hieu, a Software Engineer

Kho mã Flutter nào rồi cũng mọc ra một file .github/workflows/ci.yml chứa flutter test . Nó pass, mọi người thấy yên tâm, rồi một bản build phát hành hỏng trên máy build vì lý do mà không laptop nào có thể lộ ra. CI đáng đồng tiền khi nó bắt được những lỗi mà môi trường phát triển cục bộ về mặt cấu trúc không thể bắt: mã sinh cũ, một phụ thuộc chỉ resolve được nhờ pub cache trên máy bạn, một thay đổi định dạng chưa ai chạy, một golden đã trôi. Đây là pipeline dựng quanh những thứ đó. Hình dạng tổng thể Bốn job, chia hai đợt: Job Chạy khi Bắt được analyze mọi push và PR lệch định dạng, hồi quy lint, mã không dùng test mọi push và PR lỗi unit, widget và golden build PR vào main và tag lỗi biên dịch chỉ xảy ra trên máy sạch release chỉ tag ký, tải artifact lên analyze và test chạy song song và nhanh. build chậm nên bị chặn cổng. Sự phân chia đó quan trọng: một pipeline mà mỗi lần push đều phải chờ tám phút build Android là pipeline mà người ta sẽ học...

Every Flutter repository eventually grows a .github/workflows/ci.yml containing flutter test . It passes, everyone feels covered, and then a release build fails on the build machine for a reason nobody’s laptop could have surfaced. CI earns its keep by catching the failures that local development structurally cannot: stale generated code, a dependency that only resolves because of your local pub cache, a formatting change nobody ran, a golden that drifted. This is a pipeline built around those. The shape of it Four jobs, in two waves: Job Runs Catches analyze every push and PR format drift, lint regressions, unused code test every push and PR unit, widget, and golden failures build PRs to main and tags compile failures that only occur on a clean machine release tags only signing, artifact upload analyze and test run in parallel and are fast. build is slow and gated. That split matters: a pipeline where every push waits eight minutes for an Android...

Every Flutter repository eventually grows a .github/workflows/ci.yml containing flutter test . It passes, everyone feels covered, and then a release build fails on the build machine for a reason nobody’s laptop could have surfaced. CI earns its keep by catching the failures that local development structurally cannot: stale generated code, a dependency that only resolves because of your local pub cache, a formatting change nobody ran, a golden that drifted. This is a pipeline built around those. The shape of it Four jobs, in two waves: Job Runs Catches analyze every push and PR format drift, lint regressions, unused code test every push and PR unit, widget, and golden failures build PRs to main and tags compile failures that only occur on a clean machine release tags only signing, artifact upload analyze and test run in parallel and are fast. build is slow and gated. That split matters: a pipeline where every push waits eight minutes for an Android...

Kịch bản hỏng lúc nào cũng giống nhau. Thứ Hai có người cắm một con AI reviewer vào CI. Nó để lại ba mươi comment trên pull request đầu tiên: hai mươi bảy cái là đặt tên biến, “cân nhắc tách đoạn này ra helper”, và một gợi ý thêm test mà cái test đó đã nằm sẵn ở file cách đó hai bậc. Ba cái là thật, và một trong ba là bug mất dữ liệu thật sự nằm trong nhánh retry. Không ai thấy ba cái đó. Đến thứ Tư mọi người lướt qua phần review của bot để xuống phần review của người. Đến thứ Hai tuần sau nó thành một check không chặn merge với thông báo đã tắt — một tích hợp chết nhưng vẫn đốt token mỗi lần push. Con bot không dở trong việc tìm bug. Nó tìm ra bug rồi. Nó dở ở chỗ không biết im lặng , mà trong code review thì đó chính là toàn bộ công việc. Ngân sách của một reviewer không phải là compute, mà là mức độ sẵn lòng đọc tiếp của đồng đội — và niềm tin đó cập nhật rất nhanh. Nếu trong mười comment đầu tiên một developer đọc chỉ có một cái hữu ích, họ đã học được một quy tắc — lướt qua thôi...