Geliştirici VPS İş Akışı Örneği: Güvenle Yayınlayın
9 Ağustos 2026 tarihinde yayınlandı
Bir üretim sürümü, parmaklar çapraz halde açılmış bir SSH oturumu değil, kontrollü bir devretme süreci olmalıdır. Bu geliştirici VPS iş akışı örneği küçük bir web uygulaması kullanır, ancak aynı desen ajans siteleri, SaaS hizmetleri, API'ler ve e-ticaret mağazaları için de geçerlidir: uygulamayı sunucu kurulumundan ayırın, tekrarlanabilir bir sürüm dizinine dağıtın, sistem sağlığını doğrulayın ve hızlı bir geri alma yolu bırakın.
Amaç, sırf prosedür olsun diye fazladan resmiyet eklemek değildir. Amaç, sıradan işleri öngörülebilir hale getirmektir. Bir geliştirici değişiklikleri hızlıca yayınlayabilirken, VPS de güvenli, gözlemlenebilir, yedekli ve birinin uyuması gerektiğinde sakin kalır.
VPS temel yapılandırması ilk dağıtımdan önce gelir
Desteklenen bir Linux sürümü çalıştıran yeni bir KVM VPS ile başlayın. root olmayan bir dağıtım kullanıcısı oluşturun, bir SSH anahtarı ekleyin, uygun olduğunda parola kimlik doğrulamasını devre dışı bırakın ve SSH erişimini bir güvenlik duvarıyla sınırlayın. Kurtarma için root erişimi mevcut olmalıdır, ancak rutin dağıtımlarda kullanılan hesap bu olmamalıdır.
Yalnızca uygulamanın ihtiyaç duyduğu hizmetleri kurun. Tipik bir Node.js, Python, PHP veya Ruby uygulamasında bu çoğu zaman Nginx, dil çalışma zamanı, bir süreç yöneticisi ve bir veritabanı istemcisi anlamına gelir. Uygulamanın anlamlı trafiği, hassas verileri veya basit bir sitenin ötesinde bir kurtarma gereksinimi varsa veritabanını yönetilen bir hizmette ya da ayrı bir VPS üzerinde tutun. Erken aşamadaki bir proje için her şeyi tek bir küçük sunucuya koymak geçerlidir, ancak bu hata alanlarını birleştirir. Böylece tek bir disk sorunu herkesin sorunu haline gelir.
Sunucunun saat dilimini ayarlayın, değişiklik politikanıza uyuyorsa otomatik güvenlik güncellemelerini etkinleştirin ve günlük döndürmeyi yapılandırın. VPS sınırlı belleğe sahipse bir swap dosyası ekleyin, ancak swap alanını ek RAM gibi değerlendirmeyin. Bir hizmet sürekli swap kullanıyorsa ayarlama, daha fazla bellek veya daha az iş yükü gerekir.
Pratik bir dizin düzeni, işletim sistemini, paylaşılan verileri ve kod sürümlerini ayrı tutar:
```text /srv/myapp/ current -> /srv/myapp/releases/2026-08-09-1420 releases/ shared/ .env uploads/ logs/ ```
`shared` dizini, bir kod sürümünden sağ çıkması gereken öğeleri barındırır: ortam değişkenleri, kullanıcı yüklemeleri, gerekiyorsa kalıcı önbellekler ve günlükler. Her dağıtım yeni bir zaman damgalı sürüm oluşturur. `current` sembolik bağlantısı, Nginx'i veya uygulama hizmetini etkin sürüme yönlendirir.
Adım adım bir geliştirici VPS iş akışı örneği
İş akışı üretim sunucusunda değil, kaynak kontrolde başlar. Her üretim sürümü bir commit SHA'sına veya sürüm etiketine karşılık gelmelidir. Bir değişiklik sonradan tanımlanamıyorsa güvenle geri alınamaz, incelenemez veya müşteriye açıklanamaz.
1. Kod VPS'ye ulaşmadan önce derleyin ve test edin
Bir geliştirici bir dalı gönderir, bir inceleme açar ve yalnızca otomatik testler geçtikten sonra üretim dalına birleştirir. Derleme süreci, üretimde çalışacak tam yapıtı oluşturmalıdır. Derlenmiş ön yüzler için bu, oluşturulan varlık paketidir. Konteynerleştirilmiş bir hizmet için bu, değiştirilemez bir imajdır. Geleneksel bir sunucu dağıtımı için bu, bağımlılıkları kilitlenmiş bir sürüm arşivi olabilir.
Mümkün olduğunda, sabitlenmemiş bağımlılık kurulumlarını doğrudan üretim üzerinde çalıştırmaktan kaçının. Bir paket kayıt deposunun iki dağıtım arasında değişmesi, çok gürültülü bir öğleden sonrayı yaratmanın sessiz bir yoludur. Kilit dosyaları ve tekrarlanabilir derlemeler bu riski azaltır.
Gizli bilgileri depo ve derleme çıktısının dışında tutun. Derlemenin yalnızca herkese açık yapılandırmaya ihtiyacı vardır. Veritabanı parolaları, API anahtarları, SMTP kimlik bilgileri ve imzalama anahtarları; VPS üzerinde korunan bir ortam dosyasından veya uygun bir gizli bilgi hizmetinden enjekte edilmelidir.
2. Sürümlendirilmiş bir sürümü aktarın
Bir dağıtım kullanıcısı, onaylanmış yapıtı kısıtlı bir SSH anahtarı, CI çalıştırıcısı veya dağıtım aracı üzerinden alır. Sunucu, `releases` altında yeni bir dizin oluşturur, yapıtı yükler, süreç destekliyorsa sağlama toplamını doğrular ve üretim bağımlılıklarını kurar.
Bu aşamada trafiği henüz değiştirmeyin. Veritabanı geçişlerini bilinçli şekilde çalıştırın. Bazı geçişler yeni kod başlamadan önce güvenle uygulanabilir; diğerleri ise eski ve yeni uygulama sürümlerinin birlikte çalışabildiği bir uyumluluk penceresi gerektirir. Örneğin yoğun kullanılan bir sütunun yeniden adlandırılması, tek bir kahramanca komut yerine birkaç sürüm gerektirebilir.
Düşük riskli uygulamalarda bir geçiş, dağıtımın parçası olarak çalıştırılabilir. İş açısından kritik bir veritabanında ise bunu, test edilmiş bir yedek ve net bir geri alma planıyla onaylı ayrı bir değişiklik adımına dönüştürün. Bu; veri modeline, trafiğe ve işletmenin ne kadar kesintiyi tolere edebileceğine bağlıdır.
3. Sürümü sunucuda yerel olarak kontrol edin
`current` bağlantısını değiştirmeden önce yeni sürümü doğrulayın. Söz dizimi kontrollerini, uygulama sağlık komutlarını ve çerçeveye özgü önbellek oluşturma adımlarını çalıştırın. Gizli değerleri günlüklere yazdırmadan gerekli ortam değişkenlerinin mevcut olduğunu doğrulayın.
Burada hafif bir iç sağlık uç noktası faydalıdır. Sürecin çalıştığını ve veritabanı bağlantısı gibi kritik bağımlılıkların erişilebilir olduğunu doğrulamalıdır. Her istekte pahalı işler yapmasına izin vermeyin. Kendi olayını yaratan bir sağlık kontrolü pek yardımcı olmaz.
4. Trafiği değiştirin ve kesintisiz yeniden yükleyin
Doğrulama başarıyla geçince `current` sembolik bağlantısını atomik olarak güncelleyin ve uygulama sürecini yeniden başlatın veya yeniden yükleyin. Nginx genellikle etkin bağlantıları düşürmeden yapılandırmayı yeniden yükleyebilir. Uygulama davranışı çalışma zamanına bağlıdır: bir süreç yöneticisi kesintisiz yeniden başlatma yapabilirken bazı hizmetler kısa bir yeniden başlatma penceresine ihtiyaç duyar.
Önceki sürüm dizinini olduğu gibi koruyun. Dağıtım kaydı; sürümü, zamanı, operatörü veya CI işini, geçiş durumunu ve sağlık kontrolünün sonucunu içermelidir. Bu, "ne değişti?" gibi belirsiz bir soruyu saniyeler içinde ulaşılabilen bir yanıta dönüştürür.
Geçişten sonra genel uç noktayı sunucu dışından test edin. Beklenen HTTP durumunu, TLS sertifikası davranışını, ilgiliyse giriş veya ödeme akışını ve temsili bir API isteğini kontrol edin. Sunucu içi kontroller faydalıdır, ancak kötü bir DNS kaydı, CDN kuralı veya güvenlik duvarı hatasını yakalayamazlar.
5. Sürümden sonraki ilk dakikaları izleyin
İlk 10 ila 20 dakika, sonraki 10 saatten daha fazla dikkat hak eder. Hata oranlarını, yanıt süresini, CPU'yu, belleği, disk kullanımını ve uygulama günlüklerini izleyin. Kuyruk tabanlı bir uygulamada kuyruk derinliğini ve başarısız işleri de izleyin. Bir e-ticaret mağazasında yalnızca ana sayfayı değil, para kazandıran yolları izleyin.
Ekibiniz eğilim verilerine ve uyarı kurallarına ihtiyaç duyduğunda Prometheus ve Grafana metrikleri değerlidir. Kullanılabilirliği, disk kapasitesini, süreç durumunu ve temel hizmet bağlantı noktalarını kontrol ettiği sürece daha basit bir izleme hizmeti birçok küçük site için yeterlidir. Doğru seçim, sabah 2'de gerçekten birinin yanıt vereceği seçimdir.
Hizmet planına dahil olduğunda Kodu.cloud FASTCARE gibi yönetilen VPS izleme, ek bir operasyonel göz seti sağlayabilir. Bu, uygulama sahipliğinin yerini almaz; ancak dolu bir disk, durmuş bir hizmet veya altyapı sinyalinin bir müşteri bildirene kadar fark edilmeden kalma olasılığını azaltır.
Geri alma sıkıcı olmalıdır
Sağlıklı bir dağıtım süreci, bazı sürümlerin başarısız olacağını varsayar. Doğru yanıt panik ya da canlı bir sunucuda uzun bir hata ayıklama oturumu değildir. `current` öğesini önceki, iyi olduğu bilinen sürüme yeniden yönlendirin, gerekirse uygulamayı yeniden başlatın ve genel sağlık kontrolünü doğrulayın.
Veritabanı değişiklikleri ana istisnadır. Şema geri alma her zaman güvenli değildir; özellikle de yeni sürüm verileri yeni bir biçimde yazdıysa. Geçişleri, geri alma penceresi boyunca eski kod uyumlu kalacak şekilde planlayın. Önce yeni bir sütun ekleyin, gerekirse her iki biçime de yazın, okumaları daha sonra taşıyın ve eski alanları yalnızca değişiklik oturduktan sonra kaldırın.
Tanımlı bir sürüm saklama politikası uygulayın. Yapıtlar kaynak kontrolden yeniden oluşturulabildiği sürece, küçük bir uygulama için son beş ila on sürümü tutmak çoğu zaman yeterlidir. Eski sürümlerin, dağıtımın kendisi başarısız olana kadar VPS diskini tüketmesine izin vermeyin. Günlükler artık aynı hikâyeyi anlatıyor: disk uyarıları, acil temizlikten daha ucuzdur.
Yedekler sürümlerden ayrıdır
Bir sürüm geçmişi yedek değildir. Genellikle veritabanlarını, yüklenen dosyaları, sistem yapılandırmasını veya yanlışlıkla silme ya da ele geçirilmiş bir hesaptan sonra kurtarma için gereken durumu içermez.
Veritabanını, işletmenin kurtarma noktası hedefiyle uyumlu bir takvimde yedekleyin. Tanıtım amaçlı bir site günlük yedeği kabul edebilir. Aktif bir mağaza daha sık veritabanı yedeklerine ve belirli bir zamana geri dönme kurtarmasına ihtiyaç duyabilir. Yedekleri üretim VPS'sinden uzakta saklayın, şifreleyin ve saklama süresini hem iş ihtiyaçlarına hem de uyumluluk yükümlülüklerine göre belirleyin.
En önemlisi, geri yüklemeyi test edin. Bir veritabanını üretim dışı bir ortama geri yükleyin, yakın tarihli bir dosya yedeğini yükleyin ve uygulamanın bunu kullanabildiğini doğrulayın. Hiç geri yüklenmemiş bir yedek, kurtarma planı değil, umut dolu bir dosyadır.
Erişimi ve sahipliği net tutun
Her geliştiriciye ayrı bir SSH anahtarı verin ve sorumluluklar değiştiğinde erişimi kaldırın. Paylaşılan yönetici kimlik bilgilerinden kaçının. CI dağıtım anahtarları yalnızca dağıtım eylemleriyle sınırlandırılmalı ve bir ekip üyesi veya tedarikçi ayrıldığında döndürülmelidir.
Bir olay sırasında önemli olan az sayıdaki ayrıntıyı belgeleyin: uygulamanın nerede bulunduğu, hizmet günlüklerinin nasıl görüntüleneceği, nasıl yeniden başlatılacağı, yedeklerin nerede saklandığı ve bir geri almayı kimin onaylayabileceği. Bu tek bir sayfaya sığabilir. Bu gösterişli bir iş değildir, ama tatildeki birinin dizüstü bilgisayarından üretimin neden elle değiştirildiğini açıklamak da değildir.
En iyi VPS iş akışı, geliştiricileri üretmeye özgür bırakırken sunucunun anlaşılır, kurtarılabilir ve izleniyor durumda kalmasını sağlar. Tekrarlanabilir tek bir dağıtım, test edilmiş tek bir geri yükleme ve gerçek bir insana ulaşan tek bir uyarıyla başlayın. Buradan sonra hizmet, küçük bir gizem makinesine dönüşmeden büyüyebilir.
Andres Saar Müşteri Hizmetleri Mühendisi