DevOps

Merhaba;

Bugün uzun zamandır araştırdığım oldukça gizemli bir konuda yazmaya karar verdim. Ne olduğunu tahmin ettiğinizi düşünüyorum: DevOps.

DevOps, çok genel anlamda, dizayn ve development süreçlerinden, production desteğine kadar tüm servis yaşam döngüsü sürecinde operasyon ve development mühendislerinin birlikte etkileşimli çalışması olarak ifade edilebilir. DevOps, birbirinden bağımsız grupların her bir süreci ayrı ayrı yönettiği geleneksel yaklaşımın yerini alan çevik, yeni bir yaklaşımdır. DevOps yaklaşımı, kodu yazan, test eden, deploy eden ve operasyonu yapan grupların farklı olduğu modeli, grupların etkileşimli, birlikte çalıştığı ortak araçlar kullandığı çevik bir yapıya dönüştürmektedir.

Organizasyonlar neden DevOps’u önemsiyor? DevOps, bizler için yeni olarak ne sağlıyor? Öncelikle DevOps yaklaşımının, IT ve iş çıktılarını verimli bir şekilde iyileştirdiği ispatlanmış bir gerçektir. Değişikliklerin daha hızlı deploy edildiği, yaşam döngüsü boyunca daha az hata ile karşılaşıldığı, çıkan hataların daha hızlı giderildiği yapılan tetkiklerde bu yaklaşımı kullanan organizasyonlarca teyit edilmiştir. Daha fazlası, süreç içerisinde plansız çalışma sayılarının azaldığı, çalışanların birbiriyle daha sinerjik, işbirlikçi, yapıcı çalışma birlikteliğinin arttığı, iş stresinin azaldığı yine bu yaklaşımın olumlu çıktıları olarak karşımıza çıkmaktadır.

DevOps, development ve operasyon kelimelerinin birlikte kullanılan hali olarak karşımıza çıksada, kesinlikle bu yaklaşım diğer ekipleri oyun dışında bırakmıyor. “Ops” kısmı, yine Network mühendisleri, Database yöneticileri, Linux yöneticileri, aslında sistem tarafında olan tüm rolleri, çatısı altında topluyor. “Dev” tarafında da aynı şekilde, çekirdek kodu yazanlardan, ön yüzü tasarlayanlara kadar, QA’de dahil herkesi aynı şekilde çatısı altında topluyor. Bir yazılımın, çözümün ortaya çıkarılmasına katkı sağlayan tüm ekiplerin beraber verimli ve etkin çalışmasına imkan sağlaması, DevOps’un temelini oluşturmaktadır.

CAMS model, DevOps’un öncülerinden John Willis ve Damon Edwards tarafından oluşturulmuştur. CAMS’ın açılımı, “Culture, Automation, Measurement ve Sharing” dir. DevOps’un babası sayılan Patrick DuBois, DevOps’u kültür ve iş problemi olarak ifade ediyor. Kültür derken, hepimiz biliyoruz, bir problem olduğunda yuvarlak masa etrafında herkes birbirine suç atma eğilimindedir. Oysa ortak paydada buluşulsa ve herkes problemi çözmeye dönük olarak hareket etse sonuç daha farklı olmaz mı? Karşılıklı anlayış ve çözüme odaklı işbirlikçi bir yaklaşımın organizasyonun kültürü olarak çalışanlara aşılanması gerekmektedir. DevOps’da öncelik insanlardır. İnsanlar, süreçlerin ve araçların üstündedir. Kültürü değiştirdikten sonra, araçlar ve uygulamalar zaten kolayca sürece adapte edilebilir. Otomasyonu sağladıktan sonra, ölçümleme yapılması gerekir. Acaba yapılan değişiklikler herhangi bir iyileşme yapmış mı kısmının ölçülmesi gerekir. Doğru metriklerin belirlenmesi önemlidir. DevOps yaklaşımı, tüm organizasyonu ölçümleyecek metriklerden yanadır. CAMS’da bahsedilen “Sharing”, aslında beraber çalışmanın temelini oluşturmaktadır. Fikirlerin ve problemlerin objektif olarak paylaşılması sürecin etkin bir şekilde devamlılığını ve devamlı iyileşmesini sağlayacaktır. “Culture, Automation, Measurement ve Sharing”, birbirini karşılıklı pekiştiren dört ana esas olarak DevOps’un temelini oluşturur.

DevOps yaklaşımını hayatımıza uygulamak için temel ilkeleri bilmemiz önemlidir. En çok kullanılan Temel ilkeler, “three ways” olarak çağrılan, Gene Kim ve Mike Orzen tarafından geliştirilen modeldir. Bu model öyle bir sistemi önerir ki, bu sistem düşünecek, geri besleme çevrimlerini güçlendirecek ve sürekli bir deneyimleme ve öğrenme ortamı sunacak. Öncelikle sürecin, içinde bulunan tüm bileşenlere olan etkisini irdeleyerek çalışmalar yapılmalıdır. Örneğin, uygulama sunucu sayısını artırırken, veri tabanı sunucularında aşırı bir yük oluşturmuyor olmalıyız. Geri besleme çevrimlerini güçlendirmek derken, süreçte yer alan tüm ekiplerin birbiriyle karşılıklı konuşma yollarını kısaltmaktan, tüm ekipler arasında akışkan bir iletişim hattı oluşturmaktan bahsediyoruz. Örneğin, bir bug’ı, developer’ın bulup hemen düzelttiği bir durum ile, QA ekibi tarafından bulunup düzeltilmesi veya müşterinin bulup çağrı açarak düzeltilmesinin sağlanması arasında önemli farklılıklar vardır. Gruplar arasında kolay, etkili, akışkan geri besleme çevrimlerinin oluşturulması, daha kaliteli bir ürünün ortaya çıkması için olmaz ise olmazlardandır. Ekipler, standartları ve süreçleri oluştururken hedef, devamlı bir deneyimleme ve öğrenme kültürü oluşturulması olmalıdır. Ekiplerin yeni şeyler paylaşmasını, yeni fikirler ortaya atmasını teşvik etmemiz gerekiyor. Mühendisler, iyi birer problem bulucu ve çözücü olmakla beraber yeni teknolojileri denemeye genelde negatif bakarlar. Bu eğilimleri ortadan kaldıracak bir kültür oluşturmak mükemmele giden bir yol olarak organizasyonların gelişimlerine büyük katkılar sağlayacaktır.

İşlerimizi kolaylaştıracak araçları hepimiz çok seviyoruz. Günümüzde karşımıza pek çok araç çıkıyor. Ücretsiz ve açık kaynak kodlu olanlar, açık kaynak kodlu araçların desteği olacak şekilde enterprise olarak markete sunulanlar, ticari olanlar. Bu güzel bir şey fakat bir yandan da araç seçimlerimizde daha dikkatli olmamızı gerektiriyor. Seçtiğimiz araçlar birbiriyle uyumlu çalışabilmeli ve gerçekten iş ile ilgili amacımızı çözebilmelidir. Araçlar sayesinde, kodu daha etkin geliştirebiliyoruz, build, test, paketleme, sürüm çıkarma, konfigürasyon süreçlerini otomatik hale getirebiliyoruz ve sistem ve uygulamaları gözlemlemleyebiliyoruz. Araç seçimi yaparken tek kriterimiz elbette fiyatı değil, ürünün öğrenme süreci, ne derece kullanışlı olduğu, destek süreçlerindeki güvenilirlik, ürün seçimimizde önemli faktörler olarak karşımıza çıkıyor. Yeni araçlar, bize inanılmaz özellikler, fonksiyonlar sunarken, bu araçları kullanmadan hala geleneksel yöntemlerle işlerine devam eden organizasyonlar için yeni araçlar bir tehdit olarak karşılarına çıkacaktır. Yenilikçi bir organizasyon benzer ürünü 6 ayda çıkarırken bu araçları kullanmayan teknolojinin gerisinde kalan organizasyonların çok daha uzun sürelerde ilgili çözümü markete sunmaları kendileri için büyük bir kayıp anlamına gelmektedir. Araç seçiminde, aracın bir API’den veya komut satırından çağırılabiliyor olması önemlidir. Aracın gerçekten yapıyorum dediklerini kullanmaya başlamadan önce doğrulamak gerekir. Aracın gerek developer’lar gerekse operasyoncular tarafından ihtiyaca uygunluğunun irdelenmesi, aracın “source control” sistemlerine entegre edilebilmesi, aracın bir dizi test fonksiyonuyla gelmiş olup fonksiyonlarının bu testlerle doğrulanabilmesi ve otomatik olarak deploy edilebilmesi önemlidir.

Hepimiz “Waterfall” model ile yazılımın nasıl geliştirildiğini biliyoruz (Şekil 1.). “Agile” geliştirme sürecinde ise, “Waterfall” da olduğu gibi bir adımı tam bitirip daha aşağıdaki adıma geçmeden, tüm takımlar daha sık beraber çalışma imkanı bularak süreçleri dairesel bir döngü içerisinde yerine getirirler (Şekil 2.). “Agile” yaklaşımında operasyon tarafı eksiktir. Aynı şekilde altyapının oluşturulduğu, yazılımın deploy edildiği ve production ortamında sürekliliğinin sağlandığı kısımları da içermez. Yani görüyoruz ki “Agile” yaklaşımı tek başına DevOps sürecini oluşturamıyor. Aslında bu noktada “Lean” yaklaşımı da devreye giriyor. “Lean” yaklaşımı, ilk olarak W. Edwards Deming ve Taiichi Ohno tarafından geliştirilmiş. “Lean” yaklaşımının amaçlarından biri, geliştirme sürecinin devamlılığını sağlamaktır. Bu hedefde, sürekli geliştiren süreçleri devreye alarak yapılabilir. “Agile” metodu, “Lean”in sunduğu çerçeve ile genişletilerek DevOps yaklaşımı elde edilebilir.

Şekil 1. Waterfall Model.

Şekil 2. Agile Development Process

Şekil 3. “Waterfall” ve “Agile” Süreç Karşılaştırması

DevOps’u, “Continuous Delivery:CD” ve “Continuous Integration:CI” den bahsetmeden tam olarak ifade etmiş olmayız. CD sayesinde, elinizde bulunan bir uygulama ile kodun “commit” işlemi otomatik olarak yapılır. Unit testler çalıştırılır ve uygulama production benzeri ortamlara deploy edilir. Kabul testleri otomatik olarak çalıştırılır. Kod her daim çalışır durumdadır. CI sayesinde tüm uygulama daha sık built edilir ve unit testleri çalıştırılır. CD ise, ek bir pratik olarak yapılan her değişikliğin production benzeri ortamlarda deploy edilmesini sağlar. “Continuous Deployment”, CD’nin daha genişletilmiş halidir. Her değişiklik, yeterli tam otomatik test sürecinden geçer. Facebook, “Continuous Deployment” kullanır.

Red Hat OpenShift çözümüyle, “Continuous Integration”, “Continuous Delivery” ve “Continuous Deployment” süreçlerini başarıyla hayata geçirerek yazılım dağıtım süreçlerinizi ( “software delivery”) otomatik hale getirebilirsiniz. OpenShift’e, DevOps yaklaşımını hayata geçirebilmeniz için gereken teknoloji gözüyle bakabilirsiniz.

Şekil 4. Sürekli Geliştirme

Yazdıklarımızı Şekil 4., çok güzel özetliyor. Build, Test, Release, Deploy, Operate, Monitor işlemlerinizi, CI/CD araçlarınızın OpenShift’e entegrasyonunu sağlayarak “Software Delivery” yaşam döngünüzü sürekli gelişen, sürekli değerlendirilen, doğrulanan bir yapıya çevirebilir “Infrastructure as a Code” hayalinizi gerçekleştirebilirsiniz.

Asiye Yigit – 10 Kasım 2019

Kaynakça:

https://theagileadmin.com/what-is-devops/

https://www.atlassian.com/devops

https://www.planview.com/resources/articles/agile-and-lean/

https://www.linkedin.com/learning/devops-foundations/devops-principles-the-three-ways

https://raygun.com/blog/best-devops-tools/

https://www.guru99.com/devops-tools.html

https://assets.openshift.com/hubfs/pdfs/DevOps_with_OpenShift.pdf?hsLang=en-us

DevOps Fundamentals: Gain Solid Understanding (Updated Course – New Lectures Added)