Cara Menyiapkan Staging Environment untuk Aplikasi Anda

Untuk menyiapkan staging environment, deploy salinan kedua aplikasi Anda ke URL privat tersendiri, beri database dan test API key-nya sendiri, dan buat agar pengaturannya semirip mungkin dengan production. Lalu rilis setiap perubahan penting ke staging terlebih dahulu, jalankan alur-alur yang penting, dan baru publikasikan ke production ketika staging sudah terlihat benar.

Jika Anda baru mengenal konsepnya, apa itu staging environment menjelaskannya. Panduan ini berisi langkah penyiapannya yang praktis, ditulis untuk orang yang membangun dengan alat AI, bukan untuk tim DevOps.

Development, staging, dan production

Kebanyakan aplikasi kecil membutuhkan tiga tempat, meskipun yang pertama hanya berupa preview dari builder Anda:

Inti dari staging adalah bahwa ia berperilaku seperti production — kode yang sama, stack yang sama, jenis pengaturan yang sama — tetapi kesalahan di sana tidak merugikan siapa pun.

Langkah 1: Tentukan apa yang harus sama dengan staging

Staging hanya berguna jika masalah muncul di sana sebelum muncul di production. Samakan:

• Kode yang sama, dirilis dengan cara yang sama.
• Stack dan versi yang sama — framework, runtime, jenis database.
• Jenis konfigurasi yang sama — nama environment variable yang sama, dengan nilai uji.
• Layanan yang sama — jika production memiliki web app dan API, staging juga memiliki keduanya.

Staging boleh berbeda dalam ukuran (mesin yang lebih kecil tidak masalah) dan dalam data.

Langkah 2: Buat salinannya

Cara paling sederhana: deployment kedua dari proyek yang sama, di URL berbeda seperti staging.namaapp.com atau namaapp-staging.example.com.

Caranya bergantung pada host Anda:

• Host dengan deployment preview atau staging bawaan dapat membuatnya secara otomatis untuk sebuah Git branch.
• Host tanpa fitur itu: buat app atau proyek kedua dari kode yang sama, lalu deploy secara terpisah.
• Kode di Git: simpan branch staging atau main yang dideploy ke staging, dan deploy ke production dari sebuah rilis. Lihat cara menggunakan Git dengan aplikasi yang dibangun AI.

Langkah 3: Beri staging database sendiri

Langkah inilah yang melindungi Anda. Jika staging dan production berbagi database, sebuah tes yang menghapus data akan menghapus data production yang sungguhan.

• Buat database terpisah untuk staging.
• Isi dengan seed data — catatan palsu yang realistis yang bisa dibuatkan AI untuk Anda.
• Jika Anda membutuhkan salinan data production, hapus atau acak nama, email, dan semua informasi pribadi terlebih dahulu.

Tulis skrip seed yang mengisi database kosong dengan data uji yang realistis: 20 pelanggan, 50 pesanan dalam status berbeda, dan dua pengguna admin. Gunakan nama palsu yang jelas dan alamat email example.com.

Sebelum Anda mempercayai penyiapannya, pastikan database mana yang terhubung ke setiap salinan. Tanyakan langsung:

Database mana yang terhubung ke aplikasi ini, dan dari mana pengaturan itu berasal? Tunjukkan nama variabelnya, bukan kata sandinya.

Langkah 4: Gunakan test key dan pengaturan terpisah

Setiap hal yang berkomunikasi dengan layanan luar harus memakai kredensial test di staging:

• Pembayaran dalam mode test (misalnya test key Stripe), sehingga tidak ada kartu sungguhan yang ditagih.
• Email dikirim ke sandbox atau hanya ke alamat Anda sendiri, sehingga pelanggan tidak pernah menerima pesan uji.
• AI dan API berbayar lainnya dengan key terpisah dan batas pengeluaran yang rendah.
• Webhook diarahkan ke URL staging, bukan production.

Jaga agar nama variabel tetap sama di kedua environment dan hanya ubah nilainya. Dengan begitu kode tidak perlu tahu di mana ia berjalan. Untuk informasi lebih lanjut, lihat cara menjaga API key tetap aman.

Langkah 5: Jaga staging tetap privat

Staging seharusnya tidak publik:

• Letakkan di balik login, kata sandi, atau daftar email tim yang diizinkan.
• Cegah mesin pencari mengindeksnya dengan meta tag noindex atau header X-Robots-Tag.
• Jangan tautkan dari situs publik Anda.
• Buat tampilannya berbeda — banner berwarna "STAGING" mencegah pengujian di tab yang salah.

