DevOps & CI/CD

Bir yayın hattının değeri, canlıya ne kadar hızlı çıktığınızla değil, yanlış bir sürüm çıktıktan sonra kaç dakikada geri dönebildiğinizle ölçülür. Geri alınamayan bir hat otomasyon değil, hatayı daha hızlı yayan bir mekanizmadır. Bu yüzden kurduğumuz her hatta ilk yazılan adım dağıtım değil geri alma oluyor: hangi komutla, kimin yetkisiyle, veritabanı göçlerine dokunmadan önceki sürüme nasıl dönülür. Bu soruya yazılı cevabı olmayan bir ekip, yayın sıklığını artırdıkça risk de biriktirir. Aşağıdaki bölümler bir hattın parçalarını, ortam ve sır yönetimini, konteyner tarafını, gözlemlenebilirliği ve devirden sonraki işletmeyi tek tek açıklıyor.

CI/CD'nin amacı hız değil, geri alabilmektir

CI/CD, yani sürekli entegrasyon ve sürekli dağıtım, kod değişikliklerinin otomatik olarak test edilip yayına alınmasını sağlayan sistemi tanımlıyor; ama bu otomasyon hata oranını düşürmüyor, yalnızca hatanın maliyetini değiştiriyor, çünkü aynı hata elle yayına alınan bir sistemde de oluyor ve asıl fark sonrasında ne yapılabildiğinde ortaya çıkıyor. Bir hattı değerlendirirken sorduğumuz üç soru şu: uygulama sürümü tek komutla önceki imaja dönebiliyor mu, veritabanı değişikliği geri alınabilir biçimde mi yazılmış, ve mobil gibi geri alınamayan yayın kanallarında özellik bir bayrakla kapatılabiliyor mu. Üçünün cevabı aynı değil: uygulama sürümü dakikalar içinde geri dönebiliyor, ama sütun silen bir göç geri dönmüyor, bu yüzden şemayı önce genişletip sonra daraltan iki adımlı göç yazılıyor; mağazadan yayınlanan bir mobil sürüm ise hiç geri alınmıyor, yalnızca kapatılabilir bir bayrakla çıkıyor. Lextum AI aynı ilkenin ürün tarafındaki karşılığı: platformda tüm belge değişiklikleri izlenebilir ve geri alınabilir biçimde kayıt altına alınıyor, kimin ne zaman neyi değiştirdiği görülebiliyor. Altyapıdan beklediğimiz şey de bundan farklı değil.

Bir yayın hattı hangi parçalardan oluşur

Aşağıdaki altı başlık, bir yayın hattı kurulurken verilen kararların tamamını kapsıyor. İlk üçü hattın kendisi: derlemeden dağıtıma akan adımlar, ortamların birbirinden nasıl ayrıldığı ve uygulamanın hangi paket biçiminde taşındığı. Sonraki ikisi hattın çevresi: yayından sonra ne olduğunu gösteren ölçüm katmanı ve kimin neye erişebildiği. Altıncısı diğer beşinin sınandığı yer, yani işler kötü gittiğinde ne yapıldığı.

Hattın anatomisi: derleme, test, imaj, dağıtım

Bir yayın hattı dört adımdan oluşur ve her adımın durdurma yetkisi vardır. Derleme, kodun tek bir geliştiricinin makinesinde değil ortak bir ortamda ayağa kalktığını gösterir. Test adımı kırmızıysa hat ilerlemez; atlanabilen test, olmayan testtir. İmaj adımı çıktıyı sürümlenmiş tek bir pakete dönüştürür, böylece test edilen şeyle yayına giden şey aynı olur. Dağıtım adımı o paketi hedef ortama taşır. Bu ayrım işin belkemiği: paket ile ortam ayrıldığında aynı imaj sırayla test, hazırlık ve üretim ortamlarında çalıştırılabilir, her ortam için yeniden derleme yapılmaz.

Ortam yönetimi ve yapılandırma

Ortamlar arasındaki fark yapılandırmada olmalı, kodda değil. Uygulama hangi veritabanına bağlanacağını, hangi servis adresini kullanacağını ve hangi özelliğin açık olduğunu ortam değişkenlerinden okur; kod içinde ortam adına bakan bir dallanma, üretimde ilk kez çalışacak bir yol demektir. En az iki ortam kuruyoruz: üretimin şemasıyla ve göçleriyle aynı olan bir hazırlık ortamı ve üretimin kendisi. Hazırlık ortamı üretimden yalnızca veri ve ölçek bakımından ayrılır. Yapılandırma da kod gibi sürümlenir, çünkü bir olayın sebebi çoğu zaman kod değişikliği değil, kimsenin kaydını tutmadığı bir ayar değişikliğidir.

