Yazılım geliştirme süreçlerinde paralel çalışan kod ajanları giderek yaygınlaşıyor. Ancak, iki ajanın aynı temel commit'ten başlayıp farklı modüller üzerinde çalıştığı bir senaryoda, insan geliştiricinin araya girip yeni bir commit (B) itmesi durumunda ne olur? İşte tam bu noktada, yamaların hangi base commit'e dayandığını bilmemesi büyük bir güvenlik açığına yol açabilir. MonkeyCode SaaS üzerinde yapılan bu kara kutu deneyi, paralel görevlerin sadece hız değil, aynı zamanda tutarlılık sorunu olduğunu gözler önüne seriyor.
Deneyin temelinde dört değişmez kural (invariant) yatıyor: Her sonuç değişmez bir A commit'iyle ilişkilendirilir; X ajanı Y'nin oluşturduğu geçici dosyaları göremez; her görev yalnızca kendine izin verilen kapsamda değişiklik yapar; dal kayması (branch drift) asla temel commit'i sessizce değiştirmez. Bu kurallar, paralel çalışmanın güvenliğini sağlamak için kritik öneme sahip. Deneyde kullanılan tek kullanımlık depo, src/auth.py, tests/test_auth.py, src/logging.py, tests/test_logging.py ve iki sentinel dosyası içeriyor. Her iki test de A commit'inde bağımsız olarak başarısız olacak şekilde ayarlanıyor.
Görevler başlatılırken, X yalnızca auth dosyalarını, Y ise yalnızca logging dosyalarını düzenleyebiliyor. Her ikisinin de sentinel dosyalarını değiştirmesi yasaklanıyor. Kayıt gereksinimlerinin hash'leri ve tam base SHA'sı alınıyor. Görevler mümkün olduğunca eşzamanlı başlatılıyor ve çalışırken, ilgisiz bir dokümantasyon commit'i (B) itiliyor. Ardından her görev için task_id, requested_base, reported_or_inferred_base, changed_files, test_command, test_result, result_revision ve drift_action gibi alanlar kaydediliyor. Burada 'unknown' değeri dürüst bir gözlem olarak kabul ediliyor ancak benimseme aşamasında sorun yaratabilir.
Sistem Güvenliği
İzolasyon testi, X ve Y'nin ayrı ayrı temiz A checkout'larında çalıştırılmasını içeriyor. İzin verilen dosyalar, odaklanmış test, ilgisiz fikstür ve sentineller kontrol ediliyor. Ardından A + X + Y ve A + Y + X sıralamaları test ediliyor. Her iki sıralamada da testler çalıştırılıyor. Eğer yalnızca bir sıralama çalışıyorsa, görevler arasında temsil edilmesi ve incelenmesi gereken bir bağımlılık var demektir. Daha sonra B + X + Y senaryosu test ediliyor. Temiz bir uygulama, açık çatışma veya B'den yeniden çalıştırma isteği makul sonuçlar olabilir. Ancak sessiz base değişikliği kabul edilemez.
Son olarak, aynı satırı kasıtlı olarak düzenleyen iki görev oluşturuluyor. Burada gerekli özellik, görünür çatışma ve yeniden çalıştırma kanıtıdır; sihirli otomatik birleştirme değil. Deneyin gözlem kararları şöyle: Base net, yamalar izole ve her iki sıralama da geçiyorsa aday; çatışma açıkça belirtiliyorsa ve insan birleştirme kapısı varsa aday; base bilinmiyorsa yetersiz kanıt; görevler arası dosyalar görünüyorsa çalıştırmayı reddet; kayma base'i sessizce değiştiriyorsa çalıştırmayı reddet; birleştirilmiş yama yeniden çalıştırma kanıtı içermiyorsa birleştirmeyi engelle.
Sonuç ve Değerlendirme
MonkeyCode'un README belgesi, yönetilen çevrimiçi ortamlar, görev ve gereksinim yönetimini belgeliyor ve bu deney için pratik bir aday haline getiriyor. Ancak yukarıdaki zarf (envelope) veya semantiği vaat etmiyor. Kaynak: MonkeyCode deposu ve SaaS. Sınırlamalar: İki görev bir yük testi değildir ve süreç veya kiracı düzeyinde izolasyonu kanıtlayamaz. Açıklama: Yazar bir MonkeyCode kullanıcısıdır ve projeyle bağlantılı değildir; bu makale bağımsız bir onay değil, aynı operatör tarafından yönetilen hesaplar tarafından yayınlanan teknik makalelerden biridir.
Kaynak: dev.to
