Staging Ortamı Nedir? Canlıya Almadan Önce Test Edin

Staging ortamı, uygulamanızın canlı sürüme mümkün olduğunca yakın kurulmuş özel bir kopyasıdır; değişiklikleri gerçek kullanıcılar görmeden önce burada test edersiniz. Kendi veritabanını, test verilerini ve test API anahtarlarını kullanır; bu yüzden orada bozulan bir özellik ya da hatalı bir veri değişikliği ekip dışındaki hiç kimseyi etkilemez. Bir değişiklik staging'de doğru göründüğünde, onu production'a — müşterilerinizin kullandığı canlı uygulamaya — alırsınız.

AI ile geliştirirken staging neden önemli?

AI ile geliştirmek değişikliği hızlandırır. Bir özelliği eklemek, bir sayfayı yeniden yazmak ya da veri yapınızı değiştirmek dakikalar sürer. Bu hız harika, ta ki sessizce ödeme adımını bozan bir değişiklik veya "küçük bir temizlik" müşteri verisinin bir sütununu silene kadar.

Değişiklikler canlıya çıkmadan önce kontrol edebileceğiniz bir yer şunlara yardımcı olur:

• Müşteriler fark etmeden bozulmaları yakalamak. Her önemli değişiklikten sonra kayıt, ödeme ve temel akışları deneyin.
• Gerçek dünya koşullarında test etmek. Staging production gibi davranmalı — aynı yığın, benzer yapılandırma — böylece sorunlar daha sonra değil orada ortaya çıkar.
• Gerçek verileri korumak. Veritabanı değişiklikleri, içe aktarmalar ve toplu düzenlemeler önce test verileri üzerinde prova edilebilir.
• Devam eden işi göstermek. Bir müşteri veya ekip arkadaşı, değişiklik herkese açık olmadan onu inceleyebilir.

Günlük hayattan bir benzetme

Bir tiyatronun genel provasını düşünün.

• Development prova odasıdır: oyuncular replikleri dener, durur, baştan başlar, denemeler yapar.
• Staging genel provadır: tam kostümler, gerçek sahne, gerçek ışıklar — açılış gecesinde olacak her şey, yalnızca ödeme yapan bir seyirci yok.
• Production açılış gecesidir. Hatalar herkesin önünde olur.

Açılış gecesinde görmek istemediğiniz sorunların çoğu genel provada ortaya çıkar: çok uzun süren bir kostüm değişikliği ya da yanlış bir ışık ayarı. Staging'in tam olarak yaptığı iş de budur.

Üç yaygın ortam

Her ortam esas olarak yapılandırmasında farklılaşır: hangi veritabanına bağlandığı, hangi anahtarları kullandığı, hangi adreste yaşadığı. Bu yüzden iyi uygulamalar bu ayarları sabit kodlamak yerine ortam değişkenleri ve gizli bilgilerden okur. Aynı kod, farklı ayarlarla her ortamda çalışabilir.

Çalışılmış bir örnek: bir randevu uygulamasının iptal kurallarını değiştirmek

Ödeme yapan müşterileri olan bir kuaför randevu uygulaması işletiyorsunuz. Müşterilerin 48 saat yerine 24 saat önceye kadar iptal edebilmesini ve iadelerin otomatik yapılmasını istiyorsunuz.

1. Development'ta yapın. AI oluşturucunuzdan değişikliği istersiniz. İptal mantığını ve ödeme sağlayıcınıza giden iade çağrısını günceller.

2. Staging'e alın. Staging aynı kodu çalıştırır; test randevularının bulunduğu staging veritabanına ve ödeme sağlayıcınızın test modu anahtarlarına bağlıdır.

3. Gerçek akışları test edin. Siz ve bir meslektaşınız:

• yarın için bir test randevusu alıp 30 saat önce iptal edin — iade yapılmalı;
• 10 saat önce iptal etmeyi deneyin — açık bir mesajla reddedilmeli;
• iadenin ödeme sağlayıcısının test panelinde göründüğünü kontrol edin;
• onay e-postasının 48 değil 24 saat dediğini doğrulayın.

4. Hatayı bulun. Staging'de kuralın salonun saat dilimi yerine sunucunun saat dilimini kullandığını fark edersiniz; bu yüzden son iptal saati bir saat kayık. Düzeltirsiniz ve tekrar test edersiniz.

5. Production'a alın. Ancak şimdi değişiklik gerçek müşterilere ulaşır — saat dilimi hatası zaten yakalanmış olarak.

Staging olmasaydı, 4. adımdaki hata gerçek bir müşterinin iadesinde yaşanacaktı.

Temel terimler

Yaygın yanlış anlamalar

• "Staging production veritabanını paylaşabilir." Bu en tehlikeli kestirme yoldur. Kayıtları silen veya düzenleyen bir test gerçek müşterilere dokunur. Staging'e kendi veritabanını verin.
• "Staging'de çalışıyorsa production'da bozulamaz." Staging riski azaltır, ortadan kaldırmaz. Gerçek trafik, gerçek veri ve dış servisler yine de sizi şaşırtabilir. Geri alma yolunu hazır tutun.
• "Staging pahalı olmalı." Küçük olabilir. Production ile aynı kuruluma ihtiyacı vardır, aynı boyuta değil.
• "Gerçekçi olmak için staging'de canlı ödeme anahtarlarını kullanın." Sağlayıcının test modunu kullanın. Gerçekçi olmak gerçek para anlamına gelmez.
• "Staging yalnızca büyük ekipler içindir." Önce güvenli bir yerde test etme fikri tek kişi için bile faydalıdır. Törenin düzeyi, riske göre ölçeklenebilir.
• "İnsanlar denesin diye staging herkese açık olmalı." Özel veya korumalı tutun ve arama motorlarının dizine eklemesini engelleyin; böylece kimse onu gerçek uygulama sanmaz.

AI oluşturucunuzdan ne istemelisiniz

• "Her ortama özgü ayarı — veritabanı, API anahtarları, site URL'si — ortam değişkenlerinden gelecek şekilde yap."
• "Üretim dışı bir veritabanını gerçekçi test verileriyle dolduran bir seed betiği ekle."
• "Yayınlamaya karar verene kadar ödeme sağlayıcısının test modunu kullan."
• "Bu değişiklik canlıya gitmeden önce, test etmem gereken akışları ve her birinde ne olması gerektiğini listele."
• "Bu değişiklik mevcut verileri etkileyecek mi? Önce migration'ı göster."
• "Sitenin üretim dışı kopyalarının arama motorları tarafından dizine eklenmediğinden emin ol."

Adım adım kurulum için staging ortamı nasıl kurulur yazısına bakın. Yayınlar sıklaştığında, koddan staging'e ve production'a giden yolu otomatikleştirmek için CI/CD vardır.

Mythex'te yayından önce test

Mythex'te ayrı bir "staging ya da production" anahtarı yoktur; yayınlamak size tek bir canlı genel URL verir ve dokümanlar bunu açıkça belirtir (çok servisli uygulamalar). Sunduğu şey, geliştirme ile canlıya çıkış arasında net bir ayrımdır:

• Önizleme (Preview), siz geliştirirken uygulamanızı özel bir bulut sandbox'ında çalıştırır. Değişiklikler önce orada görünür, canlı uygulamanızda değil.
• Paylaş (Share), bir müşterinin veya ekip arkadaşının Mythex hesabı olmadan ve siz yayınlamadan devam eden işi incelemesi için önizleme bağlantıları oluşturur. Bağlantı sandbox'ı o anki haliyle gösterir, yapım sürecindeki değişiklikler dahil, ve istediğiniz zaman silebilirsiniz.
• Yayınla (Publish) projenin anlık görüntüsünü alır ve dağıtır. Tekrar yayınlayana kadar canlı uygulama eski haliyle kalır.
• Checkpoint'ler agent'ın her başarılı turundan sonra kaydedilir, böylece bir değişiklik ters giderse proje dosyalarını geri alabilirsiniz.

Önizlemeyi prova alanınız gibi düşünün: lansmana kadar ödeme sağlayıcılarını test modunda tutun ve her yayından önce temel akışlarınızdan geçin. Gerçek müşteriler söz konusu olduğunda, veri yazan veya silen herhangi bir şeyi test etmeden önce agent'a önizlemenizin hangi veritabanını ve anahtarları kullandığını sorun. Projeniz için tamamen ayrı bir staging kurulumuna ihtiyacınız varsa, seçeneklerinizi açıklamasını agent'tan isteyin veya — Pro'da — projeyi dışa aktarın ya da GitHub'a senkronize edip kendi kontrol ettiğiniz altyapıda çalıştırın.

Sorular