DevOps nedir? Otomasyon, CI/CD ve ekip kültürü rehberi

Kısa yanıt

DevOps, yazılım geliştirme (Dev) ile operasyon (Ops) ekiplerinin aynı hedef etrafında birleştiği; kültür, süreç ve otomasyon araçlarının tamamını kapsayan bir çalışma yaklaşımıdır. Amacı, yazılımı küçük parçalar halinde sık sık, güvenilir ve tekrarlanabilir biçimde üretime almak, geri bildirim döngüsünü kısaltmak ve hem teslim hızını hem de sistem kararlılığını birlikte iyileştirmektir.

DevOps bir araç listesi veya satın alınacak tek bir ürün değildir. Bir kurumun yazılımı nasıl planladığını, test ettiğini, yayına aldığını ve izlediğini baştan sona tanımlayan bir çalışma biçimidir.

DevOps nedir ve ne değildir?

DevOps terimi, “development” ve “operations” kelimelerinin birleşiminden doğdu. Ancak bu isim yanıltıcıdır: DevOps, iki ayrı ekibi aynı odada oturtmak değil, yazılımın üretimde çalışmasıyla ilgili sorumluluğu geliştirme sürecinin tamamına yaymaktır. Klasik modelde geliştiriciler özelliği yazar, operasyon ekibi sistemi ayakta tutar ve sorun çıktığında iki taraf birbirini işaret eder.

DevOps’un ne olmadığını netleştirmek, ne olduğunu anlamaktan daha öğreticidir:

• Yalnızca araç değildir. Konteyner, CI sunucusu veya izleme paneli DevOps’un görünen yüzüdür; sorumluluk paylaşılmadığında bu araçlar beklenen faydayı vermez.
• Tek bir kişinin işi değildir. “DevOps mühendisi” ilanları yaygın olsa da, bir kişiyi işe almak kültürü değiştirmez. DevOps bir ekip alışkanlığıdır.
• Yalnızca otomatik dağıtım değildir. Otomasyon, iyi tanımlanmış bir sürecin hızlandırıcısıdır; belirsiz bir süreci otomatikleştirmek sorunu daha hızlı üretmekten başka işe yaramaz.
• Tek seferlik bir proje değildir. Altyapı, ekip ve ürün büyüdükçe teslim süreci de ayarlanmalıdır.

Red Hat’in Understanding DevOps sayfası bu yaklaşımı kültür, otomasyon, ölçüm ve paylaşım eksenlerinde ele alır; AWS’nin What is DevOps? rehberi ise DevOps’u kültürel felsefe, uygulama ve araçların birleşimi olarak tanımlar.

DevOps hangi problemi çözer?

DevOps soyut bir olgunluk hedefi değil, tanıdık problemlere verilen bir yanıttır:

• Yavaş teslim: Geliştirilen bir özellik yayına alınmayı haftalarca bekliyorsa, aradaki her gün değer üretmeyen bir stok demektir.
• Ortam farkları: Geliştirme, test ve üretim ortamları elle ve farklı biçimlerde kurulduğunda, aynı kod bir ortamda çalışıp diğerinde çalışmaz.
• “Bende çalışıyordu”: Bu cümle, sürecin tekrarlanabilir olmadığının itirafıdır.
• Manuel dağıtım hataları: Onlarca adımın insan eliyle çalıştırılması, kaçınılmaz olarak atlanan bir adım ve kesinti üretir.
• Gecikmiş geri bildirim ve bilgi siloları: Üretimde fark edilen bir hatanın düzeltme maliyeti kat kat artar; sistemi yalnızca bir kişi biliyorsa, o kişi izne çıktığında operasyon durur.

Bu problemlerin ortak kökü, geliştirme ile operasyon arasındaki sorumluluk boşluğudur; DevOps bu boşluğu süreç ve otomasyonla kapatır.

DevOps’un temel ilkeleri

DevOps uygulamaları kurumdan kuruma değişse de altındaki ilkeler sabittir.

Küçük ve sık teslim

