Git ile deploy: dalınıza push edin, yeni sürüm yayına girsin

"Git ile deploy" gerçekte ne demek

Sektörün tarihinin büyük bölümünde dağıtım, bir insanın elle yaptığı bir diziydi: yerelde derle, dosyaları sunucuya kopyala, migration çalıştır, süreci yeniden başlat, bir şeyin atlanmadığını um. Her adım, bu sefer öncekinden biraz farklı yapma ihtimaliydi — ve "benim makinemde çalışıyor" ile bozuk bir üretim sitesi arasındaki fark, genellikle tam da o adımlarda yaşardı.

Git ile dağıtım bu diziyi bir kuralla değiştirir: doğruluk kaynağı daldır, orada ne varsa çalışan odur. Hiçbir şey yüklemezsiniz. Push edersiniz, platform her seferinde birebir aynı derlemeyi yapar. Mesele kolaylık değil, tekrarlanabilirliktir.

Push ile canlı uygulama arasında ne oluyor

Zincir kısadır ve bilmeye değer, çünkü bir şey ters gittiğinde hangi halkaya bakacağınızı bilmek istersiniz.

Push deponuza ulaşır, depo bize haber verir. O deponun ve dalın bir uygulamaya bağlı olup olmadığına bakılır; bağlıysa derleme başlar. Derleme izole bir kum havuzunda çalışır — kodunuz başkasının süreciyle asla aynı yerde olmaz — ve Dockerfile'ınızdan bir container imajı üretir. İmaj hazır olduğunda platform yeni sürümü başlatır ve eskisini emekliye ayırır. Derleme başarısız olursa hiçbir şey değişmez: önceki sürüm trafiği taşımaya devam eder — gecenin ikisinde isteyeceğiniz davranış tam olarak budur.

Erişim tasarım gereği kısa ömürlüdür: deponuzu okumak için kullanılan kimlik saklanmaz, dağıtım anında üretilir; yani veritabanımızda oturup ömrünü aşan bir anahtar olmaz.

Deponuzda ne olmalı

Esasen tek şey: **Dockerfile**. Kaynağınızı çalıştırılabilir bir imaja çeviren tariftir — temel imaj, bağımlılıklar, derleme adımı, başlatma komutu. Projenizde henüz yoksa yazmak tek seferlik bir iştir ve aynı dosya kendi bilgisayarınızda da çalışır.

İki ayrıntı en çok zamanı kurtarır. Birincisi, uygulamanız platforma bildirdiğiniz portu dinlemeli ve yalnız `localhost`'u değil tüm arayüzleri (`0.0.0.0`) dinlemelidir — yalnızca localhost'a bağlanan bir container dışarıdan erişilemez. İkincisi, gizli olan her şey (veritabanı adresi, API anahtarları) imaja değil ortam değişkenlerine aittir: imajlar yeniden derlenir ve taşınır; imaja gömülmüş bir sır, döndüremeyeceğiniz bir sırdır.

Çok servisli bir proje de aynı şekilde bir Compose dosyasıyla çalışır — hazır imajı olmayan her servisin derlenebilir bir Dockerfile'ı olmalıdır, yığın birbirine bağlanmış hâlde ayağa kalkar.

Dallar: üretimi günlük işinizden uzak tutun

Ekiplerin canının yandığı yer burasıdır ve çözümü bir özellik değil, bir karardır. Üretim, geliştirme yaptığınız dala bağlıysa yarım kalmış her commit yayına çıkar. Üretimi yalnızca bilerek merge ettiğiniz bir dala bağlayın — yaygın olarak günlük iş feature dallarında dönerken `main`, ya da `main` üzerinde iterasyon yapıyorsanız ayrı bir `production` dalı.

İşe yarayan zihinsel test: "şimdi push etsem, ziyaretçilerin bunu görmesinden rahatsız olur muyum?" Bağlı dal için cevap bir kez bile hayırsa, sorun süreçte değil dal seçimindedir.

Üretimi sıkıcı tutan bir yayın akışı

# gundelik is: feature dalinda
git checkout -b feature/yeni-fiyatlandirma
git commit -am "pricing page"
git push origin feature/yeni-fiyatlandirma   # deploy TETIKLEMEZ

# yayina hazir oldugunda
git checkout main
git merge feature/yeni-fiyatlandirma
git push origin main                         # deploy BU push ile baslar

Push bir şey yapmadığında

Dağıtım, sessizce hiçbir şey yapmadığı ana kadar sihir gibi gelir; o yüzden teşhisi zincirin çalıştığı sırayla yapın.

Sondan başlayın: derleme hiç başladı mı? Push'unuz için ortada derleme yoksa kopan halka bağlantıdır — bağlı olan depo ya da dal başkasıdır, veya entegrasyon erişimini yitirmiştir (iptal edilmiş kurulum, adı değişmiş ya da devredilmiş depo). Derleme başlayıp başarısız olduysa nerede olduğunu derleme günlüğü tam olarak söyler; en yaygın sebepler, `.dockerignore` dışladığı için yerelde çalışıp derlemede çalışmayan bir adım ya da derlemede olmayan bir kimlik isteyen bağımlılık kurulumudur. Derleme başarılıysa ama hâlâ eski sürümü görüyorsanız, neredeyse kesinlikle bayat uygulamaya değil cache'lenmiş yanıta bakıyorsunuzdur — deploy'dan şüphelenmeden önce sayfayı cache kırıcıyla isteyin ya da cache durum başlığına bakın.

Bilinmesi gereken bariz olmayan bir durum: zaten başarısız olmuş bir commit için dağıtımı yeniden çalıştırmak tek başına düzeltmez. Girdi commit'tir; girdi değişmediyse sonuç da değişmez. Aynısını tekrar denemek yerine bir düzeltme push edin — boş bir commit bile olur.

Durumu görmek ve terminalden deploy tetiklemek

# calisan uygulamanin durumu
cdnctl container apps list --account <uuid>

# son deploy ne yapti
cdnctl container apps logs --account <uuid> --app <app_uuid>

# elle yeniden dagit (ayni commit)
cdnctl container apps deploy --account <uuid> --app <app_uuid>

Sıkıcılaştığında ne kazanırsınız

Git ile dağıtımın asıl getirisi hız değil, dağıtımın bir "olay" olmaktan çıkmasıdır. Yayınlamak bir push olduğunda küçük değişiklikler riskli bir aylık sürüme yığılmak yerine tek tek çıkar — ve hata ayıklayabildiğiniz değişiklikler küçük olanlardır, çünkü bir şey bozulduğunda hangi commit'in yaptığını tam olarak bilirsiniz.

Geri almayı da acil durumdan çıkarıp normal bir işleme çevirir: önceki imaj hâlâ duruyordur, geri dönmek de diğerleri gibi bir dağıtımdır. Her gün yayın yapan ekipler ayda bir yapanlardan daha cesur değildir; her bir dağıtımı ilgi çekmeyecek kadar küçültmüşlerdir.