Dramsız DevOps: Her Gün Yayına Almak

Her gün yayına almak cesaret işi değildir; küçük değişiklikler, otomatik bir teslimat hattı ve sorunu kullanıcıdan önce gören bir izleme düzeni kurulduğunda sıradan bir alışkanlığa dönüşür. Gece yarısı yapılan sürümler, “herkes hazırda beklesin” mesajları ve geri dönüşü olmayan büyük güncellemeler bir ekibin yeteneğini değil, sürecinin kırılganlığını gösterir. Bu yazıda teslimatı sessiz ve öngörülebilir hâle getiren alışkanlıkları sahadan notlar olarak topladık.

Büyük sürümler neden drama üretir?

Bir sürüm ne kadar çok değişiklik taşıyorsa, bir şey ters gittiğinde nedeni bulmak o kadar zorlaşır. Haftalarca biriken kod aynı anda canlıya çıktığında hata ile onu doğuran değişiklik arasındaki bağ kopar. Ekip sorunu çözmeden önce sorunun nerede olduğunu aramakla vakit kaybeder.

Seyrek sürümün bir de insani bedeli vardır. Yayına alma nadir bir olay olduğunda herkes gerilir, kontrol listeleri uzar, onay toplantıları çoğalır. Bu da bir sonraki sürümü geciktirir; geciken sürüm büyür, büyüyen sürüm daha da korkutucu hâle gelir. Döngüden çıkmanın yolu sürümü küçültmek ve sıklaştırmaktır. Risk ortadan kalkmaz, ama yönetilebilir parçalara bölünür.

• Büyük sürüm: çok sayıda değişiklik, belirsiz hata kaynağı, zahmetli geri alma.
• Küçük sürüm: tek bir amaç, hızlı teşhis, dakikalar içinde geri dönüş.

Küçük ve sık sürümler: riski parçalara bölmek

Her gün yayına alan ekiplerin ortak noktası, değişikliği olabildiğince küçük tutmalarıdır. Bir özellik birkaç güne yayılıyorsa parçalara ayrılır ve her parça tek başına güvenle canlıya çıkabilecek hâle getirilir. Bunu mümkün kılan birkaç teknik var:

• Ana dala yakın çalışmak (trunk-based development): Uzun yaşayan dallar yerine kısa ömürlü dallar ve sık birleştirme. Çatışmalar küçükken çözülür.
• Özellik bayrakları (feature flags): Kod canlıya çıkar ama özellik kapalı kalır. Yayına almak ile kullanıcıya açmak birbirinden ayrılır.
• Kademeli açılış: Yeni bir davranış önce iç ekibe, sonra kullanıcıların küçük bir kısmına, en son herkese açılır.
• Geriye uyumlu veritabanı değişiklikleri: Önce yeni sütun eklenir, sonra kod taşınır, en son eski yapı kaldırılır. Her adım ayrı bir sürümdür.

Son madde en sık gözden kaçandır. Uygulama kodu saniyeler içinde geri alınabilir; ama bir sütunu silen ya da veriyi dönüştüren bir göç kolay kolay geri alınamaz. Veri değişikliklerini ayrı ve geri dönüşlü adımlara bölmek, yayın günü dramının en yaygın kaynağını ortadan kaldırır. Uygulamayı açılırken veritabanını kendiliğinden güncelleyecek şekilde kurmak yerine göçleri kontrollü ve izlenebilir bir adım olarak çalıştırmak da aynı ilkenin parçasıdır.

CI/CD hattı neler yapmalı?

Elle yapılan her adım, bir gün unutulacak bir adımdır. Sürekli entegrasyon ve sürekli teslimat (CI/CD) hattının görevi, “çalışıyor mu?” sorusunu insan hafızasından alıp tekrarlanabilir bir sürece devretmektir. İyi bir hat genellikle şu sırayla ilerler:

1. Derleme: Her birleştirmede kod temiz bir ortamda derlenir; “benim makinemde çalışıyordu” tartışması biter.
2. Otomatik testler: Birim ve entegrasyon testleri dakikalar içinde sonuç verir. Yavaş testler hattı yavaşlatır, yavaş hat da ekibi değişiklikleri biriktirmeye iter.
3. Güvenlik ve bağımlılık taraması: Bilinen açıkları olan paketler ve koda gömülmüş gizli anahtarlar canlıya çıkmadan yakalanır.
4. Tek paket, birden çok ortam: Aynı derleme çıktısı önce test ortamına, sonra canlıya gider. Ortamlar arasında yalnızca yapılandırma değişir.
5. Yayına alma ve doğrulama: Sürüm çıkar, ardından temel sağlık kontrolleri otomatik olarak çalışır ve sonuç ekibe bildirilir.

Hattın kendisi de kod olarak saklanmalıdır. Altyapıyı kodla tanımlamak (infrastructure as code), sunucuların ve ortamların zamanla birbirinden habersizce farklılaşmasını engeller. Bu yapı kurulurken yazılım mimarisi ile teslimat süreci birlikte ele alınmalıdır; yazılım geliştirme projelerinde teslimat hattını ilk günden işin parçası olarak tasarlamamızın nedeni budur. Sonradan eklenen bir hat, çoğu zaman mevcut alışkanlıkların etrafından dolaşmak zorunda kalır.

