Bir git push’tan production’a — korkmadan

1. Depoyu bir kez bağla — hat kendiliğinden oluşur

Örnek uygulama küçük bir aile-ağacı web uygulaması (container arkasında bir Node servisi). Tüm kurulum, GitHub deposunu bağlamaktan ibaret:

• Platforms → Container Apps’ta GitHub’ı bağlayın, depoyu ve dalı (main) seçin.
• Bu, uygulamayı bir Deployment hattına dönüştürür: kendi ca-*.cdn.com.tr adresine sahip bir Staging (test kopyası) ve Production, aralarında bir Promote butonu.
• Bundan sonra her push otomatik Staging’e deploy edilir — kod push’layarak production’a asla dokunmazsınız.

2. Her push Staging’e düşer — production sunmaya devam eder

Aynı uygulama, aynı anda iki ortamda. Footer’daki build damgasına bakın: Staging son push’tan gelen yeni build’i çoktan almış, Production hâlâ öncekini sunuyor. Production uygulamasında hiçbir şey yeniden derlenmedi, yani yeni build derlenirken kesinti ve 504 yaşanmadı.

• Staging son commit’i otomatik derleyip deploy etti — kendi test URL’inden erişilebilir.
• Production dokunulmadan: aynı çalışan build, aynı canlı domain, kesintisiz.
• Yeni build’i, tek bir production kullanıcısı görmeden gerçek ve izole bir ortamda test edersiniz.

3. Gerçek Staging URL’sinde doğrula

Staging, uygulamanın kendi subdomain’inde gerçekten çalışan bir kopyasıdır — aynı imaj, aynı add-on’lar — böylece değişikliği maket üzerinde değil, gerçekten tıklayarak denersiniz. Ancak doğru olduğunda ilerlersiniz.

• Hat kartından Staging test URL’sini açın ve değişikliği uçtan uca deneyin.
• Bir şey mi bozdunuz? Sadece bir düzeltme push’layın — Staging yeniden deploy olur, Production hâlâ güvende.

4. Promote: tek tık, yeniden derleme yok

Promote hiçbir şey derlemez. Production domain’inin origin’ini, zaten çalışan Staging build’ine geçirir — anlık, atomik bir değişim. Test ettiğiniz build, birebir canlıya çıkan build’dir.

• Hat kartında Promote’a tıklayın — production artık Staging’de doğruladığınız build’i sunar.
• Bir domain-origin swap olduğu için (yeniden derleme değil), geçiş anlıktır ve kesintisizdir.
• Rollback aynısının tersidir: tek tık production’ı önceki build’e döndürür (uygulamanın DB snapshot’ı varsa onunla birlikte).

Aynı hat terminalden (cdnctl)

Yukarıdakilerin hepsi script’lenebilir — CI için kullanışlı. Panel ve cdnctl aynı uçları kullanır:

# Connect once in the panel, then every push to main auto-deploys to Staging.
# Verify Staging on its test URL, then promote the tested build to production:
cdnctl container apps status  --account <uuid> --app <staging_app_uuid>
cdnctl container apps promote --account <uuid> --app <staging_app_uuid>

# Roll back to the previous production build if needed (instant, no rebuild):
cdnctl container apps rollback-promotion --account <uuid> --app <prod_app_uuid>

Neden tasarım gereği güvenli

• Kod push’lamak production’ı asla bozamaz — auto-deploy yalnızca Staging’i hedefler.
• Promote ettiğiniz şey, test ettiğinizin aynısıdır (test ile canlı arasında yeniden derleme yok).
• Geçiş ve rollback anlık domain-origin swap’tır, yavaş redeploy değil.
• Derlemeler kenarda olur, canlı site derlenirken asla 504 dönmez.

Referans rehberler: Deployment hattı · Git’ten deploy · Blue/green ortamlar.