Geliştirme ve Test Ortamları İçin Neden Fiziksel Donanım Yerine VDS Tercih Edilmeli?

“Benim bilgisayarımda çalışıyordu.” Yazılım ekiplerinde bu cümle, canlıya alınan bir güncellemenin siteyi bozduğu her seferinde bir kez daha söylenir. Geliştiricinin bilgisayarında PHP 8.3 vardır, canlı sunucuda 8.1. Yerelde veritabanı boştur, canlıda iki milyon kayıt vardır. Test edilmeden canlıya çıkan her değişiklik, gerçek kullanıcıların test kullanıcısı olması demektir.

Bu sorunun çözümü, canlı ortama benzeyen ayrı geliştirme, test ve hazırlık (staging) ortamlarıdır. Bu ortamlar için yıllarca ofisin bir köşesinde uğuldayan eski bir bilgisayar ya da raf sunucusu kullanıldı. Bugün ise çoğu ekip için daha mantıklı yol, geliştirme ortamı için VDS kiralama ile bu ortamları dakikalar içinde ve ihtiyaç kadar kaynakla kurmak.

Bu yazıda farklı ortamların ne işe yaradığını, fiziksel donanımın gözden kaçan maliyetlerini, VDS’in ekiplere sağladığı avantajları ve tek bir VDS üzerinde staging ile CI ortamının nasıl kurulabileceğini somut bir örnekle anlatıyoruz. Fiziksel sunucunun hâlâ daha doğru olduğu durumları da atlamıyoruz.

Geliştirme, test ve staging ortamları neden ayrı olmalı?

Profesyonel bir yazılım sürecinde kod, canlıya ulaşmadan önce birkaç aşamadan geçer. Her aşamanın amacı farklıdır ve hepsinin aynı makinede, hatta canlı sunucuda yapılması, er ya da geç bir kazaya yol açar.

Ortam	Amacı	Kimler kullanır	Kullanılan veri
Geliştirme	Yeni özellik yazmak ve denemek	Geliştiriciler	Örnek veya sahte veri
Test	Otomatik testler ve entegrasyon kontrolleri	CI sistemi, test ekibi	Test verisi
Staging (hazırlık)	Canlıya çıkmadan önce son kontrol	Ekip, ürün sahibi, müşteri	Anonimleştirilmiş canlı kopyası
Canlı (production)	Gerçek kullanıcılara hizmet vermek	Müşteriler	Gerçek veri

Staging ortamı özellikle değerlidir. Canlı ortamın birebir kopyası olduğu için bir veritabanı değişikliğinin iki milyon kayıtlı tabloda ne kadar süreceğini, yeni bir eklentinin mevcut temayla çakışıp çakışmadığını ya da bir güncellemenin ödeme akışını bozup bozmadığını gerçek kullanıcılar etkilenmeden görmenizi sağlar. Ajanslar içinse müşteriye yeni tasarımı canlıya almadan gösterebilecekleri bir vitrin işlevi görür.

Fiziksel donanımın gözden kaçan maliyetleri

Ofiste duran bir sunucu ilk bakışta ucuz görünür. Bir kere alınır ve sonra “bedavaya” çalışır. Gerçekte ise maliyetin büyük kısmı faturada görünmez:

• Bekleme süresi: Donanımın seçilmesi, siparişi, teslimatı ve kurulumu günler, bazen haftalar sürer. Yeni bir proje için ek kaynak gerektiğinde aynı döngü baştan başlar.
• Elektrik, soğutma ve gürültü: 7/24 çalışan bir sunucu fark edilir bir elektrik tüketir, ısı üretir ve sessiz bir ofis ortamında rahatsız edici olabilir.
• Uzaktan erişim: Ekibin evden çalıştığı günlerde sunucuya ulaşmak için sabit IP, port yönlendirme ve VPN gibi ek düzenlemeler gerekir. Her biri ayrı bir güvenlik riski taşır.
• Arıza riski: Disk bozulduğunda ya da güç kaynağı yandığında yedek parça gelene kadar bütün ekip bekler. Bu bekleme, sunucunun maliyetinin çok üzerinde bir iş gücü kaybına dönüşebilir.
• Esneklik eksikliği: Fiziksel makine aldığınız kaynakla sınırlıdır. İhtiyaç arttığında yeni donanım, azaldığında ise atıl kapasite demektir.

