Aydınlatma metni yükleniyor…
Web sitesindeki her değişiklik için ayrı bir test ortamı kurmak gerekmez. Metin, görsel veya etkisi kolayca sınırlandırılabilen düşük riskli stil düzenlemeleri kontrollü biçimde canlı sitede yapılabilir. Yazılım güncellemeleri, ödeme sistemleri, formlar, üyelik işlemleri, veri tabanı değişiklikleri ve kapsamlı tasarım düzenlemeleri ise canlı kullanıcıları etkilemeden önce test ortamında denenmelidir.
Doğru karar yalnızca değişikliğin ne kadar küçük göründüğüne bağlı değildir. Değişikliğin kullanıcı işlemine, veriye, başka sistemlere ve geri dönüş yöntemine etkisi birlikte değerlendirilmelidir. Bu rehber, planladığınız düzenlemeyi “kontrollü canlı değişiklik”, “test ortamında doğrulama” veya “ayrı geliştirme” olarak sınıflandırmanıza yardımcı olacak bir karar matrisi sunar.
Canlı Ortam ve Test Ortamı Ne İşe Yarar?
Canlı ortam, ziyaretçilerin ve çalışanların gerçek işlemlerini yürüttüğü yayındaki sistemdir. Buradaki bir hata; form gönderimini, sipariş kaydını, üyelik işlemini, sayfa görünümünü veya üçüncü taraf bağlantısını doğrudan etkileyebilir.
Test ortamı ise planlanan değişikliğin gerçek kullanıcıları ve canlı veriyi etkilemeden incelendiği ayrı çalışma alanıdır. Tasarım, işlev, kullanıcı rolü, form, ödeme veya entegrasyon senaryoları burada denenebilir. Müşteri de yayına alınacak sürümü canlıdan önce bu ortamda kontrol edebilir.
Ancak test ortamı, canlı sistemin kusursuz bir kopyası olduğu anlamına gelmez. Alan adı, sunucu yapılandırması, önbellek, e-posta servisi, ödeme ayarları, erişim izinleri veya gerçek trafik davranışı iki ortamda farklı olabilir. Bu nedenle testte başarılı olan değişiklik, canlıya alındıktan sonra kısa bir üretim kontrolünden geçirilmelidir.
OWASP Web Security Testing Guide, test faaliyetlerini geliştirme, dağıtım, bakım ve operasyon aşamalarına yayılan bir süreç olarak ele alır. Rehber ayrıca QA ortamında onaylanıp test edilen değişikliklerin üretime alındıktan sonra yeniden kontrol edilmesini değişiklik yönetiminin parçası olarak tanımlar.
Hangi Değişiklik Nerede Yapılmalı?
Aşağıdaki matris başlangıç kararı verir. Nihai yöntem; sitenin teknik yapısına, değişikliğin kapsamına, veri etkisine ve geri dönüş imkânına göre belirlenmelidir.
| Değişiklik türü | Başlangıç kararı | Neden? | Asgari kontrol |
|---|---|---|---|
| Yazım hatası, kısa metin veya telefon bilgisi | Kontrollü canlı değişiklik olabilir | Etki çoğunlukla tek içerik alanıyla sınırlıdır | Önizleme, bağlantı ve iki dil kontrolü |
| Görsel değişimi | Kontrollü canlı değişiklik olabilir | Teknik işlevi etkilemeyebilir; fakat boyut ve kırpma riski vardır | Masaüstü/mobil kırpma, dosya boyutu ve alt metin |
| Düşük riskli stil düzenlemesi | Kontrollü canlı değişiklik olabilir | Belirli bir bileşenle sınırlandırılabilir | Hedef sayfa, mobil görünüm ve yakın bileşenler |
| Şablon veya kapsamlı tasarım değişikliği | Test ortamı | Birçok sayfayı ve ekran boyutunu etkileyebilir | Sayfa örnekleri, mobil/tablet, form ve menüler |
| Yazılım veya bağımlılık güncellemesi | Test ortamı | Mevcut işlevlerde ve uyumlulukta beklenmeyen sonuç oluşturabilir | Kritik akışlar, hata kayıtları ve entegrasyonlar |
| Form veya e-posta akışı | Test ortamı | Başarı mesajı görünse bile teslim zinciri bozulabilir | Gönderim, alıcı teslimi, log ve hata durumu |
| Ödeme ve üyelik işlemleri | Test ortamı | Sipariş, oturum, yetki ve kayıt zinciri etkilenebilir | Başarılı/başarısız işlem, kayıt ve bildirimler |
| Veri tabanı, kullanıcı rolü veya yetki değişikliği | Test ortamı ve geri dönüş planı | Veri bütünlüğü ve erişim sınırları etkilenebilir | Yedek, örnek veri, rol senaryoları ve geri dönüş |
| Yeni modül veya kapsamlı entegrasyon | Ayrı geliştirme ve test | Değişiklik tek bir düzenleme değil, yeni işlev kapsamıdır | Gereksinim, senaryo, kabul ölçütü ve yayın planı |
Bu tablo “canlıda yapılabilir” ifadesini “kontrol gerekmez” anlamında kullanmaz. Düşük riskli bir metin değişikliği bile yanlış dile uygulanabilir, bağlantıyı bozabilir veya tasarımda taşma oluşturabilir.
Küçük Bir Değişikliğin Gerçek Riskini Nasıl Belirlersiniz?
Değişiklik birkaç satırdan oluşsa bile etkisi geniş olabilir. Karardan önce şu beş soruyu yanıtlayın:
- Kaç sayfa veya bileşen etkileniyor? Ortak şablondaki küçük bir stil değişikliği, bütün sitede görünebilir.
- Kullanıcı bir işlem yapıyor mu? Form, ödeme, üyelik, arama veya dosya yükleme gibi akışlarda test gereksinimi yükselir.
- Veri değişiyor mu? Veri tabanı yapısı, kullanıcı kaydı, sipariş veya yetki etkileniyorsa geri dönüş daha dikkatli planlanmalıdır.
- Başka bir servise bağlı mı? E-posta, CRM, ödeme, harita veya API bağlantısında iki tarafın ayarları ve hata durumları vardır.
- Sorun çıkarsa geri almak kolay mı? Önceki değer biliniyor ve değişiklik tek alandaysa geri dönüş basit olabilir. Veri dönüştüren bir işlemde yalnızca eski dosyayı yüklemek yeterli olmayabilir.
Bu sorulardan biri belirsizse değişikliği doğrudan canlıda uygulamak yerine test ortamına taşımak daha kontrollü bir seçimdir.
Değişiklik Süreci Projeye Göre Tasarlanmalıdır
Her web projesinin aynı teknik yapıya ve risk düzeyine sahip olmadığı unutulmamalıdır. NIST Secure Software Development Framework, güvenli yazılım geliştirme uygulamalarını mevcut yazılım yaşam döngülerine eklenebilen üst düzey bir çerçeve olarak sunar. Bu yaklaşım, araç veya ortam adını tek başına yeterli saymak yerine sürecin proje gereksinimlerine göre düzenlenmesini destekler.
Kumsal Ajans; kurumsal web siteleri, e-ticaret, özel yazılım ve entegrasyon içeren projelerde ayrı test ortamı kullanır. Metin, görsel ve düşük riskli stil düzenlemeleri ise etki alanı kontrol edilerek canlıda yapılabilir. Buradaki amaç her değişikliği ağır bir sürece dönüştürmek değil, kullanıcıyı, veriyi veya iş akışını etkileyebilecek değişiklikleri canlı sistemden ayırmaktır.
Projeye özel geliştirilen içerik yönetim altyapısında da aynı karar mantığı geçerlidir. İçerik editörünün belirli bir sayfadaki metni değiştirmesiyle form davranışını, kullanıcı rolünü veya entegrasyonu değiştiren bir yazılım düzenlemesi aynı risk sınıfında değerlendirilmez.
Kontrollü Yayına Alma Süreci Nasıl İlerler?
Kumsal Ajansın doğrulanmış uygulamasını genel bir kontrol akışına dönüştürdüğümüzde süreç şu şekilde ilerler:
1. Değişiklik ve etki alanı tanımlanır
Hangi sayfaların, kullanıcı rollerinin, verilerin ve entegrasyonların etkilenebileceği belirlenir. Bir değişikliğin kapsamı açık değilse test senaryosu da eksik kalır.
2. Uygun ortam seçilir
Düşük riskli içerik ve sınırlı stil düzenlemeleri kontrollü canlı değişiklik olarak ele alınabilir. Yazılım, ödeme, form, üyelik, veri tabanı ve kapsamlı tasarım değişiklikleri test ortamına alınır. Yeni modül veya iş akışı ise ayrı geliştirme kapsamı olarak planlanabilir.
3. Kritik senaryolar test edilir
Yalnızca değiştirilen ekranın açılması yeterli değildir. Değişikliğin başlangıçtan sonuca uzanan kullanıcı akışı kontrol edilir. Örneğin bir ödeme düzenlemesinde yalnızca ödeme ekranı değil; oturum, sipariş kaydı, durum güncellemesi ve gerekli bildirimler birlikte incelenir.
4. Teknik kontrol ve müşteri onayı ayrılır
Teknik kontroller Kumsal Ajans ekibi tarafından tamamlanır. Nihai yayın onayı müşteri yetkilisinden alınır. Böylece “çalışıyor” değerlendirmesiyle “iş ihtiyacını doğru karşılıyor ve yayına alınabilir” kararı aynı kişiye veya tek bir bakış açısına bırakılmaz.
5. Yedek ve geri dönüş hazırlığı yapılır
Canlıya geçiş öncesinde dosya ve veri tabanı yedeği alınır. Değişikliğin niteliği gerektiriyorsa önceki sürüme veya uygun yedeğe nasıl dönüleceği planlanır. Yedeğin bulunması tek başına geri dönüş planı değildir; hangi koşulda, hangi bileşenin ve hangi sırayla geri alınacağı da bilinmelidir.
6. Canlıya alınır ve tekrar kontrol edilir
Onaylanan değişiklik canlı ortama aktarılır. Ardından yalnızca sayfanın açılması değil, değişiklikle ilişkili kritik işlemler yeniden denenir. Test ile canlı ortam arasındaki yapılandırma farkları ancak bu aşamada görünür hâle gelebilir.
Test Ortamı Ziyaretçilerden ve Arama Motorlarından Nasıl Korunur?
Test ortamları tamamlanmamış içerik, örnek veri veya henüz onaylanmamış işlevler barındırabilir. Bu nedenle hem erişim hem de indeksleme ayrı ayrı ele alınmalıdır.
Kumsal Ajans projelerinde ihtiyaca göre şifreli erişim, IP kısıtlaması ve arama motoru indeksleme engelleri kullanılır. Google Search Central, özel içeriğe yalnızca yetkili kullanıcıların ulaşması gerekiyorsa parola korumasını; erişilebilir bir sayfanın Google sonuçlarında görünmemesi için ise noindex kuralını açıklar.
Bu iki önlem aynı görevi yapmaz. noindex, sayfaya erişimi engellemez; sayfanın arama sonuçlarında yer almamasını ister. Parola veya başka bir yetkilendirme ise içeriğe erişimi sınırlar. robots.txt dosyasında taramayı engellemek de tek başına kesin bir indeks engeli gibi değerlendirilmemelidir.
Test ortamı için uygulanacak yöntem, içerdiği veriye ve kimlerin erişmesi gerektiğine göre seçilmelidir. Gerçek kişisel veya ticari verilerin kontrolsüz biçimde test ortamına kopyalanması normal bir test adımı olarak görülmemelidir.
Canlıya Geçişten Sonra Hangi Kontroller Tekrarlanır?
Kumsal Ajans, canlıya geçiş sonrasında değişikliğin kapsamına göre şu alanları yeniden kontrol eder:
- Formların gönderimi ve gerekli bildirimler
- Mobil görünüm ve temel responsive davranış
- Sayfa içi ve sayfalar arası bağlantılar
- Projeye bağlı entegrasyonlar
- Sayfanın veya kritik akışın hız davranışı
- SSL erişimi ve güvenli bağlantı
- Temel SEO öğeleri
“Temel SEO kontrolü”; değişiklikten etkilenen sayfanın başlık, indeksleme, canonical, dil bağlantısı veya erişim durumunda beklenmeyen bir bozulma olup olmadığına bakmayı içerebilir. Bu kontrol sıralama garantisi değildir. Hız kontrolü de belirli bir skor vaadi anlamına gelmez; değişikliğin açık bir performans sorunu oluşturup oluşturmadığını incelemeye yarar.
Kontrol kapsamı değişiklikle eşleşmelidir. Yalnızca tek bir görsel değiştiyse ödeme akışının tamamını yeniden test etmek gerekmeyebilir. Ortak şablon, yazılım sürümü veya sunucu ayarı değiştiyse daha geniş örneklem gerekir.
İsimsiz Gerçek Örnek: Test Başarılıyken Canlıda Sipariş Neden Oluşmadı?
Kumsal Ajansın bir projesinde ödeme işlemi test ortamında başarılı görünüyordu. Ancak canlı sunucudaki oturum ayarları nedeniyle ödeme akışının ardından sipariş kaydı oluşmuyordu. Yayın öncesi canlı kontrol sırasında sorun tespit edildi ve ilgili yapılandırma düzeltildi.
Bu örnek iki önemli sınırı gösterir. Birincisi, test ortamındaki başarı canlı ortamın bütün yapılandırmalarının aynı olduğunu kanıtlamaz. İkincisi, kontrol yalnızca ödeme sağlayıcısının “başarılı” yanıtını görmekle bitmemelidir; siparişin uygulamada oluşması ve sonraki iş adımlarının devam etmesi de doğrulanmalıdır.
Örneğin müşteri, sektör ve kullanılan servis bilgileri anonim tutulmuştur. Amaç belirli bir altyapıyı sorunlu göstermek değil, test ile canlı arasındaki farkın neden üretim kontrolü gerektirdiğini açıklamaktır.
Yayın Öncesi Kısa Karar ve Kontrol Listesi
Bir değişikliği yayına almadan önce aşağıdaki kayıt oluşturulabilir:
| Kontrol | Yanıtlanacak soru |
|---|---|
| Değişiklik tanımı | Tam olarak ne değişiyor? |
| Etkilenen alan | Hangi sayfa, rol, veri veya entegrasyon etkilenebilir? |
| Ortam kararı | Kontrollü canlı düzenleme mi, test ortamı mı, ayrı geliştirme mi? |
| Test senaryosu | Başarılı ve başarısız hangi akışlar denenecek? |
| Teknik sorumlu | Kontrolü kim tamamlayacak? |
| Müşteri onayı | Nihai yayına kim izin verecek? |
| Yedek | Hangi dosya ve veri tabanı yedeği alındı? |
| Geri dönüş | Sorun halinde hangi sürüme veya yedeğe nasıl dönülecek? |
| Canlı kontrol | Yayından hemen sonra hangi işlemler tekrar denenecek? |
| Kayıt | Sonuç ve bulunan sorunlar nerede tutulacak? |
Bu liste her projede aynı uzunlukta olmak zorunda değildir. Önemli olan, değişikliğin gerçek etkisini görünür kılmak ve onay ile teknik kontrolü kayda bağlamaktır.
Sonuç: Değişikliğin Boyutuna Değil, Etkisine Bakın
Web sitesi değişikliklerinde doğru ortam kararı, işin kaç dakika süreceğinden veya kaç satır kod içerdiğinden daha fazlasına bağlıdır. Kullanıcı işlemi, veri, entegrasyon, ortak şablon veya geri dönüş yöntemi etkileniyorsa değişiklik test ortamında ele alınmalıdır. Etkisi tek bir içerik alanıyla sınırlı ve kolayca geri alınabilir bir düzenleme ise kontrollü canlı değişiklik yeterli olabilir.
Kumsal Ajans; kurumsal web sitesi, e-ticaret, özel yazılım ve entegrasyon projelerinde test, teknik kontrol, müşteri onayı, yedekleme ve canlı sonrası doğrulama adımlarını proje kapsamına göre planlar. Projenizdeki değişikliğin hangi ortamda ve hangi kontrol düzeyiyle ele alınması gerektiğini değerlendirmek için web yazılım hizmetimizi inceleyebilirsiniz.
Yayın ve teslim aşamasındaki daha geniş kontroller için kurumsal web sitesi teslim kontrol listesinden, yayın sonrası sorumluluk sınırları için ücretsiz destek ve yıllık bakım rehberinden yararlanabilirsiniz.
Sık Sorulan Sorular
Her web sitesi için ayrı test ortamı gerekir mi?
Her değişiklik için aynı düzeyde test ortamı gerekmeyebilir. Kumsal Ajans; kurumsal web sitesi, e-ticaret, özel yazılım ve entegrasyon içeren projelerde ayrı test ortamı kullanır. Tek bir metin veya düşük riskli görsel düzenlemesi ise etki alanı kontrol edilerek canlıda yapılabilir.
Test ortamında çalışan değişiklik canlıda neden sorun çıkarabilir?
Alan adı, sunucu yapılandırması, önbellek, oturum, e-posta, ödeme veya erişim ayarları farklı olabilir. Bu nedenle test sonucu önemli olsa da değişiklik canlıya alındıktan sonra ilgili kritik işlem yeniden kontrol edilmelidir.
noindex test ortamını tamamen korur mu?
Hayır. noindex, erişilebilir sayfanın arama sonuçlarında gösterilmemesi için kullanılan bir direktiftir; kullanıcı erişimini engellemez. Özel test ortamlarında parola, IP kısıtlaması veya başka bir yetkilendirme yöntemi ayrıca gerekebilir.
Canlıya geçiş öncesinde yedek almak yeterli midir?
Yedek önemli bir hazırlıktır ancak tek başına geri dönüş planı değildir. Hangi koşulda geri dönüleceği, dosya ve veri tabanının hangi sırayla geri alınacağı ve aradaki yeni işlemlerin nasıl ele alınacağı proje yapısına göre belirlenmelidir.
Canlıya geçiş onayını kim vermelidir?
Kumsal Ajans sürecinde teknik kontroller ekip tarafından tamamlanır; nihai yayın onayı müşteri yetkilisinden alınır. Böylece teknik uygunluk ile iş ihtiyacına ilişkin kabul kararı birbirinden ayrılır.