Git Repository'den Production'a: Dockup Deployment Rehberi

Bir Git repository'sini production'a taşımak, yalnızca bir remote bağlayıp deploy düğmesine basmaktan fazlasını gerektirir. Platformun service hedefini, branch'i, build yöntemini, start komutunu, listening port'unu, environment'ı, health gate'i ve recovery yolunu bilmesi gerekir. Dockup, hem otomatik Nixpacks build'lerini hem de repository tarafından yönetilen Dockerfile'ları desteklerken bu kararları açıkça belirlemenizi sağlar.

Bu rehber, daha önce hiç deploy edilmemiş bir repository ile başlar; doğrulanmış bir URL, deployment history, log'lar ve test edilmiş bir rollback komutuyla sona erer.

İlk production deploy'undan önce neler kontrol edilmeli?

Repository'nin belgelenmemiş local state olmadan deploy edilebildiğini doğrulayın. Temiz bir clone, secret'lar dışında dependency'leri yüklemek ve uygulamayı başlatmak için gereken her şeyi içermelidir.

Şu checklist'i kullanın:

Kontrol	Beklenen sonuç
Default branch	Hedeflenen production branch'i mevcut
Dependency lockfile	Reproducible install'lar için commit edilmiş
Start process	Yapılandırılan port'a ve 0.0.0.0 adresine bind oluyor
Health route	Harici side effect oluşturmadan başarı döndürüyor
Database migration'ları	Açık ve güvenli bir çalıştırma planına sahip
Secret'lar	Git dışında saklanıyor
Persistent dosyalar	Container filesystem'ı yerine volume kullanıyor
Rollback	Önceki deployment yeniden çalıştırılabiliyor

CLI'ı yükleyip authenticate olun:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Bir şey oluşturmadan önce mevcut service'leri listeleyin:

dockup services --json

Bu işlem duplicate resource oluşturmanızı önler ve doğru workspace ile target convention'ını doğrular.

Dockup create, Git deployment'ını nasıl destekler?

İlk deploy için kullanılan genel komut service'i oluşturur, deploy eder, sonucu bekler ve mevcut dizini link'ler:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Ortaya çıkan target production/api olur. .dockup link'i, repository içinde çalıştırılan sonraki komutların bu service'i çözümlemesini sağlar; ancak production dokümantasyonunda tam target yine de kaydedilmelidir.

Yarım kalan bir provisioning denemesinden sonra yeniden create çalıştırmadan önce service'leri listeleyin ve tam target'ı inceleyin:

dockup services --json

production/api zaten mevcutsa status ve deployment history bilgilerini okuyarak devam edin. Böylece belirsiz bir network sonucunu duplicate service'e dönüştürmekten kaçınırsınız. Repository erişim credential'larını source control'dan ve komut çıktılarından uzak tutun.

Dockup, Nixpacks veya Dockerfile'ı nasıl seçer?

Repository bir Dockerfile içeriyorsa Dockup bunu kullanır. Aksi durumda Nixpacks uygulamayı algılar ve otomatik olarak build eder. Bu sıralama, repository'deki açık container tanımını authoritative hâle getirir.

Uygulama yaygın ecosystem convention'larını izliyorsa ve işletim sistemi seviyesinde özelleştirmeye ihtiyaç duymuyorsa Nixpacks iyi bir ilk tercihtir. Belirli bir base image, system package'ları, multi-stage build, özel runtime user'ı veya kesin copy boundary'leri gerektiğinde Dockerfile kullanışlıdır.

Sırf “production'a hazır görünsün” diye boş bir Dockerfile eklemeniz gerekmez. Hatalı bir Dockerfile, conventional bir otomatik build'e kıyasla daha az reproducible olabilir. Karar süreci için Nixpacks vs Dockerfile rehberini kullanın.

Oluşturma işleminden sonra service'i inceleyin:

dockup info production/api --json

Yanıt; repository URL'sini, branch'i, deployment type'ı, port'u, build ve start ayarlarını, environment key'lerini, custom domain'leri ve en son deployment verilerini içerir.

Algılanan komutların override edilmesi gerekiyorsa belgelenen ayarları kullanın:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Ayarlar bir sonraki deployment'ta uygulanır.

Production environment ve health nasıl yapılandırılır?

Sıradan değerleri ve secret'ları ayrı ayrı ekleyin:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Environment listelendiğinde secret değerleri maskelenir. Secret'lar ayarlanabilir veya değiştirilebilir; ancak saklanan değer geri döndürülmez.