Kriter	Ofisteki fiziksel sunucu	VDS
Hazır olma süresi	Günler veya haftalar	Dakikalar
İlk maliyet	Donanım satın alma bedeli	Yok, aylık ödeme
Elektrik, soğutma, gürültü	Sizin sorumluluğunuzda	Veri merkezinde
Uzaktan erişim	Sabit IP, port yönlendirme, VPN	Kendi IP adresiyle doğrudan erişim
Donanım arızası	Ekip parça bekler	Sağlayıcının sorumluluğunda
Ölçekleme	Yeni donanım gerekir	Paket yükseltmesi

VDS’in geliştirme ekiplerine sağladığı avantajlar

Dakikalar içinde hazır bir ortam

Yeni bir müşteri projesi mi başladı? Bir hata yalnızca belirli bir işletim sistemi sürümünde mi ortaya çıkıyor? VDS ile ihtiyaç duyduğunuz ortamı satın alma onayı beklemeden hazırlayabilirsiniz. Önem Bilişim’de VDS siparişleri otomasyon sistemi üzerinden genellikle 5 ile 10 dakika içinde teslim edilir. Proje bittiğinde ise sunucuyu kapatıp maliyeti durdurmak, bir makineyi satmaya çalışmaktan çok daha kolaydır.

Farklı işletim sistemleri, tek tıkla

Bir müşteriniz Ubuntu 20.04 kullanıyor, diğeri AlmaLinux 9. Kurumsal bir projede .NET uygulamasını Windows Server üzerinde test etmeniz gerekiyor. Fiziksel donanımda her biri için ayrı makine ya da karmaşık bir sanallaştırma kurulumu gerekir. VDS’te ise Ubuntu, Debian, AlmaLinux ve Windows Server sürümleri arasından seçim yapıp sunucuyu dakikalar içinde yeniden kurabilirsiniz. Müşterinizin canlı ortamındaki sürümü birebir kopyalamak, “bizde çalışıyor ama sizde çalışmıyor” tartışmalarını büyük ölçüde bitirir.

Kaynak izolasyonu

VDS’te işlemci, RAM ve disk size ayrılmıştır. Yoğun bir yük testi ya da uzun süren bir derleme, başka bir projenin test ortamını yavaşlatmaz. Daha da önemlisi test ortamınız canlı sunucunuzdan tamamen ayrıdır. Test sırasında yaşanacak bir bellek taşması ya da yanlışlıkla çalıştırılan bir komut, canlı siteye dokunmaz.

Temiz kurulum ve yedekten geri dönüş

Test ortamlarının doğası gereği bozulmaları normaldir. Bir paket güncellemesi bağımlılıkları karıştırabilir, yanlış bir yapılandırma servisi kilitleyebilir. Bu durumda saatlerce sorun gidermek yerine sunucuyu temiz bir imajdan yeniden kurmak çoğu zaman en hızlı çözümdür. Kurulum adımlarını bir betikte ya da Ansible gibi bir araçta tutarsanız, sıfırdan çalışan bir ortama birkaç dakikada dönebilirsiniz. Staging ortamındaki verilerin günlük yedeği için Önem Bilişim’in ek olarak alınabilen Sunucu Yedekleme hizmetinden yararlanabilirsiniz.

Ekip erişimi ve yetkilendirme

Uzaktan çalışan bir ekip için VDS’in kendi IP adresiyle internete açık olması büyük kolaylıktır. Her geliştiriciye ayrı kullanıcı ve SSH anahtarı tanımlayarak kimin ne zaman bağlandığını takip edebilir, ekipten ayrılan birinin erişimini tek satırla kaldırabilirsiniz. Veritabanı yönetim arayüzü gibi yalnızca ekibin görmesi gereken servisleri bir VPN arkasına almak da mümkündür. Bunun için kendi VPN sunucunuzu VDS üzerinde kurma rehberimize göz atabilirsiniz.

Canlı ortama benzerlik

Staging ortamının değeri, canlıya ne kadar benzediğiyle ölçülür. Canlı siteniz bir VDS’te çalışıyorsa staging ortamını aynı işletim sistemi, aynı PHP veya Node.js sürümü ve aynı web sunucusuyla kurmak kolaydır. Böylece staging’de geçen bir testin canlıda da geçeceğine çok daha fazla güvenebilirsiniz.

Örnek kurulum: Tek bir VDS üzerinde staging ve CI