Konteyner ve orkestrasyon

Konteyner, "bende çalışıyordu" cümlesini ortadan kaldırmak için var. Uygulama, çalışma zamanı ve bağımlılıklar tek bir imajda birleşir; aynı imaj geliştiricinin makinesinde de üretim sunucusunda da aynı şekilde açılır. Orkestrasyon ise ayrı bir karardır ve her projeye gerekmez. Tek servisli, trafiği öngörülebilir bir uygulamada Kubernetes kazançtan çok işletme yükü getirir. Birden fazla servis bağımsız ölçekleniyorsa, dağıtımlar kesintisiz yapılacaksa ve otomatik iyileşme isteniyorsa gerekçe oluşur. Sorunun kaynağı hattın kendisi değil yükse iş Backend Ölçekleme tarafına geçer; orada mimari, veri erişimi ve önbellek konuşulur.

Gözlemlenebilirlik: log, metrik, uyarı

Yayından sonra "iyi görünüyor" bir ölçüm değildir. Üç katman kuruyoruz: yapılandırılmış loglar, hata ve gecikme metrikleri, ve eşik aşıldığında gerçekten birine ulaşan uyarılar. Uyarı kimseye ulaşmıyorsa gösterge tablosu bir dekordur. Her sürümün kendi işaretiyle kaydedilmesi de bu katmanın parçası; hata oranı yükseldiğinde ilk soru "hangi sürümden sonra" olur ve bu sorunun cevabı grafikte durmuyorsa arama saatlere yayılır. Uyarı eşiklerini az sayıda ve harekete geçirecek düzeyde tutuyoruz, çünkü sürekli çalan bir uyarı bir süre sonra susturulur.

Sır yönetimi ve erişim

Depoya bir kez girmiş anahtar, satır silinse bile geçmişte durmaya devam eder; tek doğru hamle anahtarı iptal edip yenilemektir. Veritabanı parolası, ödeme sağlayıcı anahtarı ve bulut kimlik bilgileri kod deposunda değil, hattın okuduğu bir sır deposunda tutulur ve ortam bazında ayrılır: hazırlık ortamındaki bir anahtarın üretim verisine erişmemesi gerekir. Üretime yayın yetkisi de isimle tanımlanır ve kayıt bırakır. Amaç yayın yapabilen kişi sayısını azaltmak değil, kimin ne zaman yayın yaptığının sonradan okunabilir olması.

Geri alma ve olay müdahalesi

Geri alma, olay anında yazılacak bir plan değildir; hattın normal bir adımıdır ve olay dışında da denenir. Önceki imaj hazırda tutulur, dağıtım komutu bir sürüm parametresi alır, dönüş tek adımda olur. Veritabanı tarafı ayrı düşünülür: göçler ileri ve geri yönüyle yazılır, veri kaybettiren adımlar ayrı bir sürüme bırakılır. Olay anında sıra sabittir: önce geri al, sonra sebebi ara. Ters sıra en pahalı olanıdır, çünkü sistem bozukken yapılan teşhis hem yavaş hem baskı altındadır. Olaydan sonra yazılan kısa bir kayıt da aynı hatanın ikinci kez aynı sebeple çıkmasını engelleyen tek şeydir.

Yayın sıklığı ile kırılganlık ilişkisi

Sık yayın yapmak sistemi kırılgan yapmaz; büyük yayın yapmak yapar. Riski belirleyen şey yayın sayısı değil, tek seferde giden değişikliğin boyutudur. Haftalarca biriken bir sürüm bozulduğunda hangi değişikliğin bozduğu bilinmez ve geri alma, çalışan onlarca işi de geri alır. Küçük ve sık sürümlerde geri alınan şey bellidir. Bunun ön koşulu, yayına almanın bir olay olmaktan çıkmasıdır; her sürümde toplanan bir ekip gerekiyorsa sıklık zaten mümkün değildir. Kesintiye tahammülü olmayan sistemlerde bu daha da belirleyici. Anneekspres bir pazar yeri: alıcı tarafı sipariş verirken satıcı tarafı stok güncelliyor, yani planlı bakım penceresi diye bir lüks yok. Projede RabbitMQ ile kuyruk yapısı, PostgreSQL ile veri katmanı ve Jenkins hatları birlikte kuruldu; yüksek erişilebilirlik ile hızlı dağıtım aynı yapıdan çıkıyor.

Altyapıyı kod olarak yönetmenin faydaları