Büyük ve seyrek sürümler riski biriktirir. Yüz değişikliği tek pakette yayına almak, sorun çıktığında hangisinin neden olduğunu bulmayı zorlaştırır. Küçük parçalar halinde sık teslim, her değişikliği gözlemlenebilir ve geri alınabilir kılar.

Otomasyon

Tekrar eden, elle yapılan ve hataya açık adımlar otomasyona devredilir: derleme, test, paketleme, ortam kurulumu, dağıtım, yedekleme. Amaç insanı süreçten çıkarmak değil, karar gerektiren işlere odaklamaktır.

Ölçüm

“İyileştirdik” demek için ölçmek gerekir. Dağıtım sıklığı, değişiklikten yayına geçen süre, başarısız dağıtım oranı ve kesinti süresi gibi göstergeler, sürecin gerçekten iyileşip iyileşmediğini gösterir.

Geri bildirim döngüsü

Test sonuçları geliştiriciye dakikalar içinde ulaşmıyorsa döngü kopmuştur. Üretimdeki hatalar ve kullanıcı davranışı ekibe geri akmıyorsa, ekip kendi etkisini göremez.

Paylaşılan sorumluluk

“Kodu ben yazdım, çalıştırmak senin işin” ayrımı yerini “yazdığımız kod üretimde sorunsuz çalışana kadar iş bitmemiştir” anlayışına bırakır.

CI (sürekli entegrasyon) nedir?

Sürekli entegrasyon (Continuous Integration), geliştiricilerin kod değişikliklerini ana dala sık sık birleştirmesi ve her birleştirmede derleme ile testlerin otomatik olarak çalışmasıdır. Amaç, entegrasyon sorunlarını haftalar sonra değil, dakikalar içinde yakalamaktır.

CI olmadan ekipler uzun süre ayrı dallarda çalışır ve birleştirme günü kaçınılmaz bir çatışma ve hata yığınıyla karşılaşır. CI, bu birleştirme acısını sürekli ve küçük dozlara böler. Tipik bir CI hattı şu adımları içerir:

# Örnek CI hattı (kavramsal)
on: [push]
jobs:
  build-and-test:
    steps:
      - checkout          # kodu al
      - install           # bağımlılıkları kur
      - lint              # stil ve statik kontrol
      - test              # otomatik testler
      - build             # üretim paketini oluştur

Buradaki kritik nokta, hattın herkes için aynı ve tekrarlanabilir olmasıdır. Testler geliştiricinin kendi makinesinde geçip CI sunucusunda düşüyorsa, sorun büyük olasılıkla ortam farkıdır ve önce o fark kapatılmalıdır.

CD: sürekli teslim ve sürekli dağıtım arasındaki fark

CD kısaltması iki farklı uygulamayı işaret eder ve sık sık karıştırılır:

• Sürekli teslim (continuous delivery): Testlerden geçen her değişiklik, tek komutla üretime alınabilecek durumdadır. Yayına alma kararı insana aittir.
• Sürekli dağıtım (continuous deployment): Testlerden geçen her değişiklik otomatik olarak üretime alınır; insan onayı adımı kalkar.

İkisi arasındaki seçim bir olgunluk meselesi değil, risk tercihidir. Düzenli denetim gerektiren, mevzuata tabi veya yüksek kesinti maliyeti olan sistemlerde sürekli teslim çoğu zaman daha doğru bir hedeftir. Atlassian’ın DevOps rehberi de bu ayrımı, teslim hattının ne kadarının otomatikleştirildiği üzerinden açıklar.

Her iki modelde de ortak gereksinim geri alınabilirliktir. Hızla geri döndürülemeyen otomatik bir dağıtım riski azaltmaz, artırır.

Ortam ve altyapı yönetimi: konteyner ve IaC

Ortam farklarının en etkili çözümü, ortamları elle değil tanımlarla kurmaktır.

Konteynerleştirme, uygulamayı çalışması için gereken bağımlılıklarla birlikte paketler; böylece aynı paket geliştiricinin makinesinde, test ortamında ve üretimde aynı biçimde çalışır. Konteyner, sanal makineden farklı olarak işletim sistemini paylaşır, bu yüzden daha hafif ve hızlı başlar. Önemli olan araç değil, paketin taşınabilir olmasıdır.