Küçük ve orta ölçekli ekipler için tek bir VDS üzerinde birden fazla staging ortamı ve bir CI çalıştırıcısı barındırmak hem ekonomik hem yönetilebilir bir çözümdür. Örnek yapı şöyle:

1. Kod deposuna (GitHub veya GitLab) yapılan her gönderimde CI çalıştırıcısı testleri çalıştırır ve uygulamanın Docker imajını oluşturur.
2. develop dalındaki değişiklikler, testler geçtikten sonra otomatik olarak staging ortamına dağıtılır.
3. Staging ortamına staging.ornekproje.com gibi bir alt alan adıyla, yalnızca ekibin bildiği bir parolayla erişilir.
4. Ekip ve müşteri onay verdikten sonra aynı imaj canlı ortama alınır.

İlk adım olarak sunucuya Docker’ı kurun ve kendi kullanıcınızı Docker grubuna ekleyin:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker deploy

Ardından uygulamanızı, veritabanını ve web trafiğini yöneten ters vekil sunucuyu (reverse proxy) tek bir Docker Compose dosyasında tanımlayabilirsiniz. Aşağıdaki örnekte Caddy, HTTPS sertifikalarını Let’s Encrypt üzerinden otomatik olarak alır:

services:
  app:
    image: ghcr.io/sirket/proje:develop
    restart: unless-stopped
    env_file: .env.staging
    depends_on:
      - db
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: proje
      MARIADB_USER: proje
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - db-verisi:/var/lib/mysql
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-verisi:/data
volumes:
  db-verisi:
  caddy-verisi:

Veritabanının portu dışarıya açılmaz. Uygulama, veritabanına Docker’ın iç ağı üzerinden ulaşır. Caddy yapılandırmasında ise iki önemli güvenlik ayarı bulunur:

staging.ornekproje.com {
    basic_auth {
        ekip PAROLA_HASH_DEGERI
    }
    header X-Robots-Tag "noindex, nofollow"
    reverse_proxy app:8080
}

basic_auth satırı, staging ortamını parola korumasına alır. Parola özetini caddy hash-password komutuyla üretebilirsiniz. X-Robots-Tag başlığı ise arama motorlarına bu sayfaları dizine eklememelerini söyler. Bu ayar sanıldığından daha önemlidir. Google’ın dizinine giren bir staging sitesi, canlı sitenizle yinelenen içerik oluşturur, arama sonuçlarında rakip haline gelir ve henüz yayınlanmamış çalışmalarınızı herkese açar.

CI tarafında GitHub kullanıyorsanız deponuzun ayarlarındaki “Actions > Runners” bölümünden sunucunuzu kendi barındırdığınız (self-hosted) bir çalıştırıcı olarak ekleyebilirsiniz. GitLab’da aynı işi gitlab-runner register komutu yapar. Dağıtım adımı ise çoğu zaman tek satırdır: docker compose pull && docker compose up -d. Docker ile çoklu servis mimarilerinin VDS üzerinde nasıl yapılandırılacağını Docker ve mikroservis mimarileri için VDS yapılandırması yazımızda daha ayrıntılı ele aldık.

Staging ortamında performans ve yük testi

Staging ortamı yalnızca “çalışıyor mu” sorusuna değil, “yük altında nasıl çalışıyor” sorusuna da cevap verebilir. Kampanya öncesinde bir e-ticaret sitesini, yayına çıkmadan önce yeni bir mobil uygulamanın API’sini ya da büyük bir veritabanı değişikliğini canlı ortamı riske atmadan test etmenin en güvenli yeri burasıdır.

Bunun için staging sunucusunun kaynaklarının canlıya yakın olması gerekir. 2 GB RAM’li bir test sunucusunda alınan sonuçlar, 16 GB RAM’li canlı sunucu için anlamlı bir tahmin vermez. VDS’in esnekliği burada da işe yarar. Yük testinden önce staging sunucusunu geçici olarak canlıyla aynı boyuta yükseltebilir, testi tamamladıktan sonra ihtiyaçlarınızı yeniden değerlendirebilirsiniz. Kampanya dönemleri için yük testinin nasıl planlanacağını e-ticaret siteleri için VDS seçimi yazımızda adım adım anlattık.

Örnek senaryo: Ofis sunucusundan VDS’e geçen bir ajans

