GitOps ile Çoklu Ortam Terfi Hattı

Kurumsal ekiplerde dağıtım hatlarının en kırılgan noktalarından biri, geliştirme ortamında çalışan bir değişikliğin test ve üretime hangi kurallarla taşınacağının net olmamasıdır. CI sistemleri artefact üretir; ama asıl kontrol sorusu çoğu zaman şu olur: hangi sürüm ne zaman, kim tarafından ve hangi onay mekanizmasıyla üst ortama terfi etti? GitOps yaklaşımı bu soruya daha denetlenebilir bir cevap verir.

GitOps burada neyi çözüyor?

GitOps yalnızca “deploy manifestleri Git’te dursun” yaklaşımı değildir. Çoklu ortam yönetiminde üç somut problem çözer:

• Ortam durumu istenen durum olarak sürüm kontrolüne alınır.
• Terfi kararları görünür ve denetlenebilir olur.
• Operasyon ekibi ile uygulama ekibi arasında ortak bir değişiklik yüzeyi oluşur.

Bu özellikle birden fazla Kubernetes kümesi, ayrı ağ segmentleri veya ERP çevresinde çalışan yardımcı servis kümeleri olduğunda önemlidir.

Sağlam bir ortam modeli nasıl görünür?

Başlangıç için en okunabilir yapı genelde şu ayrımı yapar:

• dev: hızlı geri bildirim ve esnek deneme alanı
• test veya staging: entegrasyon, regresyon ve güvenlik kontrolleri
• prod: kural seti sıkı, değişiklik penceresi net ortam

Bu ortamların tamamı aynı repo içinde tutulabilir; ancak onay kuralları, branch korumaları ve dağıtım tetikleyicileri farklı olmalıdır.

Terfi hattını tasarlarken temel kararlar

GitOps hattında şu kararlar baştan verilmelidir:

1. Artefact sürümü immutable mı?
2. Terfi için PR mı, etiket mi, otomatik policy mi kullanılacak?
3. Ortamlar arası fark yalnızca değer dosyalarında mı tutulacak?
4. Geri dönüş hangi commit veya manifest sürümüne göre yapılacak?

Bu sorular net değilse GitOps yalnızca yeni bir commit ritüeline dönüşür.

Örnek terfi akışı

Pratik ve kontrollü bir akış şu şekilde işler:

• Uygulama değişikliği CI ile derlenir ve sürümlü imaj üretilir.
• dev ortam manifesti yeni imaja referans verecek şekilde güncellenir.
• Doğrulamalar geçerse test ortamı için ayrı bir PR açılır.
• Gerekli kontroller sonrası prod manifesti onayla yükseltilir.

Bu modelde her ortam geçişi Git geçmişinde izlenebilir olur. Aynı zamanda “hangi sürüm üretimde?” sorusu cluster içine bakmadan da yanıtlanabilir.

Kurumsal tarafta neden zorlaşır?

Gerçek hayatta ortamlar sadece teknik olarak ayrılmaz; ağ, erişim, veri sınıfı ve değişiklik penceresi açısından da ayrılır. Bu yüzden GitOps hattı şu alanlara da temas etmelidir:

• Ayrı sır ve kimlik yönetimi
• Ortam bazlı politika kontrolleri
• Dağıtım sonrası sağlık doğrulaması
• Onaylı bakım pencereleri

Özellikle ERP bağımlı sistemlerde, uygulama sağlıklı olsa bile aşağı akış entegrasyonları hazır değilse terfi tamamlanmış sayılmaz.

Sık yapılan hatalar

• Ortam farklarını kopyala-yapıştır manifestlerle büyütmek
• Üretim terfisini aynı branch akışıyla kontrolsüz yapmak
• GitOps aracını manuel müdahaleyle sürekli bypass etmek
• Rollback stratejisini yalnızca yeniden deploy varsaymak
• Ortamlara özel gözlem ve alarm şartlarını unutmak

Bu hatalar yüzünden GitOps görünürde vardır; ama gerçek kontrol yine kişilerin terminal geçmişinde kalır.

Sonuç

GitOps ile çoklu ortam terfi hattı kurmak, dağıtımı yalnızca otomatikleştirmek değil; değişikliği denetlenebilir bir ürün hâline getirmektir. İyi tasarlanmış bir akış, geliştirme hızını boğmadan test ve üretim ortamlarında daha yüksek güven üretir. Kurumsal yapılarda asıl değer, her ortam terfisinin izlenebilir, geri alınabilir ve sahipliği açık bir karar noktası olmasında ortaya çıkar.