Tambahkan banner kuning mencolok di bagian atas setiap halaman yang bertuliskan "STAGING — hanya data uji" ketika environment variable APP_ENV bernilai "staging". Dalam kondisi itu, tambahkan juga meta tag noindex.

Langkah 6: Buat rutinitas rilis

Staging hanya membantu jika Anda menggunakannya setiap kali. Rutinitas sederhana:

1. Buat perubahan di development dan periksa di preview.
2. Rilis ke staging.
3. Jalankan alur utama Anda: daftar, masuk, fitur utama, pembayaran, apa pun yang disentuh perubahan.
4. Jika ada yang rusak, perbaiki dan rilis lagi ke staging.
5. Publikasikan versi yang sama ke production.
6. Periksa production dengan cepat — alur yang sama, secara singkat.

Tuliskan alur utama sebagai skrip uji singkat. Lihat cara menguji aplikasi Anda sebelum peluncuran untuk apa saja yang perlu dimasukkan.

Langkah 7: Tangani perubahan database dengan hati-hati

Perubahan pada struktur database — menambah kolom, mengganti nama tabel — adalah saat staging benar-benar berguna.

• Jalankan setiap perubahan struktural di staging terlebih dahulu.
• Periksa bahwa data yang ada tetap utuh, bukan hanya bahwa fitur baru berfungsi.
• Buat cadangan production sebelum menjalankan perubahan yang sama di sana. Lihat cara membuat cadangan database aplikasi Anda.
• Utamakan perubahan yang menambah daripada mengganti nama atau menghapus, sehingga versi lama tetap berfungsi jika Anda perlu kembali.

Contoh prompt

Jelaskan apa yang akan terjadi pada data yang ada jika kita menjalankan perubahan database ini di production. Apakah ada yang dihapus atau diganti namanya?

Buat semua pengaturan yang spesifik untuk environment — URL API, key, pengirim email, URL situs itu sendiri — berasal dari environment variable dengan nama yang sama di staging dan production. Daftarkan semuanya.

Tulis checklist singkat tentang alur apa saja yang harus saya uji di staging sebelum setiap rilis, berdasarkan apa yang dilakukan aplikasi ini.

Kesalahan umum

• Database yang dipakai bersama. Kesalahan paling merusak. Staging selalu harus punya database sendiri.
• Key live di staging. Tagihan sungguhan, email sungguhan ke pelanggan sungguhan.
• Staging menyimpang dari production. Versi atau pengaturan yang berbeda membuat staging berhenti menangkap masalah.
• Situs staging publik yang terindeks dan muncul di hasil pencarian di samping situs asli Anda.
• Melewati staging untuk perubahan "kecil". Perubahan kecil juga bisa merusak.
• Menguji di tab yang salah. Banner yang terlihat mengatasi ini.

Checklist

• Staging menjalankan kode, stack, dan layanan yang sama dengan production.
• Staging memiliki database sendiri dengan data uji atau data yang sudah diacak.
• Pembayaran, email, dan API berbayar memakai test key di staging.
• Nama variabel sama di setiap environment; hanya nilainya yang berbeda.
• Staging berada di balik login atau kata sandi dan tidak diindeks.
• Banner muncul ketika Anda berada di staging.
• Setiap rilis masuk ke staging terlebih dahulu, dengan daftar tertulis alur yang harus diperiksa.
• Perubahan database dijalankan di staging terlebih dahulu, dengan cadangan production sebelum rilis.

Staging di Mythex

Fitur Publish di Mythex memberi Anda satu URL live per aplikasi; tidak ada tombol staging terpisah. Dalam praktiknya ada dua pilihan:

• Preview sebagai pemeriksaan sebelum rilis. Setiap proyek berjalan di workspace cloud privat dengan Preview yang live. /test meminta agen mengklik-klik di dalamnya seperti pengguna, dan tautan Share memungkinkan klien atau anggota tim meninjau preview tanpa mempublikasikannya. Lihat Preview dan Code. Ini sudah cukup untuk banyak proyek solo.
• Proyek kedua sebagai staging. Di paket Pro, ekspor proyek lalu impor ke proyek baru, beri proyek itu database dan secret test-key sendiri, dan publikasikan di slug-nya sendiri. Rilis ke sana sebelum Anda mempublikasikan proyek production.

Apa pun pilihannya, tanyakan kepada agen database mana yang dipakai preview dan aplikasi yang dipublikasikan sebelum menguji apa pun yang bersifat merusak, dan gunakan checkpoint untuk kembali jika ada perubahan yang buruk. Untuk membawa aplikasi ke tahap live secara lebih luas, lihat cara membawa prototipe AI ke production.

Pertanyaan