Lore Hafta 2: Kontrollerimiz neden saniyeler içinde durdu, doğru bir build neden bir dosyayı kaçırır, bir bot ne zaman merge edebilir

Lab, haftalık yazı. 19 Ekim Pazartesi ile 25 Ekim Pazar arası, 2026, İstanbul saatiyle. Merge edilen pull request'leri Pazar günü 25 Ekim'de saat 21:00'de saydık, bu yüzden Pazar akşamının son saatleri sayıma girmedi.

Bu hafta 39 pull request merge ettik. Pull request, kodumuzda bir değişiklik yapmak için açılan bir öneridir. Bizde bunu çoğunlukla bir kodlama agent'ı açar, değişiklik ana sürüme girmeden önce de kontrolden geçer. Tipik bir pull request, açıldıktan yaklaşık 30 dakika sonra merge edildi. Emeğin çoğu henüz duyurmadığımız yeni bir ürüne gitti (25 merge). Onu AutoReal (6), bir iç depomuz (6) ve lorelabs.co (2) izledi.

Bu hafta pek aklımıza gelmeyen bir şey de tükendi: otomatik kontrollerimizin dakikaları. 242 kontrol çalışmasının 21'i başarısız oldu ve bunların 17'si aslında test hatası bile değildi. Hesabımız aylık hakkını bitirdiği için bu çalışmalar tek bir adım atmadan, 3 ile 7 saniye içinde durdu.

Haftanın bize netleştirdiği üç fikri anlatmak istiyoruz:

1. CI dakika bütçesi. Ne olduğunu, nasıl sayıldığını ve neredeyse hiçbir şey yapmayan bir işin neden yine de tam bir dakikaya mal olduğunu anlatıyoruz.

2. Kod doğruyken bile yayındaki paket neden bir dosyayı kaçırır. Bir build yalnızca kullanıldığını gördüğü dosyaları kopyalar. Başka bir yolla yüklenen dosya geride kalabilir.

3. Düşük riskli bot merge kuralı. Bir botun başka bir botun yazdığı değişikliği ne zaman merge edebileceğini ve bunu neyin güvenli tuttuğunu konuşuyoruz.

Fikir nedir. CI, yani continuous integration, önerilen her değişiklikte çalışan otomatik kontrollerin bütünüdür. Bu kontroller kodu okur, testleri çalıştırır ve uygulamanın build'ini alır. GitHub'da bu işler kiralık makinelerde çalışır ve özel depolar için her hesabın aylık bir makine dakikası hakkı vardır. GitHub'ın faturalama sayfasına göre ücretsiz planda ayda 2.000, Pro ve Team planlarında 3.000 dakika var. Dakikalar, çalışmayı kimin başlattığına değil, deponun sahibine yazılır.

Neden önemli. Hak bittiğinde ve bir ödeme yöntemi tanımlı değilse ya da bir harcama bütçesine ulaşıldıysa, GitHub yeni işleri başlatmayı bırakır. Kontroller kod yanlış olduğu için değil, reddedildikleri için başarısız olur. "Bütçe yok" anlamına gelen kırmızı çarpı, siz açıp bakana kadar "kod bozuk" diyen çarpıdan farksız görünür.

Sade bir dille nasıl işler. Açılış ücreti olan bir taksi düşünün. GitHub'ın fiyat sayfası, her işin kullandığı dakikaları ve dakika kesirlerini bir üst tam dakikaya yuvarladığını söylüyor. Yani başlayan, "yapacak bir şey yok" yazan ve 10 saniyede kapanan bir iş tam bir dakika tutar. On küçük iş, toplamda iki dakikalık iş bile yapmasalar on dakika tutar. Başlamadan önce bir koşulla atlanan iş ise hiç makine kullanmaz ve GitHub onu "Success" olarak gösterir. En ucuz kontrol, bakacak bir şeyi yokken hiç başlatılmayan kontroldür.

Bize ne oldu. 24 ve 25 Ekim'de hesabımızın dakikaları bitti ve haftadaki 21 başarısız çalışmanın 17'si, tek adım atmadan 3 ile 7 saniye içinde sona erdi. Bu, iki hafta içinde ikinci kez oluyor. İlki 12 Ekim'deydi. Pull request'lerimizden biri şaşırtıcı noktayı açıkça yazdı: yalnızca bir atlama satırı yazan işler bile tam bir dakika faturalandı.

Çözüm katman katman geldi. Önce AutoReal'deki ağır testleri yalnızca test ettikleri dosyalar değiştiğinde çalışır hale getirdik ve yavaş render testlerini yan yana çalışan dört parçaya böldük. Ana kontrol çalışmasının ortanca süresi yaklaşık 6, en yavaşı 12 dakikaydı. Değişiklikten sonraki en hızlı gerçek çalışma yaklaşık 4 dakika sürdü (duvar saati süresi, faturalanan dakika değil). Ardından depolarımızın çoğunda aynı kalıbı izleyen değişiklikler açtık. Bu değişiklikler taslakları atlıyor ve yola göre filtreliyor. Birkaç küçük iş yerine kontrol başına tek iş kullanıyor ve aynı pull request'teki yeni bir push'un eski kontrolü iptal etmesine izin veriyor. CI kullanımı için bir şirket kuralı da yazıldı ve onay bekliyor. Çok daha büyük bir plan yerine küçük bir plan yükseltmesiyle verimliliği birlikte seçtik.

Başkaları ne diyor. GitHub'ın kendi sayfaları kuralları veriyor: iş başına tam dakikaya yuvarlama, atlanan işin başarılı sayılması ve bir concurrency ayarının aynı gruptaki çalışan bir işi iptal edebilmesi. Bağımsız yazarlar maliyet tarafını daha açık söylüyor: 20'şer saniyelik on iş, 200 saniyelik gerçek iş için 10 dakika faturalanır. Çalışma kayıtları gerçek süreleri, fatura ise yuvarlanmış süreleri gösterir.

Biz nerede duruyoruz. Yuvarlamanın en çok cezalandırdığı kalıbı, yani çok sayıda küçük işi kurmuştuk. Duvar saati sürelerini de fatura gibi okuyorduk, oysa ikisi aynı şey değil. Düzeltmenin büyük kısmı hâlâ merge bekliyor, bu yüzden bir ayda ne kadar tasarruf sağlayacağını henüz söyleyemiyoruz.

Fikir nedir. Bir web uygulamasını yayına alırken proje klasörünün tamamını göndermeyiz. Build aracı, uygulamanın çalışırken ihtiyaç duyduğu dosyalardan oluşan daha küçük bir paket hazırlar. Next.js'in "standalone" modu, tam olarak bu dosyaları sunucunun çalıştırdığı tek bir klasöre kopyalar.

Neden önemli. Kullanıcıların dokunduğu şey bu pakettir. Paket bir dosyayı kaçırırsa, kodun her satırı doğru olsa ve projenin tamamında her test geçse bile uygulama canlıda bozulur. Testler genellikle dosyanın hâlâ yerinde durduğu klasörün tamamında çalışır.

Sade bir dille nasıl işler. Bavulu bir listeye bakarak hazırlamak, ancak liste eksiksizse işe yarar. Next.js bu listeyi kodu okuyarak çıkarır: import'ları ve dosya okumalarını arar ve izler. Belgeleri, bazı durumlarda gerekli dosyaları dahil etmeyi başaramayabileceğini açıkça söylüyor ve dosyaları elle eklemek için bir ayar sunuyor. Yolu uygulama çalışırken kurulan bir dosya, bu okumada görünmez kalabilir.

Bize ne oldu. AutoReal'de bir gönderiyi onaylamak, canlıda başarısız bir taslak kaydetti. Nedeni şuydu: barındırma tarafının sunduğu paket bir kütüphanenin ana dosyasını kopyalamış, ama kütüphanenin çalışma anında kurduğu bir yolla yüklediği küçük bir ayar dosyasını dışarıda bırakmıştı. Daha basit bir yedek yöntem devreye giremeden hata oluştu, çünkü yedek yol yalnızca belirli bir hata türünü yakalıyordu. Düzeltme eksik dosyaları pakete elle ekliyor, bu durumu yedek yola bırakıyor ve doğrudan sunulan paketin üzerinde çalışan otomatik bir kontrol ekliyor. Düzeltme 24 Ekim'de saat 23:22'de merge edildi.

Başkaları ne diyor. Next.js hem dosya izlemeyi hem de sınırlarını belgeliyor. Geçen hafta DORA'nın, CI build'inin ürettiği paketin sonraki adımlarda kullanılan paket olması gerektiği tavsiyesini aktarmıştık. Bu olay, o tavsiyenin sahadaki karşılığı oldu.

Biz nerede duruyoruz. Bu düzeltmeden önce kontrollerimiz uygulamanın build'ini alıyor ama sunulan paketi test etmiyordu. Artık bir kontrol bunu yapıyor, ancak dakika tasarrufu için yalnızca paketi etkileyen dosyalar değiştiğinde çalışıyor. Bu makul bir takas, ama izlenmeyen bir yerdeki yeni bir çalışma dosyası yine gözden kaçabilir.

Fikir nedir. Merge, bir değişikliğin ana sürüme katıldığı andır. Bu haftaya kadar yalnızca kurucumuz merge ediyordu. Düşük riskli merge kuralı, dokümanlar ya da araç ayarları gibi bazı küçük değişiklikleri, onları yazan bot olmadığı sürece bir botun merge etmesine izin veriyor.

Neden önemli. Her doküman düzeltmesinin tek bir kişinin merge etmesini beklemesi her şeyi yavaşlatır ve bu düzeltmelerin çoğu kullanıcılar için hiçbir risk taşımaz. Ama "düşük risk" bir his değil, yazılı bir test olmalı. Yoksa zamanla önemli işleri de kapsayacak kadar büyür.

Sade bir dille nasıl işler. Bunu, kontrol listesi eklenmiş dört göz ilkesi gibi düşünebilirsiniz. Kuralımız bir bot merge'üne ancak altı koşulun hepsi sağlanınca izin veriyor.

1. Bir inceleme botu merge edilecek sürümün tam kendisini onaylamış olmalı.
2. Tüm zorunlu kontroller yeşil olmalı.
3. Değişiklik yalnızca dokümanlara, planlara, kayıtlara ya da araç ayarlarına dokunmalı.
4. İçinde deploy, para, fiyatlandırma, hukuki metin, giriş, gizli anahtarlar, CI ya da kullanıcıya görünen hiçbir şey bulunmamalı.
5. Yazan ile merge eden aynı olmamalı.
6. İnceleme botu bir merge sırası belirttiyse ona uyulmalı.

Ürün kodu, tasarım ve sürümler hâlâ kurucunun onayından geçiyor ve kurucu kuralı istediği an geri alabiliyor. Merge'ün kendisi bir deploy başlatıyorsa hiçbir bot merge etmiyor.

Başkaları ne diyor. DORA'nın 2019 State of DevOps raporuna dayanan araştırması, değişiklik onayının en iyi uzaktaki bir kurulla işlemediğini söylüyor. Ona göre en iyi yol, geliştirme sırasında yapılan akran incelemesi ve kötü değişiklikleri erkenden yakalayan otomasyondur. GitHub'ın korumalı branch ayarları da son push'un, onu yapan kişiden başka biri tarafından onaylanmasını şart koşabiliyor. Bu, beşinci koşulumuzla aynı fikir.

Biz nerede duruyoruz. Kuralımız ikisiyle de örtüşüyor: değişikliği yazmamış bir tarafın incelemesi, otomatik kontroller ve dar, yazılı bir kapsam. Kayıtlarda bir ayrıntı aksadı. Kural 22 Ekim'de merge edildiğinde yürürlüğe girdi, ama kaydı iki gün daha "karar bekliyor" yazmaya devam etti. Bu hafta kurala dayanarak herhangi bir botun merge edip etmediğini kontrol etmedik.