Preview Ortamlarının Gerçek Maliyeti
Preview ortamlarının maliyeti ekip büyüklüğüne değil, açık pull request sayısına göre artar. Harcamaların nerede gizlendiğini, hangi bölümlerin paylaşılabileceğini ve beş açık PR'ın beş ayrı stack'e dönüşmesini önlemek için preview ortamlarının nasıl sonlandırılacağını öğrenin.
Preview ortamları, bir ekibin devreye alabileceği ve en yüksek getiriyi sağlayan özelliklerden biridir. Reviewer, bir bağlantıya tıklayıp değişikliği kullanabilir; diff'i okuyup sonucu hayal etmek zorunda kalmaz. Tasarım sorunları merge işleminden önce yakalanır. QA bir aşama olmaktan çıkar.
Ancak preview ortamları, faturanızı sessizce üç katına çıkarma ihtimali en yüksek kalemdir. Bunun nedeni, bu özelliği etkinleştirirken kimsenin o anda yapmadığı basit bir aritmetiktir.
Aritmetik
Preview ortamı maliyeti, ekipteki kişi veya merge sayısına göre değil, açık pull request sayısına göre artar.
Sağlıklı bir review kültürüne sahip dört kişilik bir ekipte, herhangi bir anda beş ila sekiz PR açık olabilir. Her biri stack'inizin tam bir kopyasını oluşturuyorsa production ortamının yanında beş ila sekiz production kopyası çalıştırıyorsunuz demektir. Çalıştırma maliyeti aylık 30 $ olan bir stack'in maliyeti artık 180–270 $'a çıkar. Üstelik bu maliyetin hiçbiri kimsenin tahmininde yer almaz; çünkü tahmin tek bir ortam üzerinden yapılmıştır.
Daha kötüsü, açık PR'lar genellikle sürprizleri en az karşılayabileceğiniz dönemlerle çakışır: release öncesi, bir refactor sırasında veya birinin tatilde olduğu ve branch'inin üç hafta boyunca açık kaldığı zamanlar.
Para gerçekte nereye gidiyor?
Preview'ın her bölümü aynı maliyete sahip değildir. Hangisinin ne kadar maliyet oluşturduğunu bilmek, maliyeti kontrol edilebilir hâle getirir.
Application container'ları — orta düzey maliyetli ve kullanmaya değer. Gerçekten istediğiniz bölüm budur. Ayrıca iyi ölçeklendirilebildiği için maliyeti düşürmek kolaydır; çünkü bir preview'ın production kadar memory'ye ihtiyacı yoktur.
Database'ler — pahalı bölüm. Her preview için dedicated database oluşturmak, toplam maliyete en fazla katkıda bulunan kalemdir ve genellikle en az gerekli olanıdır. Çoğu review izole bir database'e değil, gerçekçi veriler içeren bir database'e ihtiyaç duyar.
Build dakikaları — görünmez ve birikimli. Açık bir PR'a yapılan her push yeni bir build başlatır. İki hafta içinde kırk commit alan bir branch kırk kez build edilir. Bu, çalışan bir resource olarak görünmeyen gerçek bir harcamadır; bu nedenle zihinsel maliyet denetiminden tamamen kaçar.
Egress — preview başına küçük, toplamda büyük. Preview URL'leri keşfedilir ve crawl edilir. Sekiz preview ortamındaki asset'lerinizi çeken bir crawler, production'da yaptığı işin sekiz katını yapar ve bunun tamamı için ödeme yaparsınız.
Değeri kaybetmeden maliyeti azaltan dört yöntem
Database'i paylaşın
Değişikliklerin çoğunda preview'lar, temsili verilerle seed edilmiş tek bir database'i paylaşabilir. İzole database'leri yalnızca gerçekten ihtiyaç duyan PR'lar için ayırın — migration'lar, schema değişiklikleri ve yıkıcı işlemler.
Pratikte işe yarayan kural şu: Yalnızca PR schema'ya dokunuyorsa izole database kullanın. Diğer her şey paylaşır.
Preview'ı küçültün
Tek bir reviewer'a hizmet veren bir preview'ın production kaynaklarına ihtiyacı yoktur. Memory'nin yarısı ve CPU'nun bir kısmı genellikle review yapan kişi tarafından fark edilmez, ancak maliyeti önemli ölçüde düşürür.
dockup resources my-project/my-api --memory 512 --cpu 0.5
Sürelerini sonlandırın
En yüksek etkiye sahip değişiklik budur. Bir preview, pull request'inden daha uzun süre yaşamamalıdır.
Merge veya close sonrasında otomatik teardown artık temel bir gerekliliktir. Ekipleri hazırlıksız yakalayan durum ise terk edilmiş PR'lardır — birinin açtığı, daha sonra ilgisini kaybettiği ve hiç kapatmadığı branch'ler. Bu ortamlar aylarca çalışır.
Maksimum yaş sınırı, sahip olmaya değer bir güvenlik mekanizmasıdır: örneğin on dört günden eski tüm preview'lar, PR durumu ne olursa olsun kaldırılır. Birinin yeniden ihtiyacı olursa tek bir komutla geri oluşturulabilir.
Arama sonuçlarından çıkarın
Preview URL'leri index'lenir. Bu iki nedenle kötüdür — production sitenizle rekabet eden duplicate content oluşur ve kimsenin kullanmadığı ortamlarda crawler trafiği meydana gelir; bunun ücretini de siz ödersiniz.
dockup noindex my-project/my-api --on
Dockup'ta PR preview'ları service bazında yönetilir ve devre dışı bırakılabilir. Böylece miras alınan global bir setting'e bağlı kalmazsınız:
dockup pr-preview my-project/my-api --on
dockup preview list my-project/my-api --json
dockup preview delete 128 my-project/my-api
Ekiplerin atladığı ve sonradan pişman olduğu bölüm, bu ortamları listelemektir. Listeleyemediğiniz ortamlar, farkında olmadan ücretini ödediğiniz ortamlardır.
Ayda bir yapmaya değer denetim
Üç soru, beş dakika:
- Kaç preview çalışıyor? Bunu gerçekten açık olan PR sayısıyla karşılaştırın.
- En eskisi ne kadar süredir çalışıyor? İki haftayı geçen herhangi bir ortam neredeyse kesinlikle terk edilmiştir.
- Hangilerinin kendine ait database'i var? Schema değişikliği olmayanların çoğunun ayrı bir database'e ihtiyacı yoktur.
Çoğu ekip, aylar önce merge edilmiş bir PR'a ait en az bir ortam bulur; bu ortam hâlâ çalışıyor ve faturalandırılmaya devam ediyordur.
Sürprizlerle karşılaşmadan değer elde etmek
Bunların hiçbiri preview ortamlarına karşı bir argüman değildir. Asıl mesele, onları bir checkbox gibi değil, yaşam döngüsüne sahip bir infrastructure olarak ele almaktır.
Bu işi doğru yapan ekipler üç şey yapar: preview'ları küçültür, preview'ların süresini sonlandırır ve güvenle paylaşabilecekleri kaynakları paylaşır. Bu yaklaşım genellikle tüm preview footprint'ini tek bir production service'inin maliyetinin altında tutar — bu da preview kullanmanın açıkça değerli olduğu noktadır.
Sürprizlerle karşılaşan ekipler ise bu özelliği bir kez, doğru şekilde etkinleştirip listeye bir daha hiç bakmayanlardır.
Sık sorulan sorular
Preview ortamları production kadar maliyetli midir? Her ortam aynı şekilde provision edilirse maliyetleri production kadar olabilir. Kaynakları küçültülmüş ve database'i paylaşan bir preview, genellikle production maliyetinin küçük bir bölümüne mal olur.
Her preview'ın kendine ait bir database'i olmalı mı? Yalnızca değişiklik schema'ya dokunuyorsa. Seed edilmiş tek bir database'i paylaşmak, çoğu review için yeterlidir ve en büyük maliyet kalemini ortadan kaldırır.
PR kapandığında preview'a ne olur? Otomatik olarak destroy edilmelidir. Aksi hâlde kimsenin hatırlamadığı PR'lardan kalan ortamlar birikir.
Preview ortamları SEO'ya zarar verir mi?
Index'lenirlerse zarar verebilirler — production sayfalarınızla rekabet eden duplicate content oluştururlar. Onları noindex olarak işaretleyin; bu işlem crawler'ların sizin ücretini ödediğiniz trafiği oluşturmasını da engeller.