11 farklı ülkede 50’den fazla firmaya hizmet veren, 35’in üzerinde bankada ürünleri kullanılan bir firma olan Intertech, 20 milyondan fazla bankacılık müşterisine hizmet sunuyor.
Jez Humble’ın “For the love of god, stop calling Ops teams ‘DevOps teams’. DevOps is a movement / way of working, not a role, or a team.” sözüne dikkat çeken Salih Eligüzel, DevOps’un sadece otomasyon ya da konteyner teknolojilerinin kullanılması olmadığını vurguladı. “DevOps aslında bir kültür ve düşünce yapısı dönüşümü. Sadece bir ekibin ya da grubun DevOps ile dönüşmesi değil, tamamen yaptığınız işteki kültür dönüşümü aslında, bununla ilgili yaptığımız aksiyonların adına da DevOps diyoruz, ana felsefeyi ve yaklaşımı hiçbir zaman unutmamak lazım.” diyerek görüşlerini ifade etti.
Salih Eligüzel DevOps sürecinin başlatılmasında etken olan sorunların temel olarak 4 farklı sınıfa ayırdı;
- İsterlerin net olarak iletilmemesi
- Ortamlar arası farklar
- Ekipler arası uyumsuzluklar
- Uygulama Konfigürasyon Farkları
DevOps Öncesi Yazılım Geliştirme Süreçleri
Öncelikli olarak problem analizi yaptıklarını belirten Salih Eligüzel ilk olarak Intertech’in genel olarak resmini çizdiklerini ifade ederken bu yolculuğa yaklaşık 3 sene önce başladıklarını belirtti. Bu dönüşümün başında, amaçlarının belirli teknolojileri kullanmaktan ziyade, kültür dönüşümümüzü nasıl gerçekleştirebiliriz sorusuna odaklandığını ifade etti.
Intertech’in DevOps öncesi karşılaştığı sorunlardan bazıları;
- Merkezi Log Yapısı Yok
- Konfigürasyon Sorunları
- Her Müşteriye Ayrı Taşıma Süreci
- Bütün Ürün ve Müşterilerde Süreç Farklı
- Proje Yönetimi ile Yazılım Süreci Entegre Değil
- Code Review Zorunlu Değil
- Paket Girişi Manuel
- Taşımalar Manuel
- Test Süreçleri Manuel
- Db Taşımaları Hata Oranı Yüksek
- Prod Ortamına Ayrı Taşıma Süreci
- Sunucu Tarafında Servisleri Kontrol Eden Yapı Yok
- Aksiyonlarımız Proaktif Değil
Analizler sonucunda DevOps öncesi dağıtım hatası ve kod borçluluk oranının görseldeki seviyelerde olduğu aktarıldı.
DevOps Sonrasında Neler Değişti?
Continuous Integration
CI tarafına eğilip, eski bir teknoloji olan Cruise Control’u bırakarak bütün pipeline ve akışları Jenkins üzerine taşıdıklarını belirten Salih Eligüzel, Sonarqube ve Fortify gibi ürünlerin de pipelinelarının bir parçası haline geldiğini ekledi.
Bu geliştirmeler sonucunda dağıtım hatası oranı %15 seviyelerinden %0.18’e, kod borçluluk oranının ise sürekli iyileşerek 0.8’e indiği belirtildi, kod borçluluk oranını yükseltecek geliştirmelerin bazı otomasyonlarla engellenerek sürekli gelişime katkıda bulunulduğu ifade edildi.
DB Taşımaları
DB taşımaları yaparken veri tabanlarının çok büyük olmasından dolayı bu sorunu çözmek için Intertech’in kendi yaklaşımını geliştirdiğini belirten Salih Eligüzel, bunu yaparken de yazılımcıları platformlar arası karmaşadan kurtarmak adına Visual Studio üzerinden bu işlemi basitçe gerçekleştirebilecekleri bir ‘helper’ oluşturduklarını ifade etti. Geliştirilen yeni uygulamayı Jenkins ile entegre eden pipelinelar oluşturulduğunun altı çizildi.
Konfigürasyon Yönetimi
MS Powershell yardımıyla yapılan bazı konfigürasyonlar ile Intertech uygulama standartları belirlendi, standartların dışında bir şey yapılmak istendiğinde birkaç satır konfigürasyon eklenerek belirli anahtar-değer ilişkisi içeren komutlar eklenerek bunun yapılmasına imkan tanındı, bununla birlikte taşınan ortamda arzulanan biçimde ve sorunsuzca işlenen yapılar kurulmasına olanak sağlandığı ifade edildi.
Bu sayede belirtilen alanlarda kazanımlar elde edildi;
- Desired State Configuration
- Log
- IIS
- Entegrasyon
- Mikroservis
Test Piramidi
Test tarafında ciddi yatırımların olduğunu belirten Salih Eligüzel, test piramidinin DevOps öncesi istenen yapıda olmadığını fakat son zamanlarda özellikle Unit Test tarafına ciddi ağırlık verildiğini, yeni uygulamalarda zorunluluk haline getirildiğini ve CI yaklaşımı ile sürekli iyileşecek şekilde süreçlerin yürütüldüğünü bizlere aktardı.
Log Yönetimi
DevOps öncesi merkezi log yönetiminin olmadığı ve bunu aşmak için bazı çözümler geliştirildiği aktarılırken, bir bankanın tüm loglarını merkezi bir yerde toplayıp herkesin tek tek uygulama loglarıyla uğraşmasının önüne geçildiği, kolayca yönetilebilecek merkezi yapılar geliştirildiği, bunların da ciddi büyüklükte clusterlar üzerinde tutulduğu ifade edildi.
Release Yönetimi
Salih Eligüzel, release yaklaşımlarının değiştiğini, paket yönetiminin revize edilerek stabilite sorununun çözüldüğünü ve DB paketlerinde hata alınmayacak şekilde mekanizmalar geliştirildiğini ifade ederken, tek tek deploy etmek yerine uygulamayı release ederek müşterilerin bunu kendi mekanizmalarında rahatça kullanabilmesinin önünün açıldığını, bununla birlikte yazılımcıların paket girişi ve release yapmasının sonlandırıldığını ve bu süreçlerin otomatik olarak yönetildiğini de bizlerle paylaştı.
Microservices
Buraya kadar olan kısımların yaklaşımlarla ilgili kısımlar olduğunun altı çizilirken, DevOps’un bir bakış açısının da mikroservisler olduğu ve burada da dönüşümün başladığı ifade edildi. Mikro servisler ile ilgili pipeline aşağıdaki görseldeki gibi oluşturuldu.
Platformun şu an OPENSHIFT ve Anthos üzerinde çalıştığı fakat diğer bulut bilişim platformlarına deploy etmede de bir sorun olmadığı, artık deploy için ekstra bir çalışmaya gerek kalmadığı belirtildi.
Genel Mimari
Mikroservis geliştirme süreci karmaşık bir yapıdayken böyle bir dönüşümde ekibin motivasyonunu da korumanın önemli olduğunu belirten Salih Eligüzel, karmaşık ve takımların birbirine bağımlı olduğu süreçlerin ortadan kaldırılıp ekiplerin bağımsız hale gelmesinin sağlandığını, işlemlerin otomatize edilerek 1 hafta gibi bir süreden yaklaşık 12 dakikaya indirildiğini ve bu sayede önümüzdeki süreçte çok daha hızlı bir biçimde yeni mikroservisler geliştirebileceklerini düşündüklerini belirtti.
DevOps yolculuklarının devam ettiğini belirten Salih Eligüzel hala gelişmeye açık oldukları yerlerin olduğunu, sürekli geliştirip, üstüne koyarak ilerlemeye çalıştıklarını ifade ederken şu an yaklaşık 150 mikroservis’in yayında olduğunu ve çok hızlı bir biçimde deployment ve taşımalarının yapılabildiğini, bir ürün release edildikten sonra aynı anda birden fazla bankaya mikro servislerin dağıldığını ve otomatik olarak deploy olabildiğini, bunların hepsinin değişkeni ve ortamlarının farklı olduğu halde hiç kimsenin bunlara manuel müdahale etmediğini eklerken yolculuklarının devam ettiğini ve daha iyiye taşımak için çalışacaklarını belirtti.
