[Gelistirici] [RFC] Test Süreçleri

[Ekin Meroğlu]

Merhaba;

Çarşamba 22 Ekim 2008 tarihinde, Doruk Fisek şunları yazmıştı: 
> Wed, 22 Oct 2008 11:57:41 +0300, Ekin Meroğlu <ekin at pardus.org.tr> :
> > edelim, birikince birlikte alırız kararlı depoya demek istiyorsan, o
> > zaman da 15 gün önceki depo ile test edilmiş x paketini, depoya n
> > tane paket daha girdikten sonra test edilmiş ve OK'lenmiş say(a)
> > mayacağımı peşinen söyleyeyim.  
>
> Kafama takilan bir soru var.

Öncelikle, test sisteminin bu halinden son derece rahatsızım, ama daha iyisi 
nasıl olur hakkında fazla fikrim yok - aklımdakilerin çoğu en az bu hali 
kadar kötü, en çok bu hali kadar da iyi.

Şimdi : yukarıda alıntıladığın paragraftan önceki paragrafa "bu testleri depo 
bütünlüğünü de test etmek için yapıyoruz" mealinde bir giriş yapmıştım, 
kesince tekil paket testleri için söylüyor gibi olmuşum..
 
> Bu mantik kullanici illa tum sistemini guncellemeli demeye getiriyor.
> Kullanici aradan paket secip guncellerse, ya da bir paket kurmaya
> kalktigi icin sadece system.base guncellenirse sistemi patlayabilir
> anlamina geliyor.
>
> Diger yandan da dusun ki, kararli depoya x paketi girdi bir guncelleme
> serisi ile. Daha sonraki guncelleme serisi ile girenler x paketini
> bozmus olabilir diye x paketinin testini yok mu sayacagiz?
> Saymayacaksak, tekil paket guncellemelerinde niye yok sayiyorsun?

Hayır, o paketin kendi içinde sorunsuz olabileceğini - hatta olduğunu kabul 
ediyorum, ama o güncellemelerden bir gün önce sistemi güncel olan bir 
kullanıcının paket yöneticisinden "getir şu güncellemeleri" dediğinde de bu 
işlemi sorunsuz yapabiliyor olduğundan da emin olmalıyız diyorum : 2007'de 
yaşadık, tek başlarına sorunsuz olan bir sürü paket bir araya gelince 
güncellemelerin sonuçlandırılamadığı bir depo oluşturdu (detayını sorma, 
hatırlamıyorum :-()

> Sayacaksak, oyleyse depoya her guncelleme girmeden once tum deponun
> bastan asagi test edilmesi mi gerekiyor sence?

Deponun herhangi bir anında depo bütünlüğünün en azından
 
- (revdep rebuild gibi otomatik bir araçla) güncellemelerdeki eksik kitaplık 
sorunları,
- temiz bir en son sürüm kurulumunun deponun o anki haline güncellenmesinin 
mümkün olup olmadığı,
- deponun bir önceki halinden bu haline sorunsuz güncellemenin mümkün olup 
olmadığı

açılarından sorunsuz olduğundan emin olmak gerekiyor demek istiyorum. Tabii ki 
bu senaryolar olası durumların çok küçük bir bölümünü kapsıyor, ama en sık 
karşılaştığımız sorunları test etmek için işimize yarıyor.  
Tüm paket testlerini deponun belli bir state'i ile yapmak ek olarak paketlerin 
birbirlerini bozma ihtimallerini de test etmemizi sağlıyor, ama bahsettiğim 
bu değildi.

> Bastan beri soyledigim gibi, test sureci ile kurunun yaninda cok fazla
> yas yakmaya calisiliyor gibime geliyor. Sorun cikarip ortaligin
> karismasina yol acan belli paketler var. Onlari belirleyip, onlarin
> guncellenmesinde testlere ekstra ilgi gosterip, kalanlara sadece temel
> testleri (paket menuye yerlesiyor mu, aciliyor mu) uygulamak daha
> fizibl olur.

Kişisel fikrim böyle bir listenin kolay maintain edilemeyeceği yönünde, ama 
yapılmaz da değil. 

> Daha da fizibl oldugunu dusundugum soyle bir radikal onerim var :
>
> 1) Sadece guvenlik guncellemelerinin yapildigi bir 2008 deposu olsun.
> Bu depoya giren her guncellemede tirnagina kadar tum yazilimlar testten
> gecsin. Bu depoya "kararli" olacak densin. Bir paket patlarsa test
> takimini dovelim :)

