Cara Sediakan Persekitaran Staging untuk Aplikasi Anda

Untuk menyediakan persekitaran staging, terbitkan salinan kedua aplikasi anda ke URL persendirian sendiri, beri pangkalan data dan kunci API ujian sendiri, dan pastikan ia sepadan dengan persediaan pengeluaran sedekat mungkin. Kemudian lancarkan setiap perubahan penting ke staging dahulu, lalui aliran penting, dan hanya terbitkan ke pengeluaran apabila staging kelihatan betul.

Jika anda baru dengan idea ini, apakah itu persekitaran staging menerangkan konsepnya. Panduan ini ialah persediaan praktikal, ditulis untuk orang yang membina dengan alatan AI dan bukannya menjalankan pasukan DevOps.

Dev, staging dan pengeluaran

Kebanyakan aplikasi kecil memerlukan tiga tempat, walaupun yang pertama hanyalah pratonton pembina anda:

Tujuan staging ialah ia berkelakuan seperti pengeluaran — kod yang sama, tindanan yang sama, jenis tetapan yang sama — tetapi kesilapan di sana tidak menyakiti sesiapa.

Langkah 1: Tentukan apa yang staging mesti sepadan

Staging hanya berguna jika masalah muncul di sana sebelum muncul di pengeluaran. Padankan:

• Kod yang sama, dikeluarkan dengan cara yang sama.
• Tindanan dan versi yang sama — rangka kerja, runtime, jenis pangkalan data.
• Jenis konfigurasi yang sama — nama pembolehubah persekitaran yang sama, dengan nilai ujian.
• Perkhidmatan yang sama — jika pengeluaran mempunyai aplikasi web dan API, staging juga mempunyai kedua-duanya.

Saiznya boleh berbeza (mesin yang lebih kecil tidak mengapa) dan data juga boleh berbeza.

Langkah 2: Buat salinan

Cara paling mudah: penggunaan kedua projek yang sama, di URL yang berbeza seperti staging.yourapp.com atau yourapp-staging.example.com.

Cara anda melakukannya bergantung pada hos anda:

• Hos dengan penggunaan pratonton atau staging terbina dalam boleh mencipta satu secara automatik untuk cabang Git.
• Hos tanpa ciri itu: cipta aplikasi atau projek kedua daripada kod yang sama, dan gunakan secara berasingan.
• Kod dalam Git: kekalkan cabang staging atau main yang digunakan ke staging, dan gunakan ke pengeluaran daripada keluaran. Lihat cara menggunakan Git dengan aplikasi yang dibina AI.

Langkah 3: Beri staging pangkalan datanya sendiri

Langkah inilah yang melindungi anda. Jika staging dan pengeluaran berkongsi pangkalan data, satu ujian yang memadam rekod akan memadam rekod sebenar.

• Cipta pangkalan data berasingan untuk staging.
• Isikannya dengan data benih — rekod palsu yang realistik yang AI boleh jana untuk anda.
• Jika anda memerlukan salinan data pengeluaran, buang atau kaburkan nama, e-mel dan apa-apa yang peribadi terlebih dahulu.

Tulis skrip benih yang mengisi pangkalan data kosong dengan data ujian yang realistik: 20 pelanggan, 50 pesanan dalam keadaan berbeza, dan dua pengguna pentadbir. Gunakan nama palsu yang jelas dan alamat e-mel example.com.

Sebelum anda mempercayai persediaan itu, sahkan pangkalan data mana yang disambungkan oleh setiap salinan. Tanya secara terus:

Pangkalan data mana yang disambungkan oleh aplikasi ini, dan dari mana tetapan itu datang? Tunjukkan nama pembolehubah, bukan kata laluan.

Langkah 4: Gunakan kunci ujian dan tetapan berasingan

Setiap perkara yang berhubung dengan perkhidmatan luar sepatutnya menggunakan kelayakan ujian dalam staging:

• Pembayaran dalam mod ujian (kunci ujian Stripe, sebagai contoh), supaya tiada kad sebenar dicaj.
• E-mel dihantar ke sandbox atau hanya ke alamat anda sendiri, supaya pelanggan tidak pernah menerima mesej ujian.
• AI dan API berbayar lain dengan kunci berasingan dan had perbelanjaan yang rendah.
• Webhook ditujukan ke URL staging, bukan pengeluaran.

Kekalkan nama pembolehubah yang sama dalam kedua-dua persekitaran dan hanya tukar nilainya. Dengan cara itu kod tidak perlu tahu di mana ia berjalan. Untuk maklumat lanjut, lihat cara memastikan kunci API selamat.

Langkah 5: Pastikan staging persendirian

Staging sepatutnya tidak awam:

• Letakkan di sebalik log masuk, kata laluan, atau senarai benarkan e-mel pasukan.
• Hentikan enjin carian daripada mengindeksnya dengan tag meta noindex atau pengepala X-Robots-Tag.
• Jangan pautkan ke laman staging dari laman awam anda.
• Jadikan ia kelihatan berbeza — sepanduk "STAGING" berwarna menghalang ujian di tab yang salah.

