Zine.net online

Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc
w Szukaj

ZineCast

Zine-cast #3

Czas nagrania: 1h20m.
Tym razem rozmawiamy z Ziemowitem Skowrońskim o CI.
Poniżej zbiór linków do zasobów wspomnianych w czasie nagrania:

tree surgeon: http://hopka.pl/z7c2
nant: http://hopka.pl/z7c3
nantcontrib: http://hopka.pl/z7c4
Mike Roberts, How to setup a .NET Development Tree: http://hopka.pl/z7cb
nvelocity: http://hopka.pl/z7cd
subversion: http://hopka.pl/z7ce
Gemini Project Issue Tracking: http://hopka.pl/z7cf
Trac: http://hopka.pl/z7d0

CC.NET - http://hopka.pl/z7c5
MSBuild Wiki - http://hopka.pl/z7c6
MSBuild Community Tasks - http://hopka.pl/z7c7
All tasks - http://hopka.pl/z7c8
CI by M. Fowler - http://hopka.pl/z7c9
CI by Wiki - http://hopka.pl/z7ca
CI Factory by Jay Fowlers - http://hopka.pl/z7cc
VSTS - http://hopka.pl/z7d1
MS Build Sidekick - http://hopka.pl/z7d2
OnTime2007 - http://hopka.pl/z7d4
CI na wesolo - http://hopka.pl/z7d5
blog CI - http://hopka.pl/z7d6

Opublikowane 10 kwietnia 2007 14:59 przez zinecast
Filed under: ,

Attachment(s): http://zine.net.pl/ZineCasts/zinecast_3.mp3

Komentarze:

 

ris said:

Aż dziw bierze, że można pracować bez ciągłej integracji kodu.

kwietnia 10, 2007 21:54
 

bakuuu said:

Świetna sprawa. Zarówno sam pomysł tych "cast'ów" jak i pomysły tematów.

kwietnia 13, 2007 11:12
 

Tarciu said:

Pytanie odnośnie testów jednostkowych: wspomnieliście, że odbywają się automatycznie na serwerze, po wrzutkach kodu do repozytorium, i mogą trwać trochę czasu.

Czy w takim razie programiści nie odpalają testów na swoich lokalnych maszynach (bo zrobi to za nich serwer), czy też uruchamiają jakąś odchudzoną ich wersję?

kwietnia 13, 2007 21:43
 

nuwanda said:

Oczywiście programista odpala swoje testy lokalnie, natomiast serwer odpala wszystkie, żeby sprawdzić czy przypadkiem nie namieszaliśmy w czyimś kodzie (np. zmieniając klasę, której ktoś inny używa).

kwietnia 13, 2007 23:24
 

Ziemowit said:

Tarciu, nuwanda juz wlasciwie odpowiedzial na pytanie. Dodam tylko, ze programista przed commitem zmian powinien odpalic wszystkie testy, nie tylko swoje.

Dodatkowo czesto to co testy przepuszcza na maszynie developera zakonczyc sie moze bledem w niezaleznym srodowisku.

kwietnia 14, 2007 11:53
 

Tarciu said:

To ja proponuję temat na następną rozmowę - testy jednostkowe :)

Jeśli chodzi o mnie, to jestem w tym zupełnie zielony i chętnie posłucham rozmowy osób, które mają już z nimi doświadczenie.

Ciekawe, czy znajdzie się ktoś, kto brał udział w jakimś poważniejszym projekcie gdzie zastosowanoby prawdziwe TDD.

kwietnia 14, 2007 23:06
 

nuwanda said:

Ziemku, chciałem się odnieść do omawianej przez Ciebie opcji rozwiązywania bugów dopiero po przetestowaniu na serwerze integracji (40 minuta). Taki proces zakłada, że zgłoszenie buga będzie implikowało stworzenie co najmniej jednego przypadku testowego, który nie przechodzi, gdy bug jest i przechodzi, gdy zostanie on poprawiony. Moje pytanie: czy istnieją takie systemy śledzenia błędów, które pozwalają wiązać bugi z pewnym zbiorem testów?

Co do problemów z rozwiązywaniem bugów wraz z commitem to też napotkałem pewien problem (na co dzień pracuję z TFS). Otóż jeżeli częścią rozwiązania jest modyfikacja schematu bazy danych to nie zawsze jest możliwy natychmiastowy update schematu bazy dla całego projektu, w szczególności, gdy zajmuje się tym jedna osoba. Jeżeli zapomnimy o tym i wrzucimy źródła na serwer, bug zostanie rozwiązany a tester dostanie wiadomość, że kolejny build będzie zawierał tę poprawkę. Jeżeli weźmie ten build przed wprowadzeniem zmian w schemacie bazy danych, to może się okazać, że u niego ten bug nadal będzie się pojawiał. Z drugiej strony przetestowanie takiego scenariusza jest dość kłopotliwe, gdyż wymaga utworzenia nowej bazy danych, na której musiałyby działać testy jednostek…

kwietnia 17, 2007 23:12
 

arturstan said:

Podobało mi się, tylko jedno 'ale'

To co Ziemek powiedział po ok. 1h, powinno znaleźć się bliżej wstępu. Chodzi mi o to co zamiast CI, gdy projekt jest duży (myślałem, że się już nie doczekam).

nuwanda:

wydaje mi się, że tester nie powinien mieć możliwości uruchomienia programu na poprzedniej wersji bazy. I powinno się to rozwiązać programowo (stosuję automatyczną konwersję struktury bazy przy starcie programu)

maja 8, 2007 13:55
 

nuwanda said:

#arturstan: Testerzy nie mają starej wersji bazy. Gdy testują inny build to wykorzystują do testów bazę generowaną przez generator z builda, który testują. U mnie schemat bazy jest razem z kodem w repozytorium a generator baz kompiluje się razem z całym projektem. Zatem jeżeli osoba odpowiedzialna za update schematu nie zrobi update'u przed buildem to generator w nowym buildzie wygeneruje starą bazę. Więc siłą rzeczy tester będzie miał starą bazę.

maja 8, 2007 14:39
 

ziemowit said:

nuwanda:

Co do pytania, to osobiscie sie nie spotkalem z takim rozwiazaniem "pod klucz". Moze istnieja lecz nic o tym nie wiem. W kazdym razie nic nie stoi na przeszkodzie aby jakos to powiazac poprzez atrybuty, opis testu czy cos innego. Jest to metoda chalupnicza oczywiscie ale jak to mawiaja, z "braku laku dobry kit".

Co do TFS to sie pozwole niezgodzic z Twoim zdaniem, ale jest jeden warunek: uzywamy VS for Database Prof. do robienia zmian w bazie danych. Wtedy jak najbardziej jestesmy w stanie realizaowac wspomniana metodyke.

Ogolnie rzecz biorac, to developer nie powinien robic zmian w bazie. Jesli juz mowimy o tym jak to powinno byc w wiekszej organizacji. W malych oczywiscie, kazdy sam orze, sieje i kosi. W duzych organizacjach natomoast do zmian w bazie danych powinien byc osobny team i on uzywa stosownych narzedzi.

maja 9, 2007 01:10
Komentarze anonimowe wyłączone
W oparciu o Community Server (Personal Edition), Telligent Systems