@ahmeteraslan · 7 gün önce
Her commit sonrası 40 dakika test bekliyorduk: CI süresini 11 dakikaya indirmek için yaptığımız 6 değişiklik
Yurt dışındaki bir müşterinin web uygulamasında üç kişilik uzaktan bir ekiple çalışıyorum. Yaz sonunda fark ettik ki sürekli entegrasyon hattımız her commit sonrası ortalama 40 dakika sürüyordu. Bir düzeltme gönderiyorsun, kahve yapıyorsun, başka bir işe geçiyorsun, sonra test kırmızı dönüyor ve az önce ne yaptığını hatırlamaya çalışıyorsun. Saat farkı da işin içine girince bir pull request'in birleşmesi bazen iki güne yayılıyordu. Ekim ayını bu süreyi düşürmeye ayırdık ve şu an ortalama 11 dakikadayız. Neler yaptığımızı sırayla yazayım.
İlk iş ölçmek oldu. Hattın hangi adımının ne kadar sürdüğünü bir tabloya döktük. Tahminimiz testlerin yavaş olduğuydu, ama sürenin neredeyse üçte biri bağımlılıkları her seferinde sıfırdan indirmek ve konteyner imajını yeniden oluşturmakla geçiyordu. Ölçmeden başlasaydık yanlış yerde vakit kaybedecektik.
Yaptığımız değişiklikler:
1. Bağımlılık önbelleği. Kilit dosyası değişmediği sürece paketler önbellekten geliyor. Tek başına sekiz dakika kazandırdı.
2. Konteyner imajında katman sırasını düzelttik. Sık değişen uygulama kodunu en sona aldık, bağımlılık katmanı artık çoğu commit'te yeniden oluşturulmuyor.
3. Testleri dört paralel işe böldük. Bölmeyi dosya sayısına göre değil, önceki çalışmalardaki test sürelerine göre yapıyoruz, yoksa bir iş hep geç bitiyordu.
4. Veritabanı kullanan testlerde her test için şemayı sıfırdan kurmak yerine her testi bir işlem içinde çalıştırıp sonunda geri alıyoruz.
5. Uçtan uca tarayıcı testlerini her commit'te değil, ana dala birleşmeden önce ve gece bir kez çalıştırıyoruz. Bu tartışmalı bir karardı, aşağıda anlatıyorum.
6. Ara sıra kendiliğinden kırılan, kararsız testleri ayrı bir listeye aldık. Her birinin sahibi var ve iki hafta içinde ya düzeltiliyor ya siliniyor.
Beşinci madde ekipte en çok tartışılanı oldu. Uçtan uca testleri her commit'ten çıkarınca bir hatanın ana dala girmeden önce yakalanma süresi uzadı. Bunu dengelemek için pull request birleşmeden önce bu testlerin yeşil olmasını zorunlu tuttuk. Yani hızlı geri bildirim geliştirme sırasında, tam kontrol birleşmeden önce.
Altıncı madde ise beklemediğimiz kadar etkili çıktı. Kararsız testler yüzünden insanlar kırmızı sonucu görünce tekrar çalıştır butonuna basmaya alışmıştı. Hem süre kaybı, hem de gerçek bir hatanın tekrar çalıştırmayla gözden kaçması. Liste kısaldıkça kırmızıya güven geri geldi.
Sizin ekiplerde CI süresi ne kadar ve hangi noktadan sonra çok uzun diyorsunuz? Bizde on dakika civarı, birinin başka işe geçmeden beklediği sınır gibi görünüyor.
İlk iş ölçmek oldu. Hattın hangi adımının ne kadar sürdüğünü bir tabloya döktük. Tahminimiz testlerin yavaş olduğuydu, ama sürenin neredeyse üçte biri bağımlılıkları her seferinde sıfırdan indirmek ve konteyner imajını yeniden oluşturmakla geçiyordu. Ölçmeden başlasaydık yanlış yerde vakit kaybedecektik.
Yaptığımız değişiklikler:
1. Bağımlılık önbelleği. Kilit dosyası değişmediği sürece paketler önbellekten geliyor. Tek başına sekiz dakika kazandırdı.
2. Konteyner imajında katman sırasını düzelttik. Sık değişen uygulama kodunu en sona aldık, bağımlılık katmanı artık çoğu commit'te yeniden oluşturulmuyor.
3. Testleri dört paralel işe böldük. Bölmeyi dosya sayısına göre değil, önceki çalışmalardaki test sürelerine göre yapıyoruz, yoksa bir iş hep geç bitiyordu.
4. Veritabanı kullanan testlerde her test için şemayı sıfırdan kurmak yerine her testi bir işlem içinde çalıştırıp sonunda geri alıyoruz.
5. Uçtan uca tarayıcı testlerini her commit'te değil, ana dala birleşmeden önce ve gece bir kez çalıştırıyoruz. Bu tartışmalı bir karardı, aşağıda anlatıyorum.
6. Ara sıra kendiliğinden kırılan, kararsız testleri ayrı bir listeye aldık. Her birinin sahibi var ve iki hafta içinde ya düzeltiliyor ya siliniyor.
Beşinci madde ekipte en çok tartışılanı oldu. Uçtan uca testleri her commit'ten çıkarınca bir hatanın ana dala girmeden önce yakalanma süresi uzadı. Bunu dengelemek için pull request birleşmeden önce bu testlerin yeşil olmasını zorunlu tuttuk. Yani hızlı geri bildirim geliştirme sırasında, tam kontrol birleşmeden önce.
Altıncı madde ise beklemediğimiz kadar etkili çıktı. Kararsız testler yüzünden insanlar kırmızı sonucu görünce tekrar çalıştır butonuna basmaya alışmıştı. Hem süre kaybı, hem de gerçek bir hatanın tekrar çalıştırmayla gözden kaçması. Liste kısaldıkça kırmızıya güven geri geldi.
Sizin ekiplerde CI süresi ne kadar ve hangi noktadan sonra çok uzun diyorsunuz? Bizde on dakika civarı, birinin başka işe geçmeden beklediği sınır gibi görünüyor.
7 3 yorum
