CI Süreçleri 85% Kısaltıldı: Geliştirici Araçlarıyla Hızlı ve Verimli Bir Geliştirme Döngüsü
CI Süreçleri 85% Kısaltıldı: Geliştirici Araçlarıyla Hızlı ve Verimli Bir Geliştirme Döngüsü
Uzun CI zamanları, geliştirme ekibinin her zaman yüzleştiği bir sorundur. Özellikle projeler büyüdükçe, CI (Continuous Integration) süreçleri zaman alıcı hale gelir ve geliştirme hızını ciddi şekilde yavaşlatabilir. Ancak bu sorun, geliştirici araçlarının ve akıllı stratejilerin doğru şekilde kullanılmasıyla çözülebilir.
Bir geliştiricinin açık kaynak projeleri üzerinde çalışırken yaşadığı bir deneyim, bu süreci 27 dakikadan 4 dakikaya kadar kısaltarak, geliştirme döngüsünü büyük ölçüde hızlandırmıştır. Bu başarı, yalnızca teknik bilgi değil, aynı zamanda akıllı analiz, test stratejisi ve geliştirici araçlarının etkin kullanımıyla mümkün olmuştur.
Proje Durumu: 27 Dakikadan 4 Dakikaya
Proje, 32.000 satır kod ve 15.000 satır test içeren tam bir fullstack Scala uygulamasıydı. Projede yaklaşık 1.000 test bulunuyordu; bunların yaklaşık %60’ı gerçek bir Postgres veritabanı ile çalışıyordu ve bunların içinde yaklaşık %30’u aynı zamanda uygulamanın gerçek bir örneğini başlatmak zorunda kalıyordu. Bu tür testler, gerçek ortamlarda çalıştırılması gerektiğini gösterirken, aynı zamanda CI süresini de ciddi şekilde uzatıyordu.
Projenin başlangıçta 10 dakikadan az bir süre içinde çalıştığı bir template’le başladığına göre, zaman içinde bu sürenin 27 dakikaya kadar uzaması, bir dizi yinelenen test kurulumu ve geliştirme alışkanlıklarının bir sonucuydu. Özellikle her testin kendi Postgres contaner’ını başlatması ve uygulamayı tekrar başlatması, süreyi katlanarak artırmıştı.
Hedefler: Hızlı, Güvenilir ve Etkin
Bu uzun süreyi kısaltmak için geliştirici, üç temel hedef belirlemişti:
- Kod değişikliklerini minimum seviyede tutmak: Bazel gibi yeni bir yapıya geçiş veya Play Framework gibi bir kütüphane değiştirme gibi büyük değişiklikler yapmak istenmemişti.
- Yeni altyapı veya maliyet eklememek: Uzak önbellek sunucuları veya harici servisler gibi ekstra kaynaklar kullanılmamıştı.
- Test kapsamlarını korumak: Gerçek Postgres ve gerçek uygulama testlerinin düşürülmemesi, aynı zamanda gerçek veri işleyişinin korunması gerekiyordu.
Optimizasyon Stratejileri: Ölç, Değerlendir, Uygula
Her fikri bir hipotez olarak ele alarak ve gerçek CI ortamında test ederek geliştirici, dört ana kategoriye ayrılmış bir optimizasyon süreci uygulamıştı:
1. Gereksiz İşlerden Kaçınmak
Proje, her değişiklik için tüm testleri çalıştırıyordu. Ancak geliştirici, bir değişikliğin sadece frontend veya backend’e ait olduğunu belirleyerek, ilgili testleri sınırlamıştı. Böylece, tipik bir PR için sadece gerekli testlerin çalıştırılması sağlanmış oldu.
Ayrıca, testlerde kullanılan parola hashing işlemi, bcrypt ile yapılmıştı. Bu işlem, özellikle testlerde yavaş olmasına rağmen güvenliği sağlıyordu. Geliştirici, bu işlemi gerçek bir kütüphane kullanarak korurken, en düşük maliyetli ayarı seçerek yaklaşık 25 saniyelik bir kazanç elde etmişti.
2. Çok Fazla Başlatma ve Çalıştırma
Testlerin çoğu Postgres gerektirdiği için, her testin kendi container’ını başlatması büyük bir kaynak tüketimiydi. Geliştirici, tüm testler için tek bir paylaşılan Postgres container’ı kullanmaya geçerek bu süreci optimize etti. Bu değişiklik tek başına 15 dakikaya varan bir süre kazandırdı.
Aynı şekilde, uygulamayı her testten önce başlattığından çok, 15 test suite’i içinde bir kez başlatarak zaman kazandı. Ayrıca, sbt gibi bir derleme aracı, her adım için yeniden başlatılmasaydı, süreç daha hızlı ilerleyecekti. Geliştirici, sbt'nin server modunu kullanarak bu başlatma işlemi sayesinde yaklaşık 1 dakikalık kazanç elde etti.
3. Paralel Çalıştırma
CI makinesi, birden fazla çekirdek kullanabiliyordu. Testlerin paralel çalıştırılması, bir sonraki adım olarak değerlendirildi. Geliştirici, bir hata nedeniyle ilk başta bu stratejinin işe yaramadığını düşünmüş olsa da, bu hata çözüldükten sonra 4 çekirdekli bir CI makinesinde bu yöntem oldukça etkili oldu.
4. Önbelleğin Eksik veya Yanlış Kullanımı
Geliştirici, projede önbelleğin var olduğunu düşünmüştü. Ancak, önbelleklerin yanlış anahtarlarla saklandığı ve her PR için ayrı bir önbellek kaydedildiği için bu strateji işe yaramıyordu. GitHub Actions’ın bir PR üzerinde kaydedilen önbelleklerin sadece o PR’a erişilebilir olması, bu durumu daha da kötüleştiriyordu. Geliştirici, bu hatayı fark edip, önbellek stratejisinin yeniden düzenlenmesiyle birlikte, bu süreçte de önemli bir zaman kazanımı sağladı.
Sonuç: 27 Dakikadan 4 Dakikaya
Bu optimizasyon süreci, geliştiriciye 27 dakikadan 4 dakikaya kadar inen bir CI süresi sunmuş oldu. Proje artık genel olarak 2-5 dakika aralığında bir süreyi hedefliyor.
Bu sonuç, geliştirici araçlarının (özellikle AI destekli araçlar) etkin kullanımıyla mümkün olabildi. Geliştirici, aynı zamanda, bu stratejileri kullanarak kendi reposunu optimize etmek için bir prompt oluşturmuş ve bu prompt’u diğer geliştiriciler için de paylaşıyor.
Sonuç: Geliştirme Hızının Artması
Bu başarı hikayesi, hem büyük hem de küçük projeler için geçerli bir ders sunuyor: Uzun CI süreleri, teknik bir sorun değil, bir strateji sorunudur. Geliştirici araçlarının doğru şekilde kullanılması, test stratejisinin optimize edilmesi ve her adımda ölçüm yaparak karar verilmesi, geliştirme döngüsünü hızlandırmanın en etkili yollarından biridir.
Dilerseniz, kendi proje CI sürenizi analiz edin ve geliştirme sürecinizi daha hızlı ve verimli hale getirmek için bu stratejileri uygulayın. Çünkü, 27 dakikadan 4 dakikaya inmek sadece bir sayı değil, bir dönüşüm.
