GitHub Actions'ta dev, staging ve prod dağıtımı nasıl kurulur?

Çok ortamlı dağıtım neden gerekir?

Bir uygulama canlıya doğrudan çıkmaz; geliştirme, test ve üretim gibi ortamlardan geçer. Her ortamın farklı bir amacı, farklı gizli bilgileri ve farklı risk düzeyi vardır. Geliştirme ortamında hızlı deneme istenir, üretimde ise denetim ve geri dönüş planı.

GitHub Actions'ta bu yapıyı kurmanın aracı environment kavramıdır. Bir environment, bir dağıtım hedefini (örneğin staging ya da production) adlandırır ve ona koruma kuralları, gizli bilgiler ve değişkenler bağlar. Böylece aynı workflow farklı hedeflere, farklı kurallarla dağıtım yapabilir. Amaç, 'aynı imaj, aynı süreç, farklı hedef' ilkesidir: test edilen sürümle üretime çıkan sürüm aynı olmalıdır.

Environment nasıl tanımlanır ve kullanılır?

Environment, deponun ayarlarında oluşturulur ve ad verilir. Workflow'da bir iş, environment anahtarıyla bu adı referans eder. İş çalışmadan önce o ortamın koruma kuralları sağlanmak zorundadır; ortam gizli bilgilerine yalnızca bu koşul geçildikten sonra erişilir. Workflow bir environment adı belirtirse ve o ad henüz yoksa, çalıştırma sırasında ortam otomatik oluşur, fakat hiçbir koruma kuralı ya da gizli bilgisi olmaz; bunu bir depo yöneticisi sonradan yapılandırmalıdır. Bu nedenle ortamları önceden elle oluşturmak daha güvenlidir.

Örneğin tipik bir yapı şu ortamlardan oluşur: dev (her birleştirmede otomatik), staging (ana dal birleşince otomatik) ve production (onay sonrası). Her iş ilgili environment adını taşır, ortam değişkenleri vars bağlamıyla okunur, ortam gizli bilgileri ise secrets bağlamıyla.

Onay kapıları ve koruma kuralları

Üretim gibi kritik ortamlar için koruma kuralları tanımlanır. GitHub'ın environment ayarlarında şu kurallar bulunur:

• Zorunlu onaylayıcılar (required reviewers): belirli kişi ya da ekipler. Bunlardan birinin onayı yeterlidir. Kişinin kendi tetiklediği dağıtımı onaylamasını engelleyen bir kendi onayını önleme seçeneği de vardır.
• Bekleme süresi (wait timer): işin ilerlemesinden önce beklenecek dakika sayısı.
• Dağıtım dalları (deployment branches): yalnızca belirli dal ya da etiketlerden dağıtıma izin verme, adlandırma desenleriyle.
• Yöneticilerin kuralları atlamasına izin verme seçeneği; kapatılarak sıkılaştırılabilir.
• GitHub Apps ile yazılmış özel dağıtım koruma kuralları: örneğin harici bir izleme ya da değişiklik yönetimi sistemiyle entegrasyon.

Önemli bir ayrıntı: onay bekleyen iş, onay gelene kadar durur ve ortam gizli bilgilerine erişemez. Böylece onaylanmamış bir dağıtım üretim anahtarlarını göremez.

Ortama özel gizli bilgiler ve değişkenler

Her ortamın kendi veritabanı adresi, erişim anahtarı ve yapılandırması vardır. Environment gizli bilgileri ve değişkenleri bu farkı yönetmenin yoludur: yalnızca o environment'ı kullanan işlere sunulur ve koruma kuralları geçildikten sonra erişilebilir hale gelir. Aynı gizli bilgi adını (örneğin dağıtım anahtarı) her ortamda farklı değerle tanımlayabilirsiniz; workflow kodu aynı kalır, değer ortama göre değişir.