Çalışan process yeni bir environment'ı geriye dönük olarak alamayacağı için environment değişiklikleri redeploy gerektirir. Tüm yaşam döngüsü environment variables and secrets rehberinde açıklanır.

Readiness'i temsil eden bir health gate yapılandırın:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup, zero-downtime blue-green flow kullanır ve readiness başarılı olduktan sonra trafiği yalnızca yeni deployment'a yönlendirir. HTTP path yapılandırılmadığında gate, TCP port readiness kontrolüne fallback yapabilir.

Health route, uygulama process'inin request'leri karşılamaya hazır olduğunu doğrulamalıdır. Destructive check'ler veya maliyetli full-system test'leri çalıştırmaktan kaçının. Derin dependency check'leri, optional bir service degraded olduğunda false outage'lara yol açabilir.

Production'a nasıl deploy edilir, izlenir ve doğrulanır?

Release'i tetikleyin ve terminal state'i bekleyin:

dockup deploy production/api --wait --json

Varsayılan timeout 900 saniyedir. Exit 0, başarı anlamına gelir. deploy_failed ve deploy_timeout non-zero sonuçlardır; bu nedenle shell script'leri ve CI system'leri doğru şekilde durur.

Build'i NDJSON olarak izlemek için:

dockup logs production/api --build -f --json

Stream başarıda veya hatada sona erer. Build başarılı olduğu hâlde container crash olursa runtime log'larını inceleyin:

dockup logs production/api --json

Başarılı bir release sonrasında platform state'ini ve public davranışı doğrulayın:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime probe'ları her dakika çalışır ve average ile p95 response time değerlerini raporlar. Security scanning, image CVE'lerini ve configuration'ı kontrol eder. Gerçek business endpoint'i için uygulamaya özel bir smoke test ekleyin; platform readiness gerekli olsa da tek başına yeterli değildir.

Ayrıntılı log yöntemi build ve runtime log debugging rehberinde açıklanır.

Automatic deploy'lar ve preview'lar nasıl kullanıma alınmalı?

Her sınırı gözlemleyebilmek için ilk production release'ini yeterince manuel gerçekleştirin. Build, health gate ve rollback yolu netleştikten sonra push ile deployment'ı etkinleştirin:

dockup auto-deploy production/api --on --json

Automatic deployment, protected bir branch'i ve code-review politikasını takip etmelidir. Push işlemi production trigger'ı olduğundan repository permission'ları infrastructure permission'larına dönüşür.

Pull request ve branch preview'ları izole URL'ler ve environment'lar sağlar:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

Private-networking kullanılan bir project'te preview'lar project network'üne katılır. Aynı production database'ine <slug>.internal üzerinden erişebilirler; ancak Dockup preview için otomatik olarak read-only bir database user oluşturur. Preview, production biçimindeki verileri yazma işlemi yapmadan inceleyebilir.

Bu durum privacy yükümlülüklerini ortadan kaldırmaz. Preview erişimi yine sınırlandırılmalı, audit edilmeli ve yalnızca production verilerini okumanın izinli olduğu durumlarda kullanılmalıdır.

Hatalı bir deployment nasıl rollback edilir?

Recovery işleminden önce kanıtları koruyun. Build hatasında build log'larını, crash durumunda runtime log'larını okuyun. Ardından deployment history'yi listeleyin:

dockup deployments production/api -n 20 --json

Status ve timestamp'i bilinen bir deployment ID seçin, ardından yeniden çalıştırın:

dockup rollback <deploymentId> production/api --json

Rollback açıkça tanımlanmış bir incident action olmalıdır. Hatalı deployment ID'sini, seçilen recovery ID'sini, nedeni ve takip eden düzeltmeyi kaydedin. Bir database migration backward compatible değilse yalnızca uygulamayı rollback etmek uyumluluğu geri getirmeyebilir; migration tasarımı release planının bir parçası olmalıdır.

Zero-downtime deployment rehberi traffic cutover sürecini açıklar; Dockup CLI reference ise tüm komut flag'lerini belgeler.

İlk deployment tamamlama kaydı

Git repository'den production'a workflow'unun sonunda şunları kaydedin:

• Tam project/service target'ı.
• Repository ve production branch'i.
• Build yöntemi: Nixpacks veya Dockerfile.
• Override edilen build ve start komutları.
• Listening port ve health path.
• Deployment ID ve terminal status.
• Production URL'si ve custom domain planı.
• Uptime ve security doğrulaması.
• Rollback deployment ID'si veya seçim kuralı.

Bu kayıt, ikinci deployment'ı yeni bir keşif çalışması olmaktan çıkarıp rutin bir operasyona dönüştürür.

Uygulama state'ini container image'ından ayırın

Bir service container'ının içindeki writable filesystem replaceable kabul edilmelidir. Yeni bir deployment yeni bir version oluşturur ve rollback eski bir image'ı yeniden çalıştırır; yalnızca eski container'ın içine yazılan dosyalar kalıcı bir veri stratejisi değildir.

Relational, document veya cache state için managed database'ler kullanın; deployment'lar arasında korunması gereken dosyalar için volume bağlayın. İlk production release'inden önce mount path'lerini doğrulayın. Hiç mount edilmemiş containerized bir upload directory, bir sonraki deploy verileri silene kadar sağlıklı görünebilir.

Kullanıcı tarafından oluşturulan dosyaları taşımadan önce persistent volume'lar ve snapshot'lar rehberini inceleyin. Database state için database'e özel backup sistemini kullanın; hot volume snapshot'ını transaction-consistent backup olarak değerlendirmeyin.

Sabit bir instance faturası uydurmadan ilk ayı tahmin edin

Dockup, CPU, RAM ve disk tüketimini dakika bazında ölçer ve kullanımı plan bakiyesinden düşer. Free plan, 10 $ başlangıç kredisi ve en fazla üç deployment içerir; önerilen Pro planı aylık 20 $'dır ve 20 $ kullanım kredisi içerir.

Service gerçek trafik almaya başladıktan sonra CPU, RAM ve disk tüketimini app.dockup.ai üzerinden inceleyin. Service, database veya persistent disk'te ayarlama gerekip gerekmediğine karar verirken varsayılan bir maksimum yerine gözlemlenen dakika başına tüketimi kullanın.

Temiz bir ikinci deployment'ı doğrulayın

İlk release'ten sonra zararsız ve review edilmiş bir değişiklik yapıp yeniden deploy edin. Bu işlem repository link'inin, build cache varsayımlarının, health gate'in, environment'ın ve history'nin tek seferlik bir provisioning başarısı olarak değil, sürdürülebilir bir süreç olarak çalıştığını doğrular.

Target'ı açıkça belirtin

Son project/service string'ini kaydedin.

Release URL'sini koruyun

Production URL'sini deployment ID'sinin yanında kaydedin.

Sonraki trigger'ı doğrulayın

Gelecekteki release'lerin manuel mi olacağını, yoksa isteğe bağlı deploy-on-push mı kullanacağını kaydedin. Bu, ilk deployment'tan sonra repository permission'larının, branch protection'ın ve production beklentilerinin uyumlu kalmasını sağlar.

Doğrulanabilir bir deployment ile başlayın

Start komutu ve health route'u açık olan küçük bir repository seçin; ilk başarılı release'ten sonra tam target'ı ve rollback ID'sini belgeleyin.

app.dockup.ai'de ücretsiz başlayın. Free plan aylık 0 $'dır, 10 $ başlangıç kredisi içerir ve bir workspace, üç database ve üç deployment desteği sunar.

SSS

Dockup, Dockerfile olmadan bir repository deploy edebilir mi?

Evet. Dockerfile bulunmadığında Dockup, uygulamayı otomatik olarak algılamak ve build etmek için Nixpacks kullanır.

dockup create --link ne yapar?

Mevcut dizine bir .dockup link'i yazar; böylece sonraki komutlar ilişkili project/service target'ını çözümleyebilir.

İlk deploy'da neden --wait kullanılmalı?

Komutu deployment başarıya, hataya veya timeout'a ulaşana kadar bağlı tutar ve terminal sonucu doğru şekilde yansıtan bir exit code döndürür.

Environment variable değişiklikleri hemen uygulanır mı?

Hayır. Değişiklikler bir sonraki deployment'ta yeni bir container'a uygulanır; bu nedenle environment configuration'ı değiştirdikten sonra service'i redeploy edin.

Dockup bir uygulamayı nasıl rollback eder?

Deployment history'yi listeleyin, bilinen önceki bir deployment ID'sini belirleyin ve bu ID ile tam service target'ını kullanarak dockup rollback çalıştırın.