Buildery dla AC - przem

[Paweł Gołaszewski]

On Wed, 26 Mar 2003, Tomasz Kłoczko wrote:
> > tak sobie mysle - gdyby puszczenie zlecenia polegalo na wstawieniu do
> > jakiejs tabeli rekordu ze jest to i to do zbudowania, a buildery by
> > sie co jakistam okreslony czas laczyly i sprawdzaly czy nie pojawilo
> > sie cos do zbudowania, a jesli tak, to by budowaly, po poprawnym
> > zbudowaniu lub bledzie wysylalyby raport, ktory po przeparsowaniu
> > modyfikowalby status tego konkretnego zlecenia...
> Skoro już "tak sobie myslisz" to pomyśl nad tym jak to miałby mieć niby
> pzrewagę nad dostarczaniem zleceń w obecnej formie (?). W jaki sposób
> załatwisz np. w tej samej kolejce budowanei z różnych etykiet ? Ja wiem
> że baza dany to ładna rzeczale nie do wszytkiego się dobrze to nadaje ..

Akurat do tego jest bardzo piękną rzeczą.
Zauważ, ze bardzo łatwo będzie można dzięki trzymaniu zleceńw bazie zrobić 
ładne miedzymordzie, którym każdy developer będzie śledził sobie co się z 
jego zleceniem dzieje - w jakim jest stadium.. Będzie też mógł tam wcisnąć 
przycisk STBR. Osoby mające uprawnienia do builderów dostają powiadomienie 
i w tym momencie posyłają albo nie. Jeżeli nie człowiek ma możliwość 
dostać odpowiedź dlaczego (ze standardowymi formułkami zdefiniowanymi). 
KAżde zlecenie ma status (typu: oczekuje w test, w updates, etc, etc).

Nie wiem czy zauważasz, ale właśnie wysyłanie na buildery i późniejsza 
obsługa zleceń to aktualnie najwięszy problem organizacynjny. Bez 
trzymania zleceńw SQL-u ciężko taki interfejs będzie sprawnie sprzęgnąć z 
rzeczywistymi builderami oraz cvs-em.
Wysyłanie z różnych etykiet można dosyć łatwo rozwiązać przy odpowiedniej 
konstrukcji tabel. Ba - da się nawet zrobić puszcvzanie warunkowe (jeżeli 
przyszło potwierdzenie o poprawnym zbudowaniu).

Także to jest naprawdę dobry pomysł...

-- 
---------------------------------
pozdr.  Paweł Gołaszewski        
---------------------------------
CPU not found - software emulation...