Altyapı kod olarak (Infrastructure as Code, IaC), sunucu, ağ, veritabanı ve izin tanımlarının panele tıklanarak değil, sürüm kontrolünde tutulan dosyalarla oluşturulmasıdır. Altyapı da kod gibi gözden geçirilir, sürümlenir ve yeniden üretilebilir; “bu sunucuda hangi ayar açıktı?” sorusu tahminle değil dosyaya bakılarak yanıtlanır.

Bu iki yaklaşım birlikte, ortamların sessizce birbirinden sapmasını engeller. Teknik borç rehberimizde anlattığımız birikimli maliyet mantığı burada da geçerlidir: belgelenmemiş, elle yapılmış altyapı ayarları en yaygın teknik borç türlerinden biridir.

İzleme ve olay yönetimi

Teslim hattı kurulduktan sonra soru değişir: “Yayına alabildik mi?” değil, “Yayına aldığımız şey çalışıyor mu?” İzleme, sistemin sağlığını sürekli gözlemler ve üç katmanlı düşünmek yararlıdır:

• Teknik metrikler: Yanıt süresi, hata oranı, kaynak kullanımı, kuyruk uzunluğu.
• İş metrikleri: Sipariş, kayıt, ödeme gibi işin kalbindeki akışların başarı oranı.
• Kayıtlar ve izler (logs, traces): Sorunun hangi istekte ve hangi bileşende oluştuğunu gösteren kayıtlar.

Olay yönetimi, bir kesinti anında ne yapılacağının önceden tanımlı olmasıdır: kim haber verir, kim müdahale eder, müşteri nasıl bilgilendirilir, olay sonrası kök neden nasıl analiz edilir. Kesintisiz sistem yoktur; önemli olan kesintinin süresi ve aynı hatanın tekrar edip etmediğidir.

Ekip yapısı ve sorumluluk paylaşımı

DevOps’un kültürel tarafı, en zor ve en kalıcı kısmıdır. İki yaygın model vardır. Ürün odaklı ekiplerde her ekip, bir ürün parçasının hem geliştirmesinden hem üretimdeki çalışmasından sorumludur. Platform ekibi modelinde ise ortak bir ekip, diğerlerine kendi kendine hizmet eden bir teslim ve altyapı platformu sunar.

Türkiye ölçeğindeki çoğu ekip için ikinci model, yani platform sorumluluğunun küçük ama ayrı bir uzmanlık olarak kurulması daha gerçekçidir. Hangi model seçilirse seçilsin kritik ilke aynıdır: sorumluluk, sorunu çıkaran yerden kaçırılmaz.

Bu paylaşım sözleşmeye de yansımalıdır. Mevcut bir sistemi devralırken veya yeni bir proje başlatırken, kimin hangi ortama erişimi olacağı, dağıtımı kimin tetikleyeceği ve izleme verisinin kime ait olduğu baştan yazılı olmalıdır. Bu başlıkları kurumsal yazılım çözümleri rehberimizde ele alıyoruz.

DevOps’a geçişte gerçekçi bir yol haritası

Mevcut bir ekibi olan bir KOBİ için DevOps’a geçiş, her şeyi bir seferde kurmak anlamına gelmez. Sıralı bir yol daha kalıcıdır:

1. Görünürlük kurun. Mevcut durumu yazın: sürüm kontrolü kullanılıyor mu, dağıtım kaç adım, hangileri manuel, kesintiler nereden çıkıyor.
2. En acı veren adımı otomatikleştirin — genellikle manuel dağıtım veya test. Tek adımla başlamak, kapsamlı bir dönüşümden daha hızlı sonuç verir.
3. Test ve derlemeyi hatta bağlayın. Her değişiklikte otomatik test çalışmıyorsa otomasyon güven vermez.
4. Ortamları tanımla kurun; bu, ortam farklarını kalıcı olarak azaltır.
5. İzleme ve uyarı ekleyin. Ne ölçtüğünüzü bilmiyorsanız iyileşip iyileşmediğinizi de bilemezsiniz.
6. Geri alma pratiği kurun. Hızlı geri dönüş, hızlı ilerlemenin ön koşuludur.