Elle kurulmuş bir sunucu, kuran kişi ekipten ayrıldığı gün belgesiz bir sisteme dönüşür. Altyapıyı kod olarak yazmak, "bu sunucuda ne var" sorusunun cevabını insan hafızasından çıkarıp depoya taşır. Terraform gibi araçlarla sunucu, ağ, güvenlik grubu ve veritabanı tanımları sürümlenir; bir değişiklik önce metin olarak gözden geçirilir, sonra uygulanır. Kazanç üç yerde görünür. Birincisi tekrarlanabilirlik: ikinci bir ortam kurmak haftalık bir iş olmaktan çıkıp tek bir komuta iner. İkincisi denetlenebilirlik: bir ayarın ne zaman ve neden değiştiği kayıtta durur. Üçüncüsü felaket senaryosu: "sunucu tamamen silinirse kaç saatte geri gelir" sorusunun tahmin değil ölçülmüş bir cevabı olur. Bu üçünü doğrulamanın tek yolu, altyapıyı en az bir kez sıfırdan kurup ayağa kaldırmaktır.

Devir: hattı siz nasıl işletirsiniz

Bir yayın hattı, ancak sizin hesaplarınızda çalışıyorsa sizindir. Depo, bulut hesabı, alan adı ve sır deposu sizin adınıza açılır; biz erişim alırız, sahip olmayız. Devirde dört şey yazılı olarak teslim ediliyor: hattın adım adım ne yaptığı, yeni bir geliştiricinin sıfırdan yayına nasıl çıkacağı, geri alma komutunun ne olduğu ve kimin hangi ortama yayın yetkisi bulunduğu. Buna bir de nöbet tarafı ekleniyor: hangi uyarı kime gider, ilk yirmi dakikada ne yapılır. Belgeler tek başına yetmediği için devirden önce sizin ekibinizle en az bir kez gerçek bir yayın ve bir geri alma birlikte yapılıyor. Müşterinin kendi sistemine yakın çalışan mühendislik yaklaşımını Forward Deployed Engineer yazımızda ayrıntılı anlattık; devir de aynı mantığın uzantısı.

Araç seçim kriterlerimiz

Araç seçimi projenin bulunduğu yere göre yapılır, alışkanlığa göre değil. Kod GitHub'da duruyorsa ve ayrı bir çalıştırıcı sunucu işletme isteği yoksa GitHub Actions en kısa yoldur. Kendi sunucusunda çalışan, uzun süreli ve özel adımlar içeren hatlarda Jenkins hâlâ makul bir tercih; bu hizmete bağlı dokuz referansımızın altısında CI/CD Jenkins ile kuruldu ve sunucu tarafı Ubuntu üzerinde çalışıyor. Kalan üçünde teknoloji listesi farklı, çünkü aynı hattı her yere kopyalamıyoruz. Docker ortamlar arası farkı ortadan kaldırır ve konteynerleştirme kararı verildiğinde varsayılan tercih olur. Kubernetes ve Azure ise gerekçeye bağlı: birden fazla servis, bağımsız ölçekleme veya kurumsal bulut politikası varsa devreye girer. Barındırmanın nerede olacağı da bizim değil sizin kararınız; Lextum AI'ın yönetilen SaaS altyapısı AWS üzerinde kuruldu, başka projelerde tercih farklı oldu.

Sahada nasıl çalıştı

Aşağıdaki işler yayında veya tamamlanmış durumda. Her birinin ayrıntısı Başarı Hikayeleri bölümündeki kendi sayfasında duruyor.

• Lextum AI: Mikro servis mimarisi ve RabbitMQ ile asenkron işlem yapısı; Next.js arayüz, .NET servisler ve AWS üzerinde yönetilen SaaS altyapısı, Jenkins ile CI/CD otomasyonu. Yapı yüksek trafikli kurumsal kullanıma hazır.
• Anneekspres: RabbitMQ ile mesaj kuyruğu, PostgreSQL ile veri yönetimi ve Jenkins hatlarıyla kurulan pazar yeri altyapısı; yüksek erişilebilirlik ve hızlı dağıtım.
• Biletico: Next.js ve Node.js üzerinde Redis önbellek, Jenkins hatlarıyla CI/CD otomasyonu; her güncelleme test edilip canlıya alınabiliyor.
• Welldone: Flutter mobil uygulama, React yönetim paneli ve .NET servisleri; Ubuntu tabanlı ölçeklenebilir sunucu altyapısı ve Jenkins ile CI/CD otomasyonu. Siparişten sevkiyata tüm operasyon tek platform üzerinden yönetiliyor.
• World Summer Schools: Next.js, .NET ve PostgreSQL üzerinde bulut tabanlı ölçeklenebilir altyapı; Jenkins ile CI/CD otomasyonu. Altyapı artan program ve kullanıcı hacmine hazır.
• BiTalih: Next.js ve MongoDB üzerinde çalışan içerik üretim platformu; Jenkins ve Ubuntu tabanlı yayın altyapısı.