Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Blue-Green Deployment: Nginx ile İki Environment, App Service Slot'ları ve Anında Geri Dönüş
Blue-green yeni sürümü boştaki ortama kurup smoke test'ten geçirir ve trafiği tek reload ile çevirir; geri dönüş de aynı reload'dur. Nginx'te preview portu, sürüm kontrollü smoke test, switch ve geri dönüşte hatasız probe, reload sırasında blue'da tamamlanan 4 sn'lik istek; App Service slot swap'ının warm-up ve slot setting tuzakları, Kubernetes'te Service selector değişimi ve ortak veritabanının getirdiği sınır.
Rolling Deployment: Sunucuları Sırayla Güncellemek, Kubernetes'te maxSurge ve maxUnavailable
Rolling deployment filoyu parça parça günceller; doğru yapılırsa kesinti olmaz ama iki sürüm bir süre yan yana yaşar. Nginx arkasında üç instance: naif script 90 GET'in 2'sini düşürdü, drain + readiness kontrollü script 237 GET ve 90 POST'u hatasız geçirdi. Kubernetes'te maxSurge/maxUnavailable ve minReadySeconds seçimi, progressDeadlineSeconds aşılınca otomatik geri dönüş olmadığı ve rolling'in uygun olmadığı durumlar.
Zero-Downtime'ın Ön Koşulları: Graceful Shutdown, Readiness, Stateless Uygulama ve Geriye Uyumluluk
Hiçbir deployment stratejisi, kapanırken işini bitirmeyen ve hazır olduğunu doğru söylemeyen bir uygulamayı kurtaramaz. Gerçek koşularla: ShutdownTimeout 2 sn'ye inince 5 sn'lik istek RST ile kopuyor, Docker'ın 1 sn'lik bekleme süresi 137 (SIGKILL) üretiyor, readiness drain sırasında 503 dönerken API 200 vermeye devam ediyor, ayrı Data Protection key ring'i CryptographicException fırlatıyor ve silinen Angular chunk'ı ChunkLoadError'a dönüşüyor.
Deploy ve Release Farkı: Downtime Neden Olur ve Deployment Stratejileri Haritası
Deploy kodun ortama kurulması, release kullanıcının yeni davranışı görmesidir; ikisini ayırabilen ekip riski böler. Nginx arkasındaki tek container'lı recreate deploy'unda 12 istek 2,5 saniye içinde hata aldı. Downtime'ın beş kaynağı, recreate, rolling, blue-green, canary, shadow, A/B ve feature flag'in haritası, karar tablosu ve risk = blast radius × tespit süresi hesabı.
Eski GitHub Actions Workflow'larını Okumak: set-output'tan GITHUB_OUTPUT'a, Node 12/16/20'den Node 24'e
Eski bir workflow'u güncellerken runner label'ını, action major'larını, SDK kaynağını, workflow komutlarını ve cache key'ini birlikte değiştir: ubuntu-18.04, @v2 action'lar ve ::set-output 2026'da ya çalışmıyor ya uyarı veriyor. 2018–2026 zaman çizelgesi, Node 12→24 geçişleri, 2021 tarzı .NET 5 workflow'unun actionlint ve act çıktısı, .NET 10'a taşıma checklist'i ve 2026 özeti.
GitHub Actions'ta Debug, Hız ve Maliyet: Debug Logging, act, Cache Stratejisi ve Artifact Retention
Debug için ACTIONS_STEP_DEBUG/ACTIONS_RUNNER_DEBUG'ı tek bir re-run'da aç, döngüyü act ile kısalt, cache key'ini lock dosyasının hash'iyle kur ve restore-keys ver, artifact'ları kısa sakla. act'te üç koşuda gerçek cache miss, hit ve restore-keys çıktısı, act'in sınırlarının listesi, 10 GB kota ve 7 gün kuralı, retention, billing ekranları ve hız checklist'i.
GitHub Actions Runner'ları: Hosted Image'lar, ubuntu-latest Geçişi, ARM, Larger Runner ve Self-Hosted
Release ve deploy pipeline'larında runner label'ını pin'le: ubuntu-latest 19 Ekim–19 Kasım 2026 arasında 24.04'ten 26.04'e geçiyor. Hosted image haritası, arm64 ve larger runner'lar, actionlint'in label kontrolü, act'te label'ın yalnızca bir Docker image eşlemesi olduğu, ephemeral self-hosted runner, minimum sürüm kuralı, ARC, 2026 fiyatları ve multi-cloud'un IP allowlist'e etkisi.
GitHub Actions Güvenliği: SHA Pinning, Lockfile, pull_request_target ve Script Injection'dan Korunmak
Action'ları tam commit SHA'sına pin'le ve Dependabot/lockfile ile güncel tut, untrusted değerleri run: içine değil env: üzerinden ver, pull_request_target'ta PR kodu çalıştırma. tj-actions vakası, zizmor ve actionlint bulguları, gh actions-lock, act ile gerçek script injection çıktısı, checkout@v7 ve 2 Aralık 2026 değişikliği, güvenli workflow_run pattern'i ve read-only cache token'ları.
GitHub Actions'ta Tekrarı Azaltmak: Composite Action, Reusable Workflow ve YAML Anchor
Step'leri paylaşmak için composite action, environment ve approval gerektiren job'ları paylaşmak için reusable workflow, aynı dosyada blok tekrarı için YAML anchor kullan. Bookstore'un dotnet-ci action'ı ve reusable-deploy workflow'u act ile; secrets: inherit riskleri, environment secret'ları, 10 seviye/50 workflow sınırı, $/ syntax'ı, sürümleme ve merge key'in desteklenmemesi.
GitHub Actions ile Deploy 2: Kendi Linux Sunucuna SSH, Docker Image ve GHCR
Image'ı GitHub Actions'ta bir kez build edip GHCR'a push'la, sunucuya SSH ile yalnızca digest'i gönder; sunucu Docker Compose ile çeker ve yeniden başlatır. metadata-action, build-push-action ve gha cache backend'i (28 sn'den 4 sn'ye), actions/attest, known_hosts pin'leme ve host key değişince ne olduğu, .env.previous ile rollback; act ile gerçek koşu.
GitHub Actions ile Deploy 1: OIDC ile Azure App Service ve Şifresiz Cloud Erişimi
OIDC ile job her çalışmada GitHub'dan imzalı, kısa ömürlü bir token alır ve Azure bunu federated credential ile doğrulayıp client secret olmadan erişim verir. id-token: write, sub claim formatları, Temmuz 2026'daki ID'li subject değişikliği, custom property claim'leri, staging slot'a deploy, smoke test ve swap; AWS ve Google Cloud karşılıkları.
GitHub Actions Environment'ları: Protection Rule, Approval ve Deployment Geçmişi
Environment, bir job'ı runner'a göndermeden önce protection rule'ları (required reviewer, wait timer, branch/tag policy) uygulayan, secret'ları yalnızca o job'a açan ve deployment geçmişi tutan adlandırılmış hedeftir. Bookstore'un staging/production deploy workflow'u, private repository plan kısıtları, deployment: false, environment başına concurrency ve queue: max; act ve actionlint'in nerede durduğu gerçek çıktılarla.