Bu yaklaşım kazanç sağlar: önce, staging iş akışının yanlışlıkla üretim anahtarını kullanması engellenir; ayrıca üretim gizli bilgilerini depo geneline açmak yerine onaylı ortama bağlı tutarak erişim yüzeyi daraltılır. Gizli bilgilerin kendisi hiçbir zaman workflow dosyasına, günlüğe ya da dokümana yazılmaz; yalnızca adları ve nerede tanımlandıkları belgelenir.

Pipeline akışını tasarlama

Çok ortamlı bir pipeline genellikle şu sırayı izler: kod birleşince derleme ve test, başarılıysa imaj üretimi, ardından dev ortamına otomatik dağıtım, staging'e otomatik ya da yarı otomatik dağıtım ve üretim için onay kapısı. İşler needs ile birbirine bağlanır; böylece üretim işi ancak staging başarılı olduktan sonra başlar.

Aynı sürümün tüm ortamlara ilerlemesi için derleme bir kez yapılır, çıktı (imaj ya da paket) her ortamda yeniden kullanılır. Her ortamda yeniden derlemek, test edilen ile canlıya giden arasında fark yaratabilir.

Birden çok dağıtımın aynı anda çalışıp birbirini ezmesini önlemek için concurrency ayarı kullanılabilir: aynı ortam için yalnızca bir dağıtımın sürmesini sağlar. Dağıtım adımlarını her ortam için tekrar yazmak yerine yeniden kullanılabilir bir workflow'a taşımak, ortamlar arası farkı yalnızca girdilere indirger.

Geri dönüş, izleme ve denetim

Onay kapısı tek başına güvenlik değildir; dağıtım sonrası doğrulama ve geri dönüş planı da gerekir. Dağıtım sonrası bir sağlık kontrolü adımı ekleyip başarısızlıkta otomatik olarak önceki sürüme dönmek ya da en azından uyarı üretmek iyi bir pratiktir. Geri dönüşün çalışması için önceki imajın registry'de kalması ve geri dönüşün tek komutla yapılabilmesi gerekir.

GitHub, her environment için dağıtım geçmişini tutar: hangi commit'in ne zaman, hangi ortama, kim onayıyla gittiği izlenebilir. Bu kayıt hem denetim hem de olay sonrası inceleme için değerlidir. Kritik dağıtımlarda ekibe bildirim (sohbet kanalı ya da e-posta) göndermek şeffaflığı artırır.

Değişiklik yönetimi gereksinimi olan kurumlarda onay kuralları, hangi değişikliğin kim tarafından onaylandığı kaydını tutacak biçimde tasarlanmalıdır.

Sık yapılan hatalar

• Environment'ı elle oluşturup koruma kuralı tanımlamayı unutmak; workflow ortamı otomatik açar ve hiçbir korumayla gelmez.
• Üretim gizli bilgilerini depo geneli gizli bilgi olarak tanımlayıp ortam kapısını anlamsız bırakmak.
• Her ortamda yeniden derleme yapmak.
• Onaylayıcıyı yalnızca tek kişiye bağlamak; o kişi yokken dağıtım tıkanır.
• Üretim ortamına her daldan dağıtıma izin vermek; dağıtım dalları kuralı ile kısıtlanmalıdır.
• Dağıtım sonrası doğrulama adımı olmaması.
• Eşzamanlı dağıtımları yönetmemek.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

CI/CD Pipeline Tasarımı (GitHub Actions) eğitiminde Çok Ortamlı Deployment Stratejileri modülü bu konuyu doğrudan işler. Yeniden Kullanılabilir İş Akışları modülü ortamlar arası tekrarı azaltmayı, Güvenlik ve Uyumluluk Entegrasyonu modülü ise gizli bilgi yönetimi ve uyumluluk kontrollerini, Gözlemlenebilirlik ve Optimizasyon modülü dağıtım sonrası izlemeyi tamamlar.

Eğitim yazılım geliştiriciler, DevOps, platform ve yayın (release) mühendisleri için uygundur. Birden fazla ürün ekibinin ortak bir onay ve dağıtım düzenine ihtiyaç duyduğu kurumlarda, ortamlar ve onay kapıları konusunda tutarlı bir model kurmak için kullanılabilir.