GitLab CI/CD'de ortamlar ve dağıtım akışı nasıl kurulur?

GitLab'da ortam (environment) neyi temsil eder?

GitLab'da ortam, uygulamanızın dağıtıldığı yerin adlı kaydıdır: staging, production ya da bir geliştiricinin dalına özel önizleme. Pipeline'daki bir iş environment anahtar sözcüğünü taşıdığında GitLab o işi bir dağıtım olarak kaydeder. Böylece Operate bölümündeki Environments ekranında hangi ortamda hangi sürümün çalıştığını, kimin ne zaman dağıttığını ve ortama giden bağlantıyı görürsünüz. Birleştirme isteğinde de ilgili dağıtıma giden bağlantı çıkar.

Ortamlar statik ve dinamik olmak üzere ayrılır. Statik ortamların adı sabittir ve ardışık dağıtımlarda yeniden kullanılır; staging ve production bunlara örnektir. Dinamik ortamlar ise pipeline içinde, genellikle bir CI/CD değişkeninden türeyen adla açılır, tek bir dağıtım için kullanılır ve sonra durdurulur ya da silinir. Review app, dinamik türün tipik uygulamasıdır.

Statik ortam: staging ve production tanımlama

Statik ortamı arayüzden de oluşturabilirsiniz, ama pipeline içinde tanımlamak izlenebilirliği artırır. Dağıtım işine ortam adı ve bağlantı verilir. Aynı adda ortam yoksa pipeline çalışırken GitLab onu oluşturur. Aşağıdaki örnek, ana dalda otomatik staging dağıtımı yapar ve production için elle onay bekler:

deploy_staging: stage: deploy script: - ./deploy.sh staging environment: name: staging url: https://staging.example.com rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy_production: stage: deploy script: - ./deploy.sh production environment: name: production url: https://www.example.com rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: manual

Burada when: manual, production işinin pipeline ekranında bir düğme olarak beklemesini sağlar. Staging'de doğrulanan sürüm, yetkili biri düğmeye bastığında production'a gider. Önemli bir ayrıntı: bir ortam yeniden adlandırılamaz. Adı değiştirmek istiyorsanız eski ortamı durdurup silmeniz ve yeni adla yeniden oluşturmanız gerekir; bu yüzden adı baştan düşünerek seçin.

Review app: her birleştirme isteğine geçici ortam

Review app, bir dal ya da birleştirme isteği için otomatik açılan geçici test ortamıdır. Gözden geçiren kişi kodu okumak yerine çalışan uygulamayı tarayıcıda görür. Dinamik ortam adı, dal adından üretilen değişkenle kurulur:

deploy_review: stage: deploy script: - ./deploy.sh review environment: name: review/$CI_COMMIT_REF_SLUG url: https://$CI_ENVIRONMENT_SLUG.example.com on_stop: stop_review rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stop_review: stage: deploy script: - ./teardown.sh review environment: name: review/$CI_COMMIT_REF_SLUG action: stop rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" when: manual

review/ öneki, arayüzde bütün review ortamlarını tek grupta toplar. Altyapıyı (hostname çözümü, sertifika, kaynak) önceden hazırlamanız gerekir; GitLab yalnızca ortamı kaydeder ve işleri çalıştırır, uygulamayı barındıracak yeri sizin sağlamanız beklenir.

Ortamı durdurma ve temizlik: on_stop ve auto_stop_in

Kapatılmayan review ortamları sunucu kaynağını ve maliyeti sessizce tüketir. Birkaç mekanizma bunu önler. Başta on_stop gelir: dağıtım işi, ortamı kapatacak başka bir işe başvurur; bu iş environment altında action: stop taşır. GitLab, ilişkili dal birleştirildiğinde veya silindiğinde ortamı otomatik durdurur, durdurma işi tanımlı değilse de bu davranış geçerlidir. Sonra auto_stop_in: dağıtım işine süre verildiğinde ortam, etkinlik olmadığı sürece o süre sonunda kendiliğinden kapanır (örneğin bir hafta). Son olarak elle durdurma: Environments ekranında ortamın yanındaki Stop düğmesi.

Arayüzden durdurup on_stop işini de tetiklemek istiyorsanız, dağıtım ve durdurma işleri aynı resource_group içinde olmalıdır. Durdurulmuş bir ortamı silmeden önce durdurmanız gerekir. Korumalı ortamlar toplu temizlikte atlanır; bu, production'ın yanlışlıkla kapanmasına karşı bir güvencedir.

