Cách thiết lập môi trường staging cho app của bạn

Để thiết lập môi trường staging, hãy triển khai một bản sao thứ hai của app lên một URL riêng, cấp cho nó cơ sở dữ liệu và khóa API thử nghiệm riêng, và làm cho cấu hình của nó khớp với production càng sát càng tốt. Sau đó, phát hành mọi thay đổi quan trọng lên staging trước, chạy qua các luồng chính, và chỉ xuất bản lên production khi staging ổn.

Nếu bạn mới làm quen với ý tưởng này, môi trường staging là gì giải thích khái niệm. Hướng dẫn này là phần thiết lập thực tế, viết cho những người xây dựng bằng công cụ AI thay vì vận hành một đội DevOps.

Dev, staging và production

Hầu hết app nhỏ cần ba môi trường, ngay cả khi môi trường đầu tiên chỉ là bản xem trước của công cụ xây dựng:

Mục đích của staging là hoạt động giống production — cùng mã nguồn, cùng stack, cùng kiểu cấu hình — nhưng một sai sót ở đó không gây hại cho ai.

Bước 1: Quyết định staging phải khớp với điều gì

Staging chỉ hữu ích khi các vấn đề xuất hiện ở đó trước khi xuất hiện trên production. Hãy khớp:

• Cùng mã nguồn, được phát hành theo cùng một cách.
• Cùng stack và phiên bản — framework, runtime, loại cơ sở dữ liệu.
• Cùng kiểu cấu hình — cùng tên biến môi trường, với giá trị thử nghiệm.
• Cùng dịch vụ — nếu production có web app và API, staging cũng có cả hai.

Staging có thể khác về quy mô (một máy nhỏ hơn cũng được) và về dữ liệu.

Bước 2: Tạo bản sao

Cách đơn giản nhất: triển khai thêm một lần nữa cùng dự án, ở một URL khác như staging.yourapp.com hoặc yourapp-staging.example.com.

Cách làm tùy thuộc vào host của bạn:

• Host có sẵn triển khai xem trước hoặc staging có thể tự động tạo một bản cho nhánh Git.
• Host không có tính năng này: tạo một app hoặc dự án thứ hai từ cùng mã nguồn, rồi triển khai riêng.
• Mã nguồn trên Git: giữ một nhánh staging hoặc main triển khai lên staging, và triển khai lên production từ một bản phát hành. Xem cách dùng Git với app do AI xây dựng.

Bước 3: Cấp cho staging cơ sở dữ liệu riêng

Đây là bước bảo vệ bạn. Nếu staging và production dùng chung cơ sở dữ liệu, một bài kiểm thử xóa bản ghi sẽ xóa bản ghi thật.

• Tạo một cơ sở dữ liệu riêng cho staging.
• Điền vào đó dữ liệu mẫu (seed) — các bản ghi giả nhưng thực tế mà AI có thể tạo cho bạn.
• Nếu cần bản sao dữ liệu production, hãy xóa hoặc xáo trộn tên, email và mọi thông tin cá nhân trước.

Viết một script seed điền dữ liệu thử nghiệm thực tế vào cơ sở dữ liệu trống: 20 khách hàng, 50 đơn hàng ở các trạng thái khác nhau, và hai người dùng quản trị. Dùng tên rõ ràng là giả và địa chỉ email kiểu example.com.

Trước khi tin vào cấu hình, hãy xác nhận mỗi bản sao đang kết nối vào cơ sở dữ liệu nào. Hỏi trực tiếp:

App này kết nối với cơ sở dữ liệu nào, và cài đặt đó đến từ đâu? Cho tôi xem tên biến, đừng hiện mật khẩu.

Bước 4: Dùng khóa thử nghiệm và cài đặt tách biệt

Mọi thứ giao tiếp với dịch vụ bên ngoài nên dùng thông tin xác thực thử nghiệm trên staging:

• Thanh toán ở chế độ thử nghiệm (ví dụ khóa thử của Stripe), để không thẻ thật nào bị trừ tiền.
• Email gửi đến sandbox hoặc chỉ đến địa chỉ của bạn, để khách hàng không bao giờ nhận thư thử nghiệm.
• AI và các API trả phí khác với khóa riêng và giới hạn chi tiêu thấp.
• Webhook trỏ vào URL staging, không phải production.

Giữ tên biến giống nhau ở cả hai môi trường và chỉ thay đổi giá trị. Như vậy mã nguồn không cần biết nó đang chạy ở đâu. Để biết thêm, xem cách giữ an toàn cho API key.

Bước 5: Giữ staging ở chế độ riêng tư

Staging không nên công khai:

• Đặt nó sau màn hình đăng nhập, mật khẩu, hoặc danh sách email đội nhóm được phép.
• Ngăn công cụ tìm kiếm lập chỉ mục bằng thẻ meta noindex hoặc tiêu đề X-Robots-Tag.
• Đừng liên kết đến nó từ trang công khai của bạn.
• Làm cho nó trông khác đi — một băng rôn "STAGING" màu nổi bật giúp tránh việc kiểm thử nhầm tab.

Thêm một băng rôn vàng nổi bật ở đầu mọi trang với nội dung "STAGING — chỉ dùng dữ liệu thử nghiệm" khi biến môi trường APP_ENV có giá trị "staging". Trong trường hợp đó, cũng thêm thẻ meta noindex.

