Devops‘a nasıl başladık? — Analiz
Merhabalar herkese,
Önceki yazımızda Devops yaptık da n’oldu? diye anlatmıştık. Bu yazının devamı olarak kullandığımız araçlar ve dev ortamımızdan bahsetmenin faydalı olacağı kanısındayım. Bir şeyler anlatıp bunlar güzel demek tam olarak doğru olmuyor. Her firmanın geliştirme ortamı farklı, ihtiyaçlar farklı. Bu yazıda Hesapkurdu.com arge ekibi olarak biz ihtiyaçlarımızı nasıl çözdük ve sonuç olarak nasıl bir ortam yapısı kurduk, işte bunu anlatacağız.
Biz işe sıfırdan başladık. Bu açıdan yaklaşımlarımız ve tecrübelerimiz bu tip otomasyon ve devops işlerine girecek kişilere faydalı olacağını düşünüyorum. Umarım da öyle olur 🙂
Bizim ortamımızdan önceki yazmızıda da bahsetmiştim o yüzden detaya girmiyorum. Kısaca tech stack’imizde ki başlıca ürünleri sıralarsam;
Dil ve teknoloji olarak, backend C#, .Net, MVC 5, WebApi; frotend için angular, Jquery, Sass, gulp gibi teknolojiler kullanıyoruz. Aktif olarak cloud kullanıyoruz ve provider olarak AWS(Amazon) kullanıyoruz. Geliştirme aracı olarak Visual Studio 2017 zaten mecbur :) O zamanki tech stack’imiz buydu şu an apayrı alemlerdeyiz. Bunları o anki ortamımız neydi, şimdi neyiz karşılaştırması yapmak için yazıyorum. Şu ankinden kısaca bir spoiler verirsem .net core ve docker orchestration ile ciddi bir çaba içerisindeyiz ;)
Bu kadar giriş yeterli sanırım. Ortamlarımız hakkında merak ettiğiniz şeyler olursa yorum atabilirsiniz ya da bana da yazabilirsiniz. Merak etmeyin çok aktif olarak cevap veririm :)
Tanınmayan bir code base’imiz ve nasıl davranacağı kestirilemeyen bir yapı içerisindeydik. Ne zaman, nasıl deployment yapacağımız konusunda bile çokça soru işaretimiz vardı. Deployment sonrası dua ederek bu sorunun çözülmeyeceği aşikardı. Bu yüzden ilk olarak sistemimizi, kodumuzu ve ortamımızı tanımakla başladık. Ürün ekipleriyle konuştuk, ihtiyaçları daha iyi anlamalıydık. Developerlarla konuştuk canlarını en çok ne sıkıyordu çözmemiz gerekiyordu.
Ürün, UX, SEO ve marketing ekipleri tek bir noktada birleşiyordu. Testi yapılan geliştirmeler canlıya çıkıştan sonra farklı davranışlar gösteriyordu. Dolayısıyla geliştirme merge’lenince diğer yerlerde bozulmalar oluyor, bi’ yerde bir şey bozulsa haberimiz olmuyor, UAT’de sıkıntılar yaşıyoruz, test ortamlarımızdaki testlerde sıkıntısız olan şeyler production ortamında hatalı şeylere dönüşüyordu.
Sorun çok barizdi, kodlar dev ortamında farklı testte farklı pre-prod’da apayrı olabiliyordu. Bunu inceledik. Feature branch yapısıyla geliştirme yapıyorduk (bilmeyenler için bknz. git feature branching). Gözümüzden merge kısımlarında birşeyler kaçtığı çok barizdi. Test ortamlarının sayısı ve configuration yapısı yetersizdi. Test ortamlarına elle dosyalar atılıyordu. Test ortamını barındıran sunucu da pek iyi durumda sayılmazdı.
Developerlara sorunca ise ortak nokta belliydi. Bir standard yoktu, test yoktu, kodun kalitesi belirsizdi. İlk olarak bunları belirlemekle işe başlayalım dedik. Kendimize prensip olarak en çok sorun olanı belirleyip onu çözmek ve o şekilde ilerlemeyi seçtik. Bu şekilde her zaman listenin en üstünde sorunları çözdük, diğer sorunlar da kendiliğinden yok olmaya başladı.
Kodu analiz ettik kalitemizi öğrendik. Burada open source bir ürün olan Sonarqube’ü kurduk. Kodu analizden geçirdik ve aksiyon planı listemizi hazırladık. Çıkan sonuçtaki kod bloklarını tek tek temizlemek baş edilecek bir iş değildi. Burada test yazıp kritik alanları code coverage altına almamız çok önemliydi, çok köklü değişiklikler yoldaydı ve yapımızın temel işleyişi bozulmamalıydı. Burada Resharper Ultimate’den büyük bir destek aldık. HotSpot (bu daha sonra hayatımızı kurtardı!) özelliğinden faydalanarak kodda en çok çağrılan noktaları belirledik ve buraları refactor ettik. Kontrol altında tuttuk. Ve sonunda gerçekten ellerimizi kirletmeye hazırdık.
Sonarqube ve benzeri kurulumları yapıp orada bırakmadık! Eğitimler düzenledik Sonarqube nedir, ne işe yarar, ne faydası olacak diye konuştuk, sunumlar yaptık. IT ekibinin bunu sahiplenmesini sağladık.
Bunları yaparken mevcut uygulamaların sabit kalabilmesi için Slack üzerinden ürün ekipleriyle sürekli halde iletişimdeydik. Ayrıca developer’lara Sonarlint kurduk ve kod kalitemizi sabitlemeyi başardık.
Tabi bunları yaptık ama bunlar elle olacak değildi. Artık otomasyonlara bir an önce başlamamız lazımdı. Burada Jenkins’i kullandık. Open source bir ürün, çok fazla extension seçeneği var, çok genişleyebilen bir ürün ve startup bir firma olduğumuz için minimum gider ile bunu çözmenin yolu Jenkins’ten geçtiğini düşündük (İyi de oldu).
Source control için git ve provider olarak Bitbucket kullanıyoruz. Webhook’ları inanılmaz derecede işlerimizi kolaylaştırıyor. Jenkins ile webhook’ları yakaladık, master ve dev branch’lerimize gelen her push’u yakaladık ve sonarqube’den geçirdik. Dolayısıyla burada MSBuild kullanımı da başlamış oldu. CLI üzerinden Debug ve Release olarak kodumuzu build etmeye başladık. Nuget CLI kullanımı da .Net ekosistemi için olmazsa olmaz bir durum.
Burada bir önceki commit/push ile karşılaştırmalı olarak analiz raporları oluşmaya başladı. Biz de bir yandan ürün ekipleriyle ihtiyaçlar ve IT road map için toplantılar yaparak devam ettik.
Burada ürün ekiplerinin ilk ve en büyük sorunu çözmek için bir adım atmalıydık. Burada çözüm Pull Request’lerle geldi. Master ve dev branch’ine herkesin check-in yapabilme yetkisini kaldırdık. Developerlar kendi branch’lerinde çalışacak,işini bitirecek, teste yollayacak, testler başarılı olursa, Pull Request’i atılacaktı. Bu akışı kullanarak code review yapılmasını da zorunlu kıldık. Her pull request’in 2 tane reviewer’ı olmak zorunda. Bu kişiler yapılan değişikliğe hızlıca bakıp bariz gözden kaçan bir şey varsa yakalayabiliyor ve iyileştirmeler için tavsiyede bulunabiliyor. Code review’larla kod içerisindeki hatalı mimari aksiyonların, bariz sorunların ve test ortamlarındaki problemlerin önüne geçtik. Pre-prod ortamlarındaki sorunları da ciddi şekilde azalttık ama hala entegrasyon kaynaklı sorunlarımız var. Bunları çözmek için aksiyon planları da yolda!
Demek ki herkes bir şeyleri kendi merge’leyince bir şeyler bozuluyormuş:) Bu sayede hem tecrübe paylaşımı hem de kod kalitesinde inanılmaz bir ivme yakaladık. Bu sayede ürün ekiplerinin en önemli gördüğü sıkıntıyı aştık. Şu an hiç böyle bir şey duymuyoruz. CDN’in dertleri hariç, nabalım o cache ve CDN işleri hiçbir zaman kolay olmadı. Buradan Amazon’a bir sitemde bulunayım.
Raporlar takip edildi ve kod kalitesini korumak bir IT kültürü oldu. Daha sonrasında da şirket kültürü… Unutmayalım devops bir ürün veya araç değildir, bir kültürdür! Devops’u şirket kültürü yapabildiğiniz noktada halka tamamlanır. Bir halkanın ilk zincirini sistemimizin ilk olarak da yazılım merkezli bir şirket olarak kodumuza koyduk.
Sonarqube, Bitbucket webhooks, Jenkins kullanımlarımız hakkında yazılarımız geliyor, takipte kalın!