Çakışan dağıtımları engelleme: resource_group

Kısa aralıkla art arda commit gönderildiğinde pipeline'lar birlikte çalışır ve farklı pipeline'lardaki dağıtım işleri aynı altyapıya aynı anda dokunabilir. Bu durum, ortamı tutarsız bir hale bırakabilir. Çözüm, dağıtım işine resource_group eklemektir:

deploy_production: stage: deploy resource_group: production environment: production

Bu ayarla derleme işleri paralel çalışmaya devam eder, ama aynı kaynak grubunu kullanan dağıtım işleri sırayla yürür. Belgelerde birkaç işleme modu tanımlıdır: varsayılan unordered, işleri hazır olur olmaz işler; oldest_first en eski pipeline'ı önce çalıştırır ve sürekli dağıtımda daha güvenlidir; newest_first ise güncelliğini yitirmiş dağıtımları atlayıp en yenisini çalıştırır, ancak işlerin tekrar çalıştırılabilir (idempotent) olmasını gerektirir.

Yetki, değişken ve geri alma

Production dağıtımını herkesin tetikleyememesi için korumalı ortam (protected environment) kullanılır; yalnızca Allowed to deploy listesindeki kişi veya roller o ortama dağıtım yapabilir. Grup düzeyinde koruma için GitLab dağıtım katmanlarını kullanır: development, testing, staging, production ve other. Ortam adından katman tahmin edilir, ama tahmini engellemek için işte deployment_tier anahtar sözcüğünü açıkça yazabilirsiniz.

Gizli bilgiler de ortama göre ayrılmalıdır. CI/CD değişkenlerinin ortam kapsamı (environment scope) sınırlanabilir; böylece production veritabanı parolası staging işine hiç ulaşmaz. Parolaları betiğe yazmayın.

Geri alma için pratik yol, daha önce başarılı olmuş dağıtımı Environments ekranından yeniden çalıştırmaktır. GitLab ayrıca uyarı tabanlı otomatik geri alma sunar; bu özellik varsayılan olarak kapalıdır, uyarının gitlab_environment_name anahtarını taşıması gerekir ve ortamda yürüyen bir dağıtım varken geri alma atlanır. Geri almayı canlı ihtiyaç doğmadan önce prova etmek en güvenli yaklaşımdır.

Dağıtım stratejisi seçerken karar ölçütleri

GitLab ortamı ve dağıtımı kaydeder; sürümün kullanıcıya nasıl geçtiğini ise dağıtım betiğiniz veya altyapınız (örneğin Kubernetes) belirler. Strateji seçerken şu ölçütlere bakın:

• Kesinti toleransı: Kesinti kabul edilemiyorsa kademeli güncelleme (rolling) ya da mavi-yeşil, eski ve yeni ortamı paralel tutarak geçişi anlık yapar.
• Risk iştahı: Yeni sürümü önce küçük bir kullanıcı kesitine açıp gözlemlemek istiyorsanız canary yaklaşımı uygundur.
• Geri dönüş hızı: Mavi-yeşilde eski ortam hazır beklediği için dönüş hızlıdır, ama çift altyapı maliyeti vardır.
• Veritabanı değişikliği: Şema değişiklikleri sürümden bağımsız ve geriye uyumlu planlanmalıdır, aksi halde hiçbir strateji güvenli geri dönüş sağlamaz.

Sık yapılan hatalar: production'a otomatik dağıtım yapıp doğrulama kapısı koymamak, review ortamlarını temizleyecek mekanizma kurmamak ve dağıtım işlerini resource_group olmadan paralel bırakmak.

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

Ortam ve dağıtım akışı kurmak, DevOps mühendislerinin, platform ekiplerinin ve release sorumlularının ortak işidir. Mindset kataloğundaki CI/CD Pipeline Tasarımı (GitLab) programının modül başlıkları arasında Deployment ve Ortam Yönetimi, Test ve Kalite Kapıları, Runner Yönetimi ve Optimizasyon ile GitLab ile GitOps ve Olgunluk yer alıyor.

Kurumsal ekipler için değeri, staging'den production'a geçiş kurallarını, onay yetkisini ve geri alma prosedürünü ortak bir pipeline şablonunda toplayabilmektir; böylece her ekip kendi dağıtım düzenini yeniden icat etmek zorunda kalmaz.