Bước 6: Xây dựng thói quen phát hành

Staging chỉ có ích nếu bạn dùng nó mỗi lần. Một quy trình đơn giản:

1. Thực hiện thay đổi trong môi trường development và kiểm tra trong bản xem trước.
2. Phát hành lên staging.
3. Chạy qua các luồng chính: đăng ký, đăng nhập, tính năng cốt lõi, thanh toán, và bất cứ thứ gì thay đổi chạm tới.
4. Nếu có gì hỏng, sửa và phát hành lại lên staging.
5. Xuất bản cùng phiên bản đó lên production.
6. Kiểm tra nhanh production — các luồng tương tự, chỉ ngắn gọn.

Hãy ghi các luồng chính thành một kịch bản kiểm thử ngắn. Xem cách kiểm thử app trước khi ra mắt để biết cần bao gồm những gì.

Bước 7: Xử lý thay đổi cơ sở dữ liệu cẩn thận

Những thay đổi cấu trúc cơ sở dữ liệu — thêm một cột, đổi tên một bảng — là nơi staging thể hiện giá trị nhiều nhất.

• Chạy mọi thay đổi cấu trúc trên staging trước.
• Kiểm tra dữ liệu cũ vẫn còn nguyên, chứ không chỉ kiểm tra các tính năng mới hoạt động.
• Sao lưu production trước khi chạy cùng thay đổi đó ở đó. Xem cách sao lưu cơ sở dữ liệu của app.
• Ưu tiên các thay đổi thêm mới thay vì đổi tên hoặc xóa, để phiên bản cũ vẫn hoạt động nếu bạn cần hoàn tác.

Prompt mẫu

Giải thích điều gì sẽ xảy ra với dữ liệu hiện có nếu chúng ta chạy thay đổi cơ sở dữ liệu này trên production. Có gì bị xóa hoặc đổi tên không?

Hãy để mọi cài đặt phụ thuộc môi trường — URL API, khóa, người gửi email, URL của chính trang — lấy từ biến môi trường với cùng tên ở staging và production. Liệt kê chúng.

Viết một danh sách kiểm tra ngắn các luồng tôi nên thử trên staging trước mỗi lần phát hành, dựa trên những gì app này làm.

Các lỗi thường gặp

• Dùng chung cơ sở dữ liệu. Đây là lỗi gây hậu quả nặng nề nhất. Staging luôn phải có cơ sở dữ liệu riêng.
• Khóa thật trên staging. Dẫn đến trừ tiền thật, email thật gửi đến khách hàng thật.
• Staging lệch khỏi production. Khác phiên bản hoặc cài đặt khiến staging không còn bắt được vấn đề.
• Trang staging công khai và được lập chỉ mục, xuất hiện trong kết quả tìm kiếm bên cạnh trang thật.
• Bỏ qua staging cho các thay đổi "nhỏ". Thay đổi nhỏ cũng có thể làm hỏng mọi thứ.
• Kiểm thử nhầm tab. Một băng rôn hiển thị rõ sẽ khắc phục điều này.

Danh sách kiểm tra

• Staging chạy cùng mã nguồn, stack và dịch vụ với production.
• Staging có cơ sở dữ liệu riêng với dữ liệu thử nghiệm hoặc đã làm sạch.
• Thanh toán, email và các API trả phí dùng khóa thử nghiệm trên staging.
• Tên biến khớp nhau giữa các môi trường; chỉ giá trị là khác.
• Staging nằm sau màn hình đăng nhập hoặc mật khẩu và không được lập chỉ mục.
• Có băng rôn hiển thị khi bạn đang ở staging.
• Mọi bản phát hành đều lên staging trước, kèm danh sách luồng cần kiểm tra bằng văn bản.
• Thay đổi cơ sở dữ liệu chạy trên staging trước, với bản sao lưu production trước khi phát hành.

Staging trên Mythex

Tính năng Publish của Mythex cho bạn một URL trực tiếp cho mỗi app; không có nút chuyển riêng cho staging. Trên thực tế, bạn có hai lựa chọn:

• Dùng bản xem trước làm bước kiểm tra trước khi phát hành. Mỗi dự án chạy trong một không gian làm việc đám mây riêng với bản Preview trực tiếp. /test để agent tự thao tác trên đó như một người dùng, và liên kết Share cho phép khách hàng hoặc đồng đội xem bản xem trước mà không cần xuất bản. Xem Preview và Code. Với nhiều dự án cá nhân, như vậy là đủ.
• Một dự án thứ hai làm staging. Với gói Pro, hãy xuất dự án, nhập vào một dự án mới, cấp cho dự án đó cơ sở dữ liệu riêng và bí mật khóa thử nghiệm riêng, rồi xuất bản nó tại slug riêng. Phát hành lên đó trước khi xuất bản dự án production.

Dù chọn cách nào, hãy hỏi agent xem bản xem trước và app đã xuất bản đang dùng cơ sở dữ liệu nào trước khi kiểm thử bất cứ thao tác phá hủy nào, và dùng checkpoint để hoàn tác một thay đổi xấu. Để đưa app lên môi trường thật một cách toàn diện hơn, xem cách đưa prototype AI lên production.

Câu hỏi thường gặp