Bu sıralamada her adımın tek başına değer üretmesi önemlidir; kazanç, bir yıllık programın sonunda değil, ilk otomasyon adımından itibaren görünür olmalıdır.

Hangi durumda DevOps gerekmez?

DevOps her proje için doğru cevap değildir. Şu durumlarda tam kapsamlı bir dönüşüm gereksiz bir yatırım olabilir:

• Nadiren değişen, iç kullanımda bir araç yazılımı
• Kesinti maliyeti düşük ve kullanıcı sayısı sınırlı bir sistem
• Ömrü kısa, tek seferlik bir kampanya veya rapor uygulaması
• Ayda birkaç kez değişen bir iç panel

Bu durumlarda bile asgari hijyen gereklidir: sürüm kontrolü, düzenli yedekleme, belgelenmiş bir yayın süreci ve temel izleme. Fark, bu süreçlerin tam otomatik değil, tanımlı ve tekrarlanabilir olmasıdır.

Sık yapılan hatalar

• Araçla başlamak. Süreci tanımlamadan CI sunucusu satın almak, dağınık bir süreci yalnızca daha hızlı dağınık hale getirir.
• Otomasyonu tek seferlik kurmak. Bakımı yapılmayan bir hat kısa sürede güvenilmez hale gelir ve ekip ona güvenmeyi bırakır.
• Her şeyi aynı anda değiştirmek. Kültür, süreç ve altyapıyı birlikte dönüştürmek, genelde hiçbirinin tamamlanmamasıyla sonuçlanır.
• Yalnızca hıza odaklanmak. Geri alma, izleme ve test olmadan artan dağıtım sıklığı kesinti riskini artırır.
• Sorumluluğu tek kişiye yüklemek. Bir “DevOps kişisi” atayıp ekibin geri kalanını süreçten muaf tutmak kültürel değişimi engeller.
• Ölçmemek. Darboğazı bilmeden yapılan iyileştirmeler çoğu zaman yanlış yeri hedefler.

Kontrol listesi

Mevcut durumunuzu değerlendirmek için şu soruları kullanabilirsiniz:

• Kod tek bir sürüm kontrol sisteminde ve ana dal her zaman çalışır durumda mı?
• Her değişiklikte otomatik derleme ve test çalışıyor mu?
• Dağıtım tek komut veya tek onayla yapılabiliyor mu?
• Üretim ortamları elle değil, tanımlarla mı kuruluyor?
• Yanıt süresi, hata oranı ve iş metrikleri izleniyor mu?
• Son dağıtımı geri almanız gerekse bunun ne kadar süreceğini biliyor musunuz?
• Bir kesinti anında kimin ne yapacağı yazılı mı?

Bu soruların çoğuna “hayır” diyorsanız, maddelerin her biri bağımsız ele alınabilir; en acı veren noktadan başlamak yeterlidir.

Sonraki adım

DevOps, bir ürün satın alarak değil, teslim sürecini görünür kılıp adım adım otomatikleştirerek kurulur. İlk hedef kusursuz bir platform değil, tekrarlanabilir ve geri alınabilir bir teslim akışıdır. Bu akış kurulduğunda yayına alma sıklığı ile sistem kararlılığı birlikte iyileşir.

Yayın sonrası görünürlük sorunlarını teşhis etmek için web siteniz Google’da görünmüyorsa izlenecek adımları da inceleyebilirsiniz.

Mevcut yazılımınızın teslim sürecini değerlendirmek, manuel adımları otomatikleştirmek veya CI/CD hattını sıfırdan kurmak isterseniz, özel yazılım projelerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Grup şirketimiz Web Tasarım Ofisi de web projelerinde teknik altyapı ve sürdürülebilir bakım konusunda destek veriyor.