Acceptance Tests On CI Pipeline

Trendyol · 2020 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bài ngắn của một scrum team, viết khi refactor một ứng dụng legacy; phần lớn là cấu hình Docker. Wiki giữ quyết định về nơi chạy kiểm chứng.

Bối cảnh

Team test tính năng theo sprint rồi mới đưa lên production, nhưng việc giao hàng hay trễ vì lỗi do môi trường (môi trường test dùng chung, dependency thật), làm tăng Lead Time (một trong bốn chỉ số của sách Accelerate).
Service có một database Couchbase và hai API bên ngoài; theo Trendyol, càng nhiều dependency ngoài thì càng nhiều kịch bản lỗi phải xử lý.

Thêm tầng component test (acceptance test cho riêng một service) giữa unit test và end-to-end: kiểm hành vi của cả service khi mọi dependency đều bị thay bằng stub.
Dựng môi trường cô lập bằng Docker Compose: image Couchbase tự build sẵn bucket và index (tạo qua API của Couchbase trước khi test chạy), WireMock giả hai API ngoài bằng file cấu hình request/response, service dùng chính image đã có để deploy, cộng một container chạy test. depends_on quy định thứ tự khởi động.
Thêm stage Test vào pipeline GitLab CI: mỗi lần push chạy docker-compose up --build; test hỏng thì pipeline dừng.
Bài nhắc tới cách khác trong cùng công ty: team Search deploy container theo từng feature lên Kubernetes.

Đưa kiểm chứng tích hợp vào môi trường dựng mới mỗi lần, không phụ thuộc trạng thái môi trường chung, để lỗi lộ ra trước khi tới khâu test thủ công cuối sprint.

Một tầng test chạy trên service thật với dependency giả lấp khoảng giữa unit test (quá hẹp) và e2e (phụ thuộc môi trường).
Dữ liệu khởi tạo (bucket, index) phải nằm trong image test, nếu không mỗi lần chạy lại phụ thuộc thao tác tay.
Bài không nêu số liệu Lead Time trước và sau.