𝟯 Bước Kiểm Tra Sau Khi Triển Khai Tôi Thực Hiện Sau Khi Cloudflare Pages Build Xong
Tôi đã mất hai tuần để gỡ lỗi các vấn đề trên môi trường production.
Một quy tắc chuyển hướng (redirect) sitemap đã chặn các tệp sitemap của tôi. Việc tải lên hình ảnh bị lỗi do độ trễ khi triển khai. Những sai lầm này đã làm tiêu tốn rất nhiều thời gian.
Giờ đây, tôi sử dụng ba bước kiểm tra cụ thể sau mỗi lần triển khai Cloudflare Pages. Tôi không sử dụng một bộ kiểm thử (test suite) đầy đủ. Tôi sử dụng ba bước kiểm tra nhanh này để bắt được những lỗi mà tôi thực sự gặp phải.
Tôi thực hiện các bước này trên ba trang web được xây dựng bằng Astro 5 SSG.
- Xác minh Sitemap
Tôi kiểm tra xem sitemap-index.xml có trả về mã trạng thái (status code) 200 trên tất cả các tên miền hay không. Tôi cũng kiểm tra cả sitemap-0.xml.
Tôi xác minh rằng số lượng URL đáp ứng một ngưỡng tối thiểu. Ví dụ, aiappdex.com phải có ít nhất 1.000 URL. Nếu số lượng giảm xuống, nghĩa là đường ống dữ liệu (data pipeline) của tôi đã gặp lỗi.
Tôi sử dụng curl mà không đi theo các lệnh chuyển hướng (without following redirects). Điều này giúp tôi phát hiện các quy tắc chuyển hướng bị lỗi vốn thường che giấu lỗi đối với trình duyệt.
- Gửi dữ liệu qua IndexNow
Sau khi kiểm tra sitemap, tôi chạy một tập lệnh (script) để gửi các URL đến IndexNow cho Bing, Yandex, Naver và Seznam.
Tập lệnh này sẽ đọc sitemap đang hoạt động và gửi các URL lên. Nếu IndexNow trả về lỗi 403, điều đó có nghĩa là tệp xác minh khóa (key verification file) của tôi bị thiếu hoặc quy tắc chuyển hướng bị lỗi.
Tôi chạy việc này một cách thủ công sau khi triển khai. Điều này đảm bảo tôi gửi các URL đang hoạt động và ổn định.
- Theo dõi hiệu suất Lighthouse
Tôi chạy bước kiểm tra này thông qua một cron job hàng tuần thay vì sau mỗi lần triển khai. Nó giúp theo dõi các xu hướng hiệu suất.
Tôi theo dõi:
- Điểm hiệu suất (Performance scores) dưới 80
- CLS trên 0,1
- Các lỗi suy giảm khả năng truy cập (Accessibility regressions)
Vì các trang web của tôi sử dụng Astro SSG và không có JS ở phía client, các điểm số này nên duy trì ổn định. Nếu chúng giảm xuống, có khả năng một thay đổi CSS đã làm hỏng bố cục (layout). Tôi coi các điểm số này như một công cụ theo dõi xu hướng, chứ không phải là cách để chặn việc triển khai.
Tổng kết
Tôi không sử dụng giám sát thời gian hoạt động (uptime monitoring) hay các bài kiểm tra người dùng đầu cuối (end-to-end user tests). Đối với một bản triển khai CDN tĩnh, ba bước kiểm tra này đã bao quát được các rủi ro chính của tôi. Chúng bảo vệ SEO và tính toàn vẹn của bố cục mà không làm tăng thêm sự phức tạp không cần thiết.
Nguồn: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-48b4