Tambah sepanduk kuning terang di bahagian atas setiap halaman yang berbunyi "STAGING — data ujian sahaja" apabila pembolehubah persekitaran APP_ENV ialah "staging". Tambah juga tag meta noindex dalam keadaan itu.

Langkah 6: Buat rutin keluaran

Staging hanya membantu jika anda menggunakannya setiap kali. Rutin yang mudah:

1. Buat perubahan dalam pembangunan dan semaknya dalam pratonton.
2. Keluarkannya ke staging.
3. Lalui aliran utama anda: daftar masuk, log masuk, ciri utama, pembayaran, apa-apa yang disentuh oleh perubahan itu.
4. Jika ada yang rosak, betulkan dan keluarkan semula ke staging.
5. Terbitkan versi yang sama ke pengeluaran.
6. Semak pengeluaran dengan cepat — aliran yang sama, secara ringkas.

Tulis aliran utama sebagai skrip ujian yang pendek. Lihat cara menguji aplikasi anda sebelum pelancaran untuk perkara yang perlu dimasukkan.

Langkah 7: Kendalikan perubahan pangkalan data dengan berhati-hati

Perubahan pada struktur pangkalan data — menambah lajur, menamakan semula jadual — ialah tempat staging benar-benar berguna.

• Jalankan setiap perubahan struktur di staging dahulu.
• Semak data sedia ada masih selamat, bukan sekadar ciri baharu berfungsi.
• Buat sandaran pengeluaran sebelum menjalankan perubahan yang sama di sana. Lihat cara membuat sandaran pangkalan data aplikasi anda.
• Utamakan perubahan yang menambah dan bukan menamakan semula atau memadam, supaya versi lama masih berfungsi jika anda berundur.

Contoh arahan

Terangkan apa yang akan berlaku kepada data sedia ada jika kami menjalankan perubahan pangkalan data ini di pengeluaran. Adakah apa-apa dipadam atau dinamakan semula?

Jadikan semua tetapan khusus persekitaran — URL API, kunci, pengirim e-mel, URL laman itu sendiri — datang daripada pembolehubah persekitaran dengan nama yang sama dalam staging dan pengeluaran. Senaraikannya.

Tulis senarai semak ringkas tentang aliran yang patut saya uji di staging sebelum setiap keluaran, berdasarkan apa yang dilakukan aplikasi ini.

Kesilapan biasa

• Pangkalan data dikongsi. Kesilapan paling merosakkan. Staging sentiasa mendapat pangkalan datanya sendiri.
• Kunci sebenar dalam staging. Caj sebenar, e-mel sebenar kepada pelanggan sebenar.
• Staging menyimpang daripada pengeluaran. Versi atau tetapan yang berbeza bermakna staging berhenti menangkap masalah.
• Laman staging awam yang diindeks yang muncul dalam hasil carian di sebelah laman sebenar anda.
• Melangkau staging untuk perubahan "kecil". Perubahan kecil juga boleh merosakkan sesuatu.
• Menguji di tab yang salah. Sepanduk yang kelihatan menyelesaikannya.

Senarai semak

• Staging menjalankan kod, tindanan dan perkhidmatan yang sama seperti pengeluaran.
• Staging mempunyai pangkalan data sendiri dengan data ujian atau yang telah dibersihkan.
• Pembayaran, e-mel dan API berbayar menggunakan kunci ujian dalam staging.
• Nama pembolehubah sepadan merentasi persekitaran; hanya nilai yang berbeza.
• Staging berada di sebalik log masuk atau kata laluan dan tidak diindeks.
• Sepanduk dipaparkan apabila anda berada di staging.
• Setiap keluaran pergi ke staging dahulu, dengan senarai bertulis aliran untuk disemak.
• Perubahan pangkalan data dijalankan di staging dahulu, dengan sandaran pengeluaran sebelum keluaran.

Staging di Mythex

Penerbitan Mythex memberi anda satu URL langsung bagi setiap aplikasi; tiada suis staging berasingan. Dalam amalan, anda ada dua pilihan:

• Pratonton sebagai semakan pra-keluaran anda. Setiap projek berjalan dalam ruang kerja awan persendirian dengan Pratonton langsung. /test meminta ejen mengklik melaluinya seperti pengguna, dan pautan Kongsi membolehkan pelanggan atau rakan sepasukan menyemak pratonton tanpa menerbitkan. Lihat Pratonton dan Kod. Ini sudah memadai untuk banyak projek solo.
• Projek kedua sebagai staging. Pada Pro, eksport projek dan import ke projek baharu, beri projek itu pangkalan data dan rahsia kunci ujian sendiri, dan terbitkannya pada slug sendiri. Keluarkan ke sana sebelum anda menerbitkan projek pengeluaran.

Sama ada cara, tanya ejen pangkalan data mana yang digunakan oleh pratonton dan aplikasi yang diterbitkan sebelum menguji apa-apa yang merosakkan, dan gunakan titik semak untuk berundur daripada perubahan yang buruk. Untuk membawa aplikasi live dengan lebih meluas, lihat cara membawa prototaip AI ke pengeluaran.

Soalan lazim