İzleme ve gözlemlenebilirlik: sorunu kullanıcıdan önce görmek

Sık yayına almak, bir şeyin bozulduğunu hızla fark edebildiğiniz sürece güvenlidir. İzleme “sistem ayakta mı?” sorusunu yanıtlar; gözlemlenebilirlik ise “neden böyle davranıyor?” sorusunu. Üç sinyal temel oluşturur:

• Metrikler: Hata oranı, yanıt süresi, trafik ve kaynak kullanımı. Her sürümden sonra bu eğrilere bakmak bir refleks olmalı.
• Loglar: Yapılandırılmış, aranabilir ve tek bir isteği baştan sona takip etmeye izin veren kayıtlar.
• İzler (traces): Bir isteğin servisler arasında nerede yavaşladığını ya da nerede koptuğunu gösteren zincir.

Alarmlar az ve anlamlı olmalıdır. Her küçük dalgalanmada çalan bir alarm kısa sürede görmezden gelinir. İşe yarayan bir kural: Bir alarm geldiğinde birinin yapması gereken somut bir iş yoksa, o alarm bir panoya ya da haftalık rapora taşınmalıdır. Dağınık iş akışlarını tek yerde toplamanın değerini Next Platform’u geliştirirken de gördük; aynı ilke izleme için de geçerli. Ekip sistemin durumunu tek bir ekrandan, yorum gerektirmeden okuyabilmelidir.

Geri alma, olay yönetimi ve suçlamasız değerlendirme

İyi bir sürüm süreci hatayı tamamen önlemekten çok, hatanın bedelini küçültmekle ilgilidir.

Hiçbir süreç hatayı sıfırlamaz. Fark, hata olduğunda ne kadar hızlı ve sakin toparlandığınızdadır. Bunun için üç şeyin önceden hazır olması gerekir:

• Tek adımda geri alma: Bir önceki sürüme dönmek, yeni bir sürüm çıkarmak kadar kolay ve daha önce denenmiş olmalı.
• Net roller: Bir olay sırasında kimin karar verdiği, kimin teknik müdahaleyi yürüttüğü ve kimin müşteriyle iletişim kurduğu önceden bellidir.
• Suçlamasız değerlendirme: Olaydan sonra “kim yaptı?” değil, “süreç bunun olmasına nasıl izin verdi?” diye sorulur. Çıkan her ders bir teste, bir alarma ya da yeni bir otomasyon adımına dönüşür.

Bu döngü zamanla güven üretir. Ekip, hatanın bir felaket değil düzeltilebilir bir olay olduğunu gördükçe daha küçük ve daha sık sürümler çıkarmaya istekli hâle gelir. Sık sürüm de bir sonraki hatanın daha küçük olmasını sağlar.

Sık sorulan sorular

DevOps bir araç mı, bir ekip mi?

İkisi de değil; geliştirme ve operasyonun aynı hedef için birlikte çalıştığı bir çalışma biçimidir. Araçlar bu biçimi destekler, ama yalnızca bir araç satın almak DevOps’a geçmek anlamına gelmez.

Küçük bir ekip için her gün yayına almak gerçekçi mi?

Evet, hatta küçük ekipler için çoğu zaman daha kolaydır. Temel bir CI/CD hattı, otomatik testler ve basit bir izleme düzeni kurulduğunda sürüm çıkarmak birkaç dakikalık rutin bir işe dönüşür.

DevOps’ta başarı nasıl ölçülür?

Yaygın olarak kullanılan DORA metrikleri iyi bir başlangıçtır: yayına alma sıklığı, bir değişikliğin canlıya ulaşma süresi, sorun çıkaran değişikliklerin oranı ve hizmeti yeniden ayağa kaldırma süresi. Önemli olan tek bir rakam değil, dördünün birlikte iyileşmesidir.

Güvenlik bu sürecin neresinde durur?

En başında. Bağımlılık taramaları, gizli anahtar kontrolleri ve erişim yetkileri hattın parçası olduğunda güvenlik, sürümü yavaşlatan bir kapı olmaktan çıkar. Daha kapsamlı bir liste için siber güvenlik kontrol listemize göz atabilirsiniz.

Nereden başlamalı?

Her şeyi aynı anda değiştirmeye çalışmayın. Önce bugünkü sürüm sürecinizi adım adım yazın; elle yapılan, en çok zaman alan ya da en sık hataya yol açan adımı seçin. Onu otomatikleştirin, ardından bir sonrakine geçin.

1. Her birleştirmede çalışan bir derleme ve test adımı kurun.
2. Canlıya çıkışı tek bir komuta ya da tek bir tıklamaya indirin.
3. Hata oranı ve yanıt süresi için birkaç anlamlı alarm tanımlayın.
4. Geri almayı gerçekten deneyin; yazılı ama hiç denenmemiş bir geri alma planı henüz bir plan değildir.

Teslimat sürecinizin nerede tıkandığını birlikte görmek ve ekibinize uygun bir yol haritası çıkarmak için strateji ve danışmanlık ekibimizle konuşabilirsiniz. Bize ulaşın; ilk adımı birlikte atalım.