☑ 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.
Bu nedenle web ve yazılım hizmetlerinde CMS yayın ortamları, yalnız teknik deployment alanları değil; içerik, tasarım, onay ve kalite kontrolün birlikte işlendiği operasyonel güvenlik katmanı olarak düşünülmelidir.
- •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ı.
Bu ayrımın sahada işlemesi için CMS yayın onay akışı tarafında rol, yetki ve yayın sorumluluğu net tanımlanmalıdır.
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.
Sürecin ekip içinde aynı şekilde uygulanabilmesi için editörler için preview review publish süreci standartlarının onboarding aşamasında verilmesi büyük fark yaratır.
- •Ö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:
Bu kapının en kritik parçalarından biri de publish öncesi teknik SEO kontrolü olup meta, canonical, URL, sitemap ve structured data gibi alanların yayından önce doğrulanmasını sağlar.
- •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.
Özellikle preview aşamasında preview aşamasında UI/UX kontrolü, mobil görünüm, CTA yerleşimi, form davranışı ve kullanıcı akışındaki kırılmaları yayından önce görünür hale getirir.
İç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
Bu senkronizasyonun otomatik ilerlemesi için publish sonrası webhook otomasyonu, yayın sonrası build, bildirim, cache temizleme veya revalidation adımlarını tetikleyebilir.
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)
Bu nedenle lansman tarihleri, scheduled publish kurgusu ve reklam yayını aynı ritimde ilerlemeli; kampanya içerikleri için içerik yayın akışı CMS takvimiyle birlikte yönetilmelidir.
- •☑ 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.
Bu yapıyı kalıcı hale getirmek için yayın akışı güçlü CMS entegrasyonu desteği alabilir, süreç ve kurulum tarafındaki detay sorular için de CMS entegrasyonu hakkında sık sorulan sorular sayfasını inceleyebilirsiniz.
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.