[Gelistirici] Test surecleri

[Serbulent UNSAL]

On Sunday 05 October 2008 10:46:23 Doruk Fisek wrote:
> Sun, 5 Oct 2008 06:58:40 +0300, Erkan Tekman <tekman at pardus.org.tr> :
> > Burada da şu konuları konuşmak yerinde olacaktır sanırım:
> > * Güncel olmak/kalmak ile kararlı olmak/kalmak arasında seçimi hep
> > ilkinden yana yapıyoruz. Bu durum gözden geçirilmeli mi?
> > * Test süreçleri sürekli olarak yavaşlatıcı bir etken olarak
> > görülüyor. Böyle olması kötü mü? Ve/veya daha hızlı olması mümkün mü?
>
> Bu sorularin kendime gore yanitlarini daha once test sureci ile ilgili
> thread'lere birden fazla kere yazdim, yine usenmedigim kadarini
> hatirlatayim.
>
> Test sureci ile ilgili ciddi birkac problem var :
>
> 1) Test sureci duzenli islemiyor. Guncellenen bir paketin ne kadar
> surecek bir surecte "test edilecek" diye askida kalacagi, testin ne
> kadar zamanda tamamlanacagi -- hatta teste ne zaman baslanacagi bile
> belli degil.
>
> 2) Gercekten test edilmesi gereken kritik paketler "guvenlik
> guncellemesi" diye test edilmeden depoya giriyor.
>
> 3) Aslinda kirilmasi pek mumkun olmayan, bagimliligi az olan, basit
> uygulamalar "test edilmeden aslaa olmaaaaz" diye depoya cok gec giriyor.
>
> Isin kotusu, her kritik paketi hizli depoya almaktan dolayi problem
> ciktiginda "daha yavas guncellenmemiz lazim" diye test surecleri
> iyice yavaslatiliyor, kabak problem cikmayan paketlerin basina
> patliyor. Kritik paketler yine jet hiziyla depoya giriyor.
>
> Yani bir Firefox guncellemesini test etmeden depoya aldik diye, bir
> oyunun yeni surumu ciktigi gun Pardus'ta guncellenmesine karsin 1-1.5
> ay sonra kullanicilara ulasabiliyor.
>
> Cozum ne?
>
> 1) Test surecinin "ciddi" yapilmasi. Ornegin her hafta Pazartesi gunu
> test surecinin yeni gelen paketler icin tekrar baslanmasi gerekiyor.
> Boyle bir insan gucumuz yok deniyorsa -- bunun adi konur, sadece belli
> kritik paketlere test sureci uygulanabilir, kalanlar test edilmeden
> depoya alinabilir.
>
> Test edilmeden Pardus deposuna hic paket giremez deniyorsa,
> insangucunun yetmedigi kalan paketler contrib deposuna alinmali. En
> azindan adam gibi guncellenirler.
>
> Ama bunun adi mutlaka konmali. Su anda "ne guzel de test yapiyoruz" diye
> dusunenler kendilerini kandiriyorlar bence.
>
> 2) Bir "acil test ekibi"nin olmasi gerekiyor. Yani bir guvenlik
> guncellemesi varsa, onu atiyorum 12 saat icinde test edip "tamam, bu
> saglam" diyecek birileri olmali. Yanlis anlamayacaginizi umarak
> soyluyorum, cekirdek ekipte az sayida insan yok, mesailerinin bir
> kismini buna ayirmalari cok zor olmamali.
>
>
> Bir de su anda cok kullanilan uygulamalar kirilmis durumda, 24 saat
> gecmesine karsin hala cozum icin bisi yapilmamis durumda. Bu bir tek
> bana mi batiyor bilmiyorum. Tatil gunu diyeceksiniz, dogru, o zaman
> tatil gununde kritik guncelleme depoya almayalim :/
>
>                    Doruk 
>

Bütün bu söylediklerinin ışığında sadece test süreçlerini değil , kararlı 
depoya paket alma sürecimizi de baştan tasarlasak diyorum.

Önerim şu; Test deposundaki paketinin yeterli kararlılığa ulaştığını düşünen 
geliştirici listeye ( sanırım en uygunu geliştirici listesi ) mail atar ve 
test isteğinde bulunur. Test sorumlusu bu isteği yakalar ve paket ile ilgili 
test sürecini işletir[1]. Test sürecinin sonunda ortaya çıkan sonucu listeye 
gönderir.

Test için gereken max. süreler gruplanır ve test isteği ile beraber listeye 
gönderilir. Örneğin 1. önceliğe sahip paketler 24 saat içinde, 2. önceliğe 
sahip paketler 48 saat içinde , 3. önceliğe sahip paketler 72 saat içinde 
test sürecinden geçmelidir gibi.

[1]  Test süreci; En son kararlı depoyu içeren sisteme kurulum, sistemdeki 
ters bağımlılıkların kontrolü ve pakete uygulanacak işlev testlerini içerir.


-- 
İyi Çalışmalar;
 
Serbülent