☑ Mini Check (H1 seviyesi)
- • “Canlıda deneme” yapıyorsanız, staging/preview ve publish gate eksiktir.
1. Neden Birden Fazla Ortam? (Dev/Staging/Prod + CMS Preview)
Birden fazla ortam (environment) kullanmanın amacı “fazla iş çıkarmak” değil, risk izolasyonu sağlamaktır. Canlı ortam (prod) müşterinin gördüğü gerçek dünyadır; burada yapılan her hata doğrudan gelir, itibar ve ekip stresine yansır. Staging; prod’a en yakın test ortamıdır, “prod’da olacak şeyin provası” burada yapılır. Preview ise içerik ekibinin draft içerikleri “site üzerinde” görebilmesi için kritik bir köprüdür.
- •En basit çerçeve:
- •Dev: geliştirici testleri, yeni bileşenler
- •Staging: prod’a yakın UAT (User Acceptance Test)
- •Prod: canlı
- •CMS Preview: draft içeriği, prod/staging render’ında görme
CMS ortamları (preview, staging, prod) neden önemlidir?
Kısa cevap: Çünkü değişiklikleri canlıya almadan önce test edip onaylamanızı, yanlış yayını engellemenizi ve hata olursa hızlı geri almanızı sağlar.
- •Preview olmadan içerik “sitede nasıl duruyor” canlıda görülür.
- •Staging olmadan tasarım/JS değişikliği prod’da denenir.
- •Rollback olmadan kriz uzar (özellikle kampanya dönemlerinde).
- •☑ Mini Check:
- •Staging ortamınız prod’a “gerçekten” benziyor mu?
- •CMS preview linkleri her içerik tipinde var mı?
- •Prod’a deploy olmadan UAT yapılıyor mu?
Ne yapmalıyım?
- • Prod’a yakın staging oluştur (env config + CDN + analytics farklarını dokümante et).
- • CMS preview linklerini standartlaştır (draft içerik için).
- • Ortamlar arası içerik/asset erişim izinlerini netleştir.
- • UAT checklist’i zorunlu yap (en az kritik sayfalar).
- • Rollback planını “yayın sürecinin parçası” yap.
| Ortam | Amaç | Kim kullanır? | Tipik yetki/aksiyon |
|---|---|---|---|
| CMS Preview | Draft içeriği site üzerinde görmek | İçerik ekibi + reviewer | Preview linkleri ile kontrol; publish yok |
| Staging | Prod’a yakın UAT/test | QA + ürün/IT + ajans | UAT; entegrasyon/performans kontrol; prod öncesi prova |
| Prod | Canlı yayın | Son kullanıcı + operasyon | Yayınlı içerik; hata riski yüksek; rollback planı şart |
2. Draft → Review → Publish Süreci
Workflow’un kalbi; içerik üretimini ve yayınlamayı ayırmaktır. “Edit yetkisi olan herkes publish yapabiliyor” yaklaşımı, büyüyen ekiplerde kaos üretir. Draft→Review→Publish; hem kaliteyi hem sorumluluğu netleştirir: kim yazdı, kim onayladı, kim yayınladı.
Draft–review–publish workflow’u nasıl tasarlanır?
Kısa cevap: Taslak (draft) hazırlanır, preview’da kontrol edilir, reviewer onaylar, publisher planlı yayınlar; kritik değişikliklerde ikinci onay eklenir.
- •Önerilen minimum durum seti:
- •Draft: içerik hazırlanıyor
- •In Review: onay bekliyor
- •Approved: yayınlanabilir
- •Scheduled: tarihli yayın
- •Published: canlı
- •Rollback candidate: sorun çıkarsa geri alınacak sürüm etiketi
Publish gate (yayın kapısı) mantığı
Yayın, belirli koşullar sağlanmadan gerçekleşmemelidir. Örnek publish gate:
- •Meta title/description dolu mu?
- •Görsel/OG var mı?
- •Kampanya sayfasında tarih/koşul alanları doğrulandı mı?
- •Çok dilli projede EN/DE/RU “minimum alan seti” tamam mı?
- •☑ Mini Check:
- •Review adımı gerçekten zorunlu mu?
- •Planlı yayın (scheduled) kullanıyor musunuz?
- •Eksik alanlarla publish engelleniyor mu?
Ne yapmalıyım?
- • Status setini panelde standartlaştır (draft→review→approved→published).
- • Publish yetkisini sınırlı rol(ler)e ver (publisher).
- • Publish gate kurallarını içerik tipine göre yaz.
- • Scheduled publish + geri alma (rollback) prosedürü ekle.
- • Workflow’u ekip eğitimine bağla (kim, neyi, ne zaman yapar).
3. İçerik ve Tasarım Değişiklikleri İçin Workflow
İçerik değişikliği ile tasarım/geliştirme değişikliği aynı süreçten yönetilmezse, staging ve preview karmakarışık hale gelir. Sağlam yaklaşım: içerik değişiklikleri CMS workflow ile, tasarım/geliştirme değişiklikleri ise dev→staging→prod release süreci ile yönetilir; kritik nokta ikisini lansman takviminde senkronize etmektir.
İçerik değişikliği örneği (CMS odaklı)
- •Yeni blog: içerik ekibi draft yazar → preview’da kontrol → review → scheduled publish
- •Kampanya metni: reviewer + (gerekirse) revenue onayı → publish
Tasarım/geliştirme değişikliği örneği (release odaklı)
- •Yeni bileşen: dev’de geliştirilir → staging’de UAT → prod’a deploy
- •Deploy sonrası: CMS içerikleri zaten hazırsa scheduled publish ile aynı saate senkronlanır
Rollback ve versiyonlama “ne zaman devreye girer?”
- •İçerik hatası: CMS version history’den önceki sürüme dön (rollback content)
- •Tasarım hatası: release rollback (deployment rollback) + CDN purge/revalidate kontrolü
- •Kampanya döneminde: “geri alma” için önceden etiketlenmiş sürüm çok kritik
- •☑ Mini Check:
- •İçerik rollback ile deploy rollback ayrımı net mi?
- •Lansman günü içerik ve deploy senkron mu?
- •Staging’de UAT yapılmadan prod’a çıkılıyor mu?
Ne yapmalıyım?
- • İçerik değişikliği vs deploy değişikliğini iki farklı süreç olarak dokümante et.
- • Lansman takviminde “deploy saati” ve “scheduled publish”i eşleştir.
- • Rollback için “son iyi sürüm” etiketlemesi yap.
- • Staging UAT’yi zorunlu kıl (özellikle kampanya/landing).
- • Olay anında kimin karar vereceğini (incident owner) belirle.
4. Otel ve B2B İçin Örnek Yayın Senaryoları
Bu bölüm, teoriyi gerçek hayata çevirir: otelde sezon baskısı, B2B’de lansman/landing disiplini. Her iki tarafta da workflow yoksa kritik değişiklikler prod’da denenir ve geri alma karmaşıklaşır.
Otel senaryosu — sezonluk kampanya yayını
- •Kampanya landing + görseller staging’de kontrol edilir
- •CMS içerikleri draft→review’den geçer
- •Revenue/finance kritik alanları onaylar (fiyat/koşul)
- •Scheduled publish ile lansman saati planlanır
- •Publish sonrası: cache/revalidation kontrol edilir (özellikle kampanya sayfası)
Mini örnek: Belek’te erken rezervasyon kampanyası; metin ve görseller hazır, landing bileşenleri staging’de test edildi; yayın zamanı geldiğinde “tek tıkla canlı” stres olmadan gerçekleşir.
Otel senaryosu — yeni oda tipi yayını
- •Oda sayfası + galeri + özellikler staging’de preview’lanır
- •İç linkler (oda→paket) doğrulanır
- •SEO alanları (meta, OG) tamamlanmadan publish edilmez
B2B senaryosu — yeni hizmet/landing yayını
- •Yeni hizmet sayfası tasarımı staging’de UAT
- •CMS içerik blokları review’dan geçer (vaat/kanıt kontrolü)
- •SMM/Ads lansmanı ile aynı zamanlamaya bağlanır (tutarlılık)
- •☑ Mini Check:
- •Kampanya sayfalarında “kritik alan onayı” var mı?
- •Yeni oda/hizmet sayfasında SEO alanları publish gate’e bağlı mı?
- •Lansman SMM planı ile yayın saati eşleşiyor mu?
Ne yapmalıyım?
- • Otelde kampanya ve fiyat alanlarını “kritik” ilan et; ek onay ekle.
- • Yeni oda/hizmet sayfalarında UAT + SEO gate zorunlu yap.
- • Scheduled publish’i standart hale getir (lansman takvimi).
- • Publish sonrası hızlı kontrol listesi uygula (link, görsel, form).
- • Rollback planını her lansman öncesi test et.
5. Rakip Açığını Kapat: “Canlıda Deneme”yi Sistemsel Olarak Bitir
Workflow’u olmayan panellerde kritik değişiklikler canlıda denenir ve geri alma karmaşıklaşır. Oysa sorun “dikkatsizlik” değil, sistemdir: staging yoktur, preview yoktur, onay yoktur, rollback yoktur. Bu rehberin farkı; ortamları ve yayın adımlarını bir “governance modeli” olarak ele alıp; ajans ve kurum ekiplerinin aynı prosedürde buluşmasını sağlamasıdır.
Ne yapmalıyım?
- • Ortamları net ayır (dev/staging/prod + preview).
- • Draft→review→publish kuralını esnetme.
- • Publish gate ve checklist’i zorunlu yap.
- • Rollback’i hem içerik hem deploy için hazır tut.
- • 365 döngüsünde workflow’u versioned güncelle.
6. Sonuç: Stabil site = iyi süreç + doğru ortam + hızlı geri alma
Düzenli workflow ve ortam yapısı olan projelerde, canlıda görülen “tasarım bozulması” ve “yanlış içerik yayını” vakalarının sayısı genelde ciddi ölçüde düşer. Draft–review–publish akışı ve staging/preview standardı; ekibin hızını düşürmez, hatayı ve paniği azaltır. Rollback ve versiyon geçmişi ise “kaza olursa ne yapacağız?” sorusunu önceden çözer.
7. CMS Draft–Review–Publish & Ortam Planlama Şablonunu İndir— Yazılım / CMS yayın workflow modeli (v1.0)
Sezonluk/Lansman Sosyal Medya Strateji Dokümanı Şablonunu İndir — Kampanya Doc (v1.0)
Bu şablon, CMS ortamlarını (preview/staging/prod) ve draft→review→publish yayın akışını standartlaştırarak “canlıda deneme” riskini ortadan kaldırmayı hedefler. Ajans ve kurum ekiplerinin aynı prosedürde buluşmasını sağlar; kampanya ve lansman dönemlerinde rollback-ready yayın disiplini kurar.
Kim Kullanır?
Ajans proje yöneticisi, IT/ürün lideri, içerik lideri, pazarlama yöneticisi.
Nasıl Kullanılır?
- Ortamları ve erişim yetkilerini doldurun (kim nerede ne yapar?).
- Workflow adımlarını ve publish gate kurallarını içerik tiplerine göre tanımlayın.
- Lansman senaryoları ve rollback planını ekleyip ekipçe imzalayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Ortam haritası + erişim yetkileri
- ▢ ✅ Workflow ve publish gate dokümanı
- ▢ ✅ Lansman takvimi + rollback prosedürü
- ▢ ✅ UAT checklist + sorumluluk matrisi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Canlıda deneme riskini bitirip otel ve B2B projelerinde yayın güvenliğini artırın.