Somut bir örnek üzerinden düşünelim. On iki müşterinin web sitesini yöneten beş kişilik bir ajans, yıllardır ofisteki eski bir sunucuyu test ortamı olarak kullanıyor. Müşterilere yeni tasarımları göstermek için port yönlendirmeyle açılan karmaşık adresler kullanılıyor. Evden çalışan geliştiriciler her sabah VPN bağlantısıyla uğraşıyor. Sunucunun diski bir gün arızalandığında ise ekip iki gün boyunca test yapamıyor.

Ajans bu yapıyı iki VDS ile yeniden kuruyor. Birincisi, her müşterinin staging ortamını Docker ile ayrı bir alt alan adında çalıştırıyor: musteri1.staging.ajans.com, musteri2.staging.ajans.com gibi. Bütün ortamlar parola korumalı ve arama motorlarına kapalı. İkinci VDS ise CI çalıştırıcısı olarak testleri ve derlemeleri üstleniyor, böylece derleme yükü staging ortamlarını yavaşlatmıyor.

Sonuçta müşteriler yeni tasarımları tek bir linkle görebiliyor, ekip ofise bağlı kalmadan çalışıyor, bozulan bir test ortamı ise dakikalar içinde yeniden kuruluyor. Ajans ayrıca yeni donanım satın alma ihtiyacından kurtuluyor ve maliyetini aylık olarak öngörebiliyor.

Test ortamında veri güvenliği ve KVKK

Staging ortamını canlıya benzetmenin en kolay yolu canlı veritabanını olduğu gibi kopyalamaktır. Ancak bu, en sık yapılan hatalardan biridir. Test ortamları genellikle canlı ortam kadar sıkı korunmaz. Daha fazla kişinin erişimi vardır, parolalar daha basittir ve kayıtlar daha az izlenir. Müşterilerinizin adları, telefonları ve adresleri bu ortamda da kişisel veridir. 6698 sayılı Kişisel Verilerin Korunması Kanunu’ndan doğan sorumluluklar test sunucusunda da devam eder.

Pratik bir yaklaşım şöyledir:

• Canlı veritabanını staging’e aktarırken ad, e-posta, telefon ve adres alanlarını maskeleyin ya da sahte verilerle değiştirin.
• Mümkün olduğunda gerçek veri yerine, gerçekçi ama tamamen sahte veri üreten araçlar kullanın.
• Staging ortamına erişimi yalnızca ihtiyacı olan kişilerle sınırlayın ve işi biten ortamlardaki verileri silin.
• Ödeme altyapılarını staging’de yalnızca test modunda kullanın, gerçek kart bilgisi asla bu ortama girmesin.

Fiziksel sunucu ne zaman daha mantıklı?

Her durumda VDS doğru cevap değildir. Şu senaryolarda fiziksel donanım ya da adanmış bir sunucu daha uygun olabilir:

• GPU gerektiren işler: Makine öğrenmesi modeli eğitmek veya görüntü işleme gibi işlerde güçlü bir ekran kartı gerekir.
• Donanıma bağlı lisanslar ve cihazlar: USB donanım anahtarıyla çalışan yazılımlar ya da özel çevre birimleri sanal ortamda sorun çıkarabilir.
• 7/24 tam yükte çalışan ağır işler: İşlemcinin sürekli yüzde 100’de çalıştığı büyük derleme çiftlikleri için, kaynak başına maliyet bakımından adanmış bir fiziksel sunucu daha avantajlı hale gelebilir.
• Kendi sanallaştırma laboratuvarınız: Proxmox, ESXi veya Kubernetes kümeleri üzerinde deneme yapmak istiyorsanız, iç içe sanallaştırmayı destekleyen sunucular ara bir çözüm sunar. Bu yaklaşımı Kubernetes lab’leri ve konteyner testleri için nested sunucu yazımızda anlattık.

Bu istisnaların dışında kalan web uygulamaları, API’ler, mobil uygulama arka uçları, kurumsal yazılımlar ve otomasyon projeleri için VDS hem daha hızlı başlamanızı hem de daha az yönetim yükü taşımanızı sağlar.

Geliştirme ve test için kaynak önerileri

Test ortamı kaynakları canlı ortam kadar büyük olmak zorunda değildir. Ancak staging ortamında performans testi yapacaksanız, canlıya ne kadar yakın olursa sonuçlar o kadar anlamlı olur. Aşağıdaki tablo genel bir başlangıç noktası sunar:

Kullanım	Önerilen başlangıç	Not
Tek geliştirici, birkaç küçük proje	2 vCPU, 4 GB RAM, SSD	Docker ile birkaç hafif servis
Küçük ekip: staging ve CI çalıştırıcısı	4 vCPU, 8 GB RAM, NVMe	Derleme süreleri için NVMe fark yaratır
Yoğun derleme, çok sayıda konteyner	6–8 vCPU, 16 GB RAM, NVMe	Yüksek frekanslı işlemci tercih edin
Windows tabanlı .NET test ortamı	4 vCPU, 8 GB RAM	Windows Server sürümü seçilebilir

Derleme işlemlerinin önemli bir kısmı tek çekirdekte çalışır. Bu yüzden çekirdek sayısı kadar çekirdek hızı da önemlidir. Yüksek frekanslı AMD Ryzen 9 işlemcili VDS’ler, CI çalıştırıcıları ve derleme sunucuları için bu açıdan avantajlıdır. Disk tarafında ise npm install ve docker build gibi binlerce küçük dosyayla çalışan işlemler NVMe’den doğrudan faydalanır. Projenize uygun kaynağı seçmek için geliştirme ekipleri için hazırlanmış VDS kiralama paketlerine göz atabilirsiniz.

Maliyeti kontrol altında tutmak için ipuçları

VDS’in esnekliği, dikkat edilmezse kullanılmayan sunucuların birikmesine de yol açabilir. Birkaç alışkanlık bunu önler:

• Ortamları birleştirin: Her proje için ayrı sunucu açmak yerine, küçük projelerin staging ortamlarını Docker ile tek bir VDS üzerinde alt alan adlarıyla çalıştırın.
• İşi biteni kapatın: Müşteri onayı alınmış ve canlıya çıkmış projelerin geçici test ortamlarını düzenli olarak gözden geçirin.
• Küçük başlayın: Kaynak ihtiyacından emin değilseniz küçük bir paketle başlayın. Önem Bilişim’de VDS kaynakları verileriniz silinmeden yükseltilebilir ve ücretlendirmede kalan gün farkı hesaba katılır.
• Otomasyona yatırım yapın: Ortam kurulumunu betiklerle tanımlamak, sunucuyu gerektiğinde silip birkaç dakikada yeniden kurmanızı sağlar.

Sık Sorulan Sorular

Test ortamı ile staging ortamı arasındaki fark nedir?

Test ortamı, otomatik testlerin ve entegrasyon kontrollerinin çalıştığı, sık sık bozulup yeniden kurulabilen bir alandır. Staging ise canlı ortamın birebir kopyasıdır ve canlıya çıkmadan önceki son kontrol için kullanılır. Staging’in değeri canlıya ne kadar benzediğiyle ölçülür.

Geliştirme ortamı için kaç GB RAM gerekir?

Tek geliştiricinin birkaç küçük projesi için 4 GB RAM genellikle yeterlidir. Docker ile çok sayıda servis çalıştıran ya da CI çalıştırıcısı barındıran ekip sunucuları için 8 ile 16 GB daha rahat bir çalışma alanı sağlar.

Staging sitemin Google’da görünmesini nasıl engellerim?

En güvenli yöntem staging ortamını parola korumasına almaktır. Buna ek olarak sunucu yanıtlarına X-Robots-Tag: noindex başlığı ekleyin. Yalnızca robots.txt dosyasına güvenmeyin. Bu dosya taramayı engeller ama başka sitelerden link alan bir sayfanın dizine eklenmesini her zaman önlemez.

Fiziksel sunucu yerine VDS kullanmak güvenli mi?

Evet. VDS’ler sanallaştırma katmanıyla birbirinden yalıtılmıştır ve veri merkezindeki fiziksel güvenlik, ofisteki bir sunucuya göre genellikle çok daha yüksektir. Güvenliği asıl belirleyen, SSH ayarları, güvenlik duvarı ve güncellemeler gibi sizin yapacağınız yapılandırmalardır.

Aynı VDS’te hem test hem canlı ortam çalıştırabilir miyim?

Teknik olarak mümkündür ama önerilmez. Test sırasında yaşanacak bir kaynak tüketimi ya da hatalı bir komut canlı siteyi etkileyebilir. Canlı ortamı ayrı bir VDS’te tutmak, test ortamlarını ise ayrı bir sunucuda birleştirmek hem güvenli hem ekonomik bir dengedir.