Devops’ta kodu analiz ettik — Continuous Analysis
Merhabalar,
Devops yazı dizimizde işleri nasıl hızlandırdığımızdan bahsettik. İşlerimizi hızlandırırken technical debt’i nasıl azalttığımızdan bahsetmek için bir yazı yazmaya karar verdim. Burada tooling’den de biraz bahsedeceğim ama asıl dokunacağım nokta sürekli analizi nasıl geliştirme sürecinizin bir parçası yapacağınız hakkında olacak.
Ufak bir hatırlatma yaparak yazıma başlayacağım. Özellikle hem Türkçe’sini hem İngilizce’sini yazdığım, aynı anlam ifade eden şeyler çok fazla. Bunu kasıtlı yapıyorum çünkü; ülkemizde herkes her şeyi sadece İngilizce ya da sadece Türkçe kullanmıyor. Başkası bir terimi ya da olguyu farklı bir şekilde söylerse sizin kafanız karışmasın. Bu yaklaşımımın yanlış olduğunu düşünen varsa DM’den yürüsün konuşalım 🙂
Serinin 4. yazısı olan bu yazının öncesini de okumak isterseniz buradan buyrun.
2 — Devops‘a nasıl başladık? — Analiz
3 —Devops’a nasıl devam ettik? — Build & Automation
Technical Debt’i anlamak
İlk olarak technical debt nedir onu bir sorgulayalım. Burada size kitap tanımı gibi şeyler anlatmam, bunu zaten yüzlerce yazılmış o yazılardan ve kitaplardan öğrenirsiniz. Ben size teknik borcun gerçekten ne anlam ifade ettiğini anlatacağım.
Teknik borç demek şu demek; bugün aceleyle bug fixledin topladın her şeyi ama kodu kötü kötü yazdın, sonra orayı refactor etmen ya da o koda dokunan bir geliştirme yapman gerekti, işte orada; püü nasıl toplucam burayı?! bu nasıl kod?! diyoruz ya işte o teknik borç oluyor. Yani 5 dakika daha uğraşarak temiz bir şey çıkarmak yerine geleceğinizden katlarıyla süre çalıyorsunuz! Kısacası dün yazdığın kötü kodlar gelir, bugün delirtir demek.
Teknik borcu ölçen ve tahmini bir süre veren çok fazla tool var ama oradaki sayılar her zaman bir anlam ifade etmiyor. Durum, o sayılara nasıl baktığınızla alakalı değişiyor.
Kodu analizden geçirmiştin ya bu ne?
Bu lafı çok kişi diyecek eminim, 3. adımda dedik analiz yaptık vs. diye. Olay şu kodu analizden geçirmek asıl mevzu değil o basit. Ben burada işin kültüründen ve bu kültürü nasıl force’ladığımızdan bahsedeceğim. IT’S NOT THE JEDI WAY! diyen olursa biz zaten Sith’iz arkadaşım, haberin olsun da.
Neden Jedi Way ile gitmedik kibar kibar ondan bahsedeyim. Abi analizde birşeyler kötü gelmiş, bunu bir dahakine dikkat edelim diyerek olmuyor. Olayın kilit noktası bu. Analizde sen o comment’i yazmazsan, o testi eklemezsen, variable’ları a,b,c diye tanımlarsan, otomatik reddetmektir asıl olay. Gerçek bir Sith gibi acımasız bir şekilde kodumuza hükmetmeliyiz.
Bunu tooling olarak nasıl mı yaptık? Bitbucket’ın webhook’ları, Sonarqube’un webhook’ları, biraz Jenkins ve powershell magic ile.
Bu sistemi nasıl işlettik?
Hikayemiz şu şekilde işliyor. Developer test’e yollar eğer herşey tamam ise PR(Pull request) atar. Ben bunu mergelemek için girmeden önce şöyle bir şey görürüm.
Eğer icon yeşilse (yukarıda sol) testler tamam, Sonarqube’den gelen analiz sonucu tamam demek. Eğer değilse zaten otomatik reddedilir ve developer kodunu düzenler. Her şey tamamsa review ederim, o da tamamsa staging’e bakan branch’imize mergelenir ve staging ortamlarında beta yayınlanır ve zaten UAT’den geçmiş kod prod’a doğru bir yolculuğa çıkar.
Sistem perspektifinden ise olay kısaca şöyle;
Bitbucket her pull request’te bir webhook atarak, Jenkins’imizi uyarıyor. Jenkins kodu build ediyor ve analizi için Sonarqube scanner’ı çalıştırıyor ve Sonarqube’den belirli bir token ile geri bir webhook gelene kadar Jenkins bu pipeline’ı bekletebiliyor. Buradan success sonucu gelirse pipeline devam ediyor ve devamı uygunsa build başarılı deyip aşağıdaki görüntüde de görebileceğiniz gibi yeşil tick oluyor.
O yeşil tick olması için çalışan süreç aşağı yukarı böyle;
Developer açısından ise şöyle
Developer’larımız şu şekilde bir yakarış yaptılar. E PR atana kadar ben bilmiyorum ki analize uygun mu, sonra ben onu düzeltmek için geri döndüğümde mevcut işimi bırakmam gerkeiyor ve vakit kaybediyorum. E sonuna kadar haklılardı. Yeterli bir pipeline kurmamıştık. Bunu şu şekilde geliştirdik. Herkes Visual Studio’larına resharper kurdu bunu yavaş bulanlar ise sonarlint kurdu. Kodunu yollamadan analizine localinde bakma sorumluluğu developer’da oldu ve sorun ortadan kalktı.
Zamanla bu tempoya alışan ekibimiz analizde sıkıntı var comment’i unutmuşum gibi durumlarla kendisi bu pipeline’ın bir parçası oldu. Eğer sistemi kurarsanız işe yaramaz, ama herkesi sistemin bir parçası yaparsanız işte o çalışır. Biz bunu öğrendik.
Bu işi amaç edinmiş olan benim açımdan olay şöyle
Kod kalitesi arttıkça, teknik borç azaldıkça WTF per minute azaldı. Bu metric’i bi yerde bulamazsınız kulağınızla duymanız ve saymanız lazım 🙂 WTFpm dediğimiz şey aşağıdaki resimde gayet net diye düşünüyorum.
Sonarqube’de quality gateleri kontrol ederek tüm yapılarımızın kod kalitesine merkezi tek bir noktadan hükmetmek beni zaman açısından çok rahatlattı. Mesela şu an kafam tamamen rahat, bir analiz başarılı ise başarılıdır nokta. Her geçen gün kalite standartlarımızı daha da çetinleştirerek daha yüksek kod kalitesi sağlamak için takipte kalıyorum. Her ay seviyeyi bir adım ileri taşıyarak, kod kalitesini tavan yaptırma peşindeyiz. Şu an çok iyiye gittiğimizi görebiliyorum. Her metric olarak hem geliştirme hızı olarak etkisi yüksek. Benim temel metric’im geliştirme hızı ve takımın bu konudaki mutluluğu.
Sonuç olarak iyiye gitmek için temel şey pipeline sadece kod ya da Jenkinsdeki bir pipeline komutu değildir. Pipeline tüm tooling’lerle beraber developer’dır, kodun kendisidir, analistlerdir, pm’lerdir hatta tüm yöneticilerdir. Bunların sesine kulak vermektir, sadece kırmızı renkli o hatalar tooling’den gelmez, developerdan da gelebilir. Bu geliyorsa evet hata var, tooling hataları basittir, 2 satır yazar çözersiniz, kişilerden gelen hatalar daha zordur, onlar için yapınızı hatta kültürünüzü fix’lemeniz gerekir. Bir dahaki yazıya kadar esenlikle kalın.
Saygılarımla.
