Uygulamanız için Staging Ortamı Nasıl Kurulur

Bir staging ortamı kurmak için uygulamanızın ikinci bir kopyasını kendi özel URL’sine yayınlayın, ona kendi veritabanını ve test API anahtarlarını verin ve kurulumunu üretimdekine mümkün olduğunca yakın tutun. Ardından her önemli değişikliği önce staging’e çıkarın, önemli akışlardan geçin ve ancak staging doğru göründüğünde üretime yayınlayın.

Kavrama yeniyseniz, staging ortamı nedir kavramı açıklar. Bu rehber ise bir DevOps ekibi yönetmek yerine yapay zekâ araçlarıyla uygulama geliştiren insanlar için pratik kurulumu anlatır.

Geliştirme, staging ve üretim

Çoğu küçük uygulamanın üç ortamı olur; ilki sadece oluşturma aracınızın önizlemesi bile olsa:

Staging’in amacı üretim gibi davranmasıdır — aynı kod, aynı yığın, aynı türde ayarlar — ama orada yapılan bir hata kimseye zarar vermez.

Adım 1: Staging’in neyle eşleşmesi gerektiğine karar verin

Staging, sorunlar üretimde görünmeden önce orada görünürse işe yarar. Şunları eşleştirin:

• Aynı kod, aynı yöntemle yayınlanmış.
• Aynı yığın ve sürümler — çatı, çalışma zamanı, veritabanı türü.
• Aynı türde yapılandırma — aynı ortam değişkeni adları, test değerleriyle.
• Aynı servisler — üretimde bir web uygulaması ve bir API varsa, staging’de de ikisi olmalı.

Boyut (daha küçük bir makine sorun değil) ve veri açısından farklı olabilir.

Adım 2: Kopyayı oluşturun

En basit yaklaşım: aynı projenin ikinci bir dağıtımını, staging.uygulamaniz.com ya da uygulamaniz-staging.example.com gibi farklı bir URL’de yapmak.

Nasıl yapacağınız barındırma sağlayıcınıza bağlıdır:

• Yerleşik önizleme ya da staging dağıtımı olan sağlayıcılar bir Git dalı için bunu otomatik oluşturabilir.
• Bunu olmayan sağlayıcılar: aynı koddan ikinci bir uygulama ya da proje oluşturun ve ayrı olarak dağıtın.
• Kodu Git’te tutanlar: staging’e dağıtan bir staging ya da main dalı tutun ve üretime bir sürümden dağıtın. Bkz. AI ile oluşturulmuş bir uygulamada Git nasıl kullanılır.

Adım 3: Staging’e kendi veritabanını verin

Sizi koruyan adım budur. Staging ve üretim aynı veritabanını paylaşırsa, kayıt silen bir test gerçek kayıtları siler.

• Staging için ayrı bir veritabanı oluşturun.
• Onu tohum verisi ile doldurun — yapay zekânın sizin için üretebileceği gerçekçi sahte kayıtlar.
• Üretim verisinin bir kopyasına ihtiyacınız varsa, önce isimleri, e-postaları ve kişisel olan her şeyi silin ya da karıştırın.

Boş bir veritabanını gerçekçi test verisiyle dolduran bir tohum betiği yaz: 20 müşteri, farklı durumlarda 50 sipariş ve iki yönetici kullanıcı. Açıkça sahte isimler ve example.com e-posta adresleri kullan.

Kuruluma güvenmeden önce her kopyanın hangi veritabanına bağlandığını doğrulayın. Doğrudan sorun:

Bu uygulama hangi veritabanına bağlanıyor ve bu ayar nereden geliyor? Şifreyi değil, değişken adını göster.

Adım 4: Test anahtarları ve ayrı ayarlar kullanın

Dış bir servisle konuşan her şey staging’de test kimlik bilgilerini kullanmalıdır:

• Ödemeler test modunda (örneğin Stripe test anahtarları), böylece gerçek bir kart çekilmez.
• E-posta bir sandbox’a ya da yalnızca kendi adresinize gönderilir; müşteriler asla bir test mesajı almaz.
• Yapay zekâ ve diğer ücretli API’ler ayrı bir anahtarla ve düşük bir harcama sınırıyla.
• Webhook’lar üretime değil staging URL’sine yönlendirilir.

İki ortamda da değişken adlarını aynı tutun, yalnızca değerleri değiştirin. Böylece kodun nerede çalıştığını bilmesi gerekmez. Bu konuda daha fazlası için bkz. API anahtarlarınızı nasıl güvende tutarsınız.

Adım 5: Staging’i özel tutun

Staging herkese açık olmamalıdır:

• Bir giriş, bir şifre ya da ekip e-postalarından oluşan bir izin listesi arkasına koyun.
• Arama motorlarının bir noindex meta etiketi ya da X-Robots-Tag başlığıyla dizinlemesini durdurun.
• Herkese açık sitenizden ona bağlantı vermeyin.
• Farklı görünmesini sağlayın — renkli bir "STAGING" bandı yanlış sekmede test yapmayı önler.

APP_ENV ortam değişkeni "staging" olduğunda, her sayfanın üstüne parlak sarı bir bant ekle ve bu metni göster: "STAGING — yalnızca test verisi". Bu durumda ayrıca bir noindex meta etiketi ekle.

Adım 6: Bir yayın rutini oluşturun

Staging, her seferinde kullanırsanız işe yarar. Basit bir rutin:

1. Değişikliği geliştirme ortamında yapın ve önizlemede kontrol edin.
2. Staging’e yayınlayın.
3. Temel akışlarınızdan geçin: kayıt olma, giriş yapma, ana özellik, ödemeler, değişikliğin dokunduğu her şey.
4. Bir şey bozulursa düzeltin ve staging’e yeniden yayınlayın.
5. Aynı sürümü üretime yayınlayın.
6. Üretimi hızlıca kontrol edin — aynı akışlar, kısaca.

Temel akışları kısa bir test betiği olarak yazın. Neleri içermesi gerektiği için bkz. lansmandan önce uygulamanızı nasıl test edersiniz.

Adım 7: Veritabanı değişikliklerini dikkatle yönetin

Veritabanı yapısındaki değişiklikler — bir sütun eklemek, bir tabloyu yeniden adlandırmak — staging’in değerini gösterdiği yerlerdir.

• Her yapısal değişikliği önce staging’de çalıştırın.
• Yalnızca yeni özelliklerin çalıştığını değil, mevcut verinin de sağlam kaldığını kontrol edin.
• Aynı değişikliği üretimde çalıştırmadan önce üretimin bir yedeğini alın. Bkz. uygulama veritabanınızı nasıl yedeklersiniz.
• Yeniden adlandırma ya da silme yerine ekleme yapan değişiklikleri tercih edin; böylece geri dönerseniz eski sürüm hâlâ çalışır.

Örnek istemler

Bu veritabanı değişikliğini üretimde çalıştırırsak mevcut verilere ne olur? Bir şey silinir ya da yeniden adlandırılır mı?

Ortama özgü tüm ayarları — API URL’leri, anahtarlar, e-posta göndericisi, sitenin kendi URL’si — staging ve üretimde aynı adlara sahip ortam değişkenlerinden gelecek şekilde yap. Bunları listele.

Bu uygulamanın ne yaptığına göre, her sürümden önce staging’de test etmem gereken akışların kısa bir kontrol listesini yaz.

Sık yapılan hatalar

• Paylaşılan veritabanı. En zararlı hata. Staging her zaman kendi veritabanını almalı.
• Staging’de canlı anahtarlar. Gerçek ücret kesimleri, gerçek müşterilere gerçek e-postalar.
• Staging üretimden sapar. Farklı sürümler ya da ayarlar, staging’in sorunları yakalamasını durdurur.
• Herkese açık, dizinlenen bir staging sitesi ve bunun gerçek sitenizin yanında arama sonuçlarında çıkması.
• "Küçük" değişiklikler için staging’i atlamak. Küçük değişiklikler de işleri bozar.
• Yanlış sekmede test etmek. Görünür bir bant bunu çözer.

Kontrol listesi

• Staging, üretimle aynı kodu, yığını ve servisleri çalıştırıyor.
• Staging, test ya da temizlenmiş verilerle kendi veritabanına sahip.
• Ödemeler, e-posta ve ücretli API’ler staging’de test anahtarlarını kullanıyor.
• Değişken adları ortamlar arasında eşleşiyor; yalnızca değerler farklı.
• Staging bir giriş ya da şifre arkasında ve dizinlenmiyor.
• Staging’de olduğunuzda bir bant görünüyor.
• Her sürüm önce staging’e gidiyor; kontrol edilecek akışların yazılı bir listesiyle.
• Veritabanı değişiklikleri önce staging’de çalışıyor; yayından önce üretimin yedeği alınıyor.

Mythex’te staging

Mythex’in Publish özelliği uygulama başına tek bir canlı URL verir; ayrı bir staging anahtarı yoktur. Pratikte iki seçeneğiniz var:

• Yayın öncesi kontrolünüz olarak Preview. Her proje, özel bir bulut çalışma alanında canlı bir Preview ile çalışır. /test komutu ajanın bir kullanıcı gibi üzerinde gezinmesini sağlar ve bir Share bağlantısı bir müşterinin ya da ekip arkadaşının projeyi yayınlamadan önizlemeyi incelemesine olanak verir. Bkz. Preview ve Code. Birçok tek kişilik proje için bu yeterlidir.
• Staging olarak ikinci bir proje. Pro’da projeyi dışa aktarıp yeni bir projeye aktarın, o projeye kendi veritabanını ve test anahtarı gizli bilgilerini verin ve kendi slug’ı ile yayınlayın. Üretim projesini yayınlamadan önce oraya sürüm çıkarın.

Hangi yolu seçerseniz seçin, yıkıcı bir şey test etmeden önce önizlemenin ve yayınlanmış uygulamanın hangi veritabanını kullandığını ajana sorun ve kötü bir değişikliği geri almak için kontrol noktalarını kullanın. Uygulamayı daha geniş biçimde canlıya almak için bkz. bir yapay zekâ prototipini üretime nasıl taşırsınız.

Sorular