Burada karşımıza yine işgücü sorunu geliyor - herhangi bir yazılım bir 
güvenlik güncellemesini / kritik hata düzeltmesini yeni (ve bizim dağıtım ile 
uyumsuz, ya da en iyi ihtimalle depoda test edilmesi gerekecek kadar fazla 
değişiklik gerektiren) bir sürüm ile yayınladığında karşımıza çıkan 
seçenekler belli : 

- güvenlik güncellemesi depo / bağımlılık ağacında değişiklik gerektirmeyecek 
şekilde eski sürüme backport edilir,
- Güvenlik güncellemesini mutlaka almalıyız denilip o paket ve arkasında 
taşıyabileceği tüm güncellemeler depoya alınır, "kararlılık yerine güvenlik" 
denir, olası regressionlar sineye çekilir.

Şimdiye kadar backport için işgücümüz yeterli gelmediği durumlarda (burayı 
genellikle diye okuyun) ikinci seçeneği seçtik - yani gelişmelerden geri 
kalmayayım kararı çoğu zaman da güvenlik güncellemelerinin zorlaması ile 
alındı. Temel sorunum yukarıda bahsettiğin kararlı depoya backport 
_edemediğimiz_ bir güncelleme almak durumunda kaldığımızda ne yapacağımız. 
Bugüne kadar üçüncü seçenek olan "kararlı kalalım, ne yapalım güvenli 
değilse" kimsenin içine sinmediğinden pek seçilmedi, ama yukarıdaki gibi çok 
daha sıkı bir kararlı depo yapısına geçersek, "ya backport ya güvensiz paket" 
durumunda kalacağız. 
  
> 2) Normal depoda test sureci islemesin ya da sadece kritik paketlerde
> islesin. x hafta test deposunda durup hata raporu almayan paketler
> normal depoya sorgusuz sualsiz girsin. Kullanicilar "sistemim bozuldu,
> guncellemeler test edilmiyor mu" dediginde de, "test deposunda x hafta
> hata belirtilmemis. eger surecin daha iyi olmasini istiyorsaniz, siz de
> testlere daha cok katilin. Ben sistemim kararli kalsin istiyorum
> diyorsaniz, sadece guvenlik guncellemeleri yapilan depoyu kullanin."
> densin.

Buna hiçbir itirazım yok, sadece sürecin - paketlerin depoda kalış süresi, 
bildirilmiş hatalarının takibi, vs - iyi tanımlanıp son derece düzenli takip 
edilmesi gerekiyor.

> Boylece hedef belirlenmis olur, dagitim depolarinin bir kimligi olur.
> Su anda bence herkes farkli beklentiler icinde dagitimdan ve kimse
> mutlu olamiyor. Hem ultra kararli olayim, hem gelismelerden geri
> kalmayayim, hem o da olsun, hem bu da olsun diye hareket edince hicbiri
> elde edilemiyor.

Haklısın, ama yukarıda da söylediğim gibi karar verilmesi gereken durumların 
yarısında biz "aman eskimeyelim" diyorsak, yarısında da hata düzeltme ve 
güvenlik güncellemelerini backport edecek geliştirici olmaması nedeniyle 
oyumuzu güvenlik ve hata düzeltmesinden yana kullanıyoruz. 

--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>

... did i listen to pop music because i was miserable, or was i miserable
because i listened to pop music?... - rob [nick hornby / hi fi]