Jak działają narzędzia typu Jenkins lub TeamCity?

Hej,

jestem dosyć początkujący w Java'ie, lecz natknąłem się na coś co się zwie Teamcity. Potem natknąłem się na Jenkins, ale nadal nie rozumiem po co te aplikacje są. Otóż wyczytałem, że służą do komilacji i do testów automatycznych. Problem jest jednak taki, że jak chciałbym coś sobie wybudować np. z pomocą Gradle'a na Android'a to zrobię to o wiele szybciej na swoim kompie w 40 sekund i obejdzie się przez wrzucania plików na Git'a i planowania nowego Task'a w Jenkins'ie... No więc, pytam się, doświadczonych programistów po co są te narzędzia i czy serio ich używacie?

Jak sama nazwa wskazuje (Teamcity) jest to narzędzie dla zespołów, a nie dla pojedynczych programistów.

To nie oznacza że nie możesz mi wytłumaczyć...

Po to że są różne zespoły i różne środowiska. Ja pracuje przy webówce ale to nie ma zbyt dużego znaczenia -> jest branch zespołowy, wrzucamy na gita, jenkins + git same odpowiadają za merge ze środowiskiem np. testowym i tyle.

Ale Buildy na reklamach trwają np. 1.5h a mój Build trwa np. 10 minut. To jak to jest???

Bo masz mały system. U nas Jenkins sam co jakiś czas sobie wszystko buduje i rozsyła raporty. Tak samo Jenkins sam przenosi zmiany między gałęziami. U nas deploy całego systemu na Jenkinsie trwa 3h, a jest to serwer z 2 x Xeon 10 rdzeni i ramdyski. Kwestia skali.

lukas_gab napisał(a):

Bo masz mały system. U nas Jenkins sam co jakiś czas sobie wszystko buduje i rozsyła raporty. Tak samo Jenkins sam przenosi zmiany między gałęziami. U nas deploy całego systemu na Jenkinsie trwa 3h, a jest to serwer z 2 x Xeon 10 rdzeni i ramdyski. Kwestia skali.

No dobra, ale o jakiej skali mówimy??? Czy to projekt na 1000h jednego człowieka, czy 500h teamu po 50 osób???

Ten system co buduje się 3h to buduje od 3-10 osób od 17 lat na pełen etat. To też kwestia technologii. Np. C++ buduje się dłużej od takiego C# a wynika to z architektury tychże języków.

lukas_gab napisał(a):

Ten system co buduje się 3h to buduje od 3-10 osób od 17 lat na pełen etat. To też kwestia technologii. Np. C++ buduje się dłużej od takiego C# a wynika to z architektury tychże języków.

A jeśli można widzieć (choć to trochę głupie pytanie) ile skrypt ma linijek (w tys.)

@Matisiek PL powodów na używanie CI jest bardzo dużo:

• automatyczne budowanie i publikowanie artefaktów w repozytorium jeśli aplikacja po pushu się buduje
• automatyczne uruchamianie wszystkich testów -> ciekawe kto przy każdym lokalnym przekompilowaniu projektu ma włączone wszystkie testy, w tym integracyjne ;)

Zauważ że to nie jest tak że lokalnie pracujesz nad jakimiś usprawnieniami i każdy build wysyłasz do CI, bo to by było bez sensu i może się zdarzyc chyba tylko jeśli aplikacja to jakaś mega kobyła i zbudowanie jej jest zbyt skomplikowane. Pracujesz lokalnie, ale kiedy uznasz ze coś jest "gotowe" to robisz push a CI automatycznie zbuduje nową wersje systemu z twoimi zmianami i poinformuje cię jeśli wywaliły się jakieś testy. Dla dużych aplikacji odpalenie wszystkich testów może trwać długi czas, stąd też programisci często uruchamiaja tylko te, które w ich mniemaniu dotyczą tego nad czym pracowali.

Nie rozumiem też gdzie widzisz jakiś narzut czasowy. Taska robisz przecież raz a potem sam sobie żyje. Ustawiasz np. że co 20 min sprawdza nowe zmiany w repo i jak są to buduje i voila. Spędziłeś całe 5 minut nad utworzeniem tego taska a teraz będzie działał automatycznie jak tylko wrzucisz swoje zmiany do repo.

Shalom napisał(a):

@Matisiek PL powodów na używanie CI jest bardzo dużo:

• automatyczne budowanie i publikowanie artefaktów w repozytorium jeśli aplikacja po pushu się buduje
• automatyczne uruchamianie wszystkich testów -> ciekawe kto przy każdym lokalnym przekompilowaniu projektu ma włączone wszystkie testy, w tym integracyjne ;)

Zauważ że to nie jest tak że lokalnie pracujesz nad jakimiś usprawnieniami i każdy build wysyłasz do CI, bo to by było bez sensu i może się zdarzyc chyba tylko jeśli aplikacja to jakaś mega kobyła i zbudowanie jej jest zbyt skomplikowane. Pracujesz lokalnie, ale kiedy uznasz ze coś jest "gotowe" to robisz push a CI automatycznie zbuduje nową wersje systemu z twoimi zmianami i poinformuje cię jeśli wywaliły się jakieś testy. Dla dużych aplikacji odpalenie wszystkich testów może trwać długi czas, stąd też programisci często uruchamiaja tylko te, które w ich mniemaniu dotyczą tego nad czym pracowali.

Nie rozumiem też gdzie widzisz jakiś narzut czasowy. Taska robisz przecież raz a potem sam sobie żyje. Ustawiasz np. że co 20 min sprawdza nowe zmiany w repo i jak są to buduje i voila. Spędziłeś całe 5 minut nad utworzeniem tego taska a teraz będzie działał automatycznie jak tylko wrzucisz swoje zmiany do repo.

Wiesz, wyczerpałeś mój temat, stąd dzięki. Poza tym, nie mam jakiegoś narzutu czasowego, tylko bardzo mnie ciekawiło skąd biorą się takie czasy build'u. Teraz wiem, że testy trochę czasu zajmują i kompilacja dużych projektów nie jest bardzo szybka. Ciekawi mnie jeszcze tylko jedna rzecz. Jakiego typu są projekty, które zajmują na sam build kilka godzin? Czy jest to jakiś rozbudowany CMS do zarządzania klientami dla wielkich korporacji, czy są to gigantyczne skrypty do obliczania czegoś???

PS. Jeszcze raz dzięki wielkie...

Tak jak @Shalom wspomniał, narzędzia CI są do budowania środowiska oraz odpalania wszystkich testów.

Podam Ci też przykład na środowisku Pythonowym.
Jak piszesz jakąś paczkę/bibliotekę i chcesz, żeby była kompatybilna z wszystkimi wersjami Pythona (py2.7, py3.3, py3.4, py3.5, py3.6) to podpinasz to wszystko pod np. Appveyor'a (narzędzie CI) i sam Ci uruchamia wszystkie testy na wszystkich wersjach. I Ty jako developer nie spędzasz czasu na uruchamianiu wszystkiego ręcznie, albo przez skrypt, i nie wkurzasz się jak Ci komp muli, bo odpala ileś tam testów :).

Dodatkowo jak np. jesteś project managerem paru projektów/apek to możesz sobie na Jenkinsie podejrzeć, czy wszystkie projekty są zielone (testy przechodzą) i czy nie ma żadnych problemów z np. nowymi funkcjonalnościami itp. Tak jest w dużych organizacjach jak np. w Mozilli (http://weblogs.mozillazine.org/stephend/)

Co innego jest mała aplikacja. Wyobraź sobie aplikację którą rozwijają dziesiątki programistów i ma kilkadziesiąt jeśli nie kilkaset tysięcy lini kodu. Podejrzewam że te Twoje aplikacje mają kilkaset/kilka tysięcy lini, więc troche inna skala ;)

@Shalom:

Shalom napisał(a):

@Matisiek PL powodów na używanie CI jest bardzo dużo:

• automatyczne budowanie i publikowanie artefaktów w repozytorium jeśli aplikacja po pushu się buduje
• automatyczne uruchamianie wszystkich testów -> ciekawe kto przy każdym lokalnym przekompilowaniu projektu ma włączone wszystkie testy, w tym integracyjne ;)

Zauważ że to nie jest tak że lokalnie pracujesz nad jakimiś usprawnieniami i każdy build wysyłasz do CI, bo to by było bez sensu i może się zdarzyc chyba tylko jeśli aplikacja to jakaś mega kobyła i zbudowanie jej jest zbyt skomplikowane. Pracujesz lokalnie, ale kiedy uznasz ze coś jest "gotowe" to robisz push a CI automatycznie zbuduje nową wersje systemu z twoimi zmianami i poinformuje cię jeśli wywaliły się jakieś testy. Dla dużych aplikacji odpalenie wszystkich testów może trwać długi czas, stąd też programisci często uruchamiaja tylko te, które w ich mniemaniu dotyczą tego nad czym pracowali.

Nie rozumiem też gdzie widzisz jakiś narzut czasowy. Taska robisz przecież raz a potem sam sobie żyje. Ustawiasz np. że co 20 min sprawdza nowe zmiany w repo i jak są to buduje i voila. Spędziłeś całe 5 minut nad utworzeniem tego taska a teraz będzie działał automatycznie jak tylko wrzucisz swoje zmiany do repo.

Mam pytanie: dlaczego dużo osób ustawia, że co 20 minut włącza Ci build'a??? Nie lepiej od razu włączać build'a po commicie???

Bo nie zawsze jest to możliwe? Jeśli masz CI sprzęgnięte jakoś z VCSem to można tak zrobić, np. gitlab + gitlab CI. Ale jeśli masz zupełnie niezależne rzeczy np. SVN + Jenkins to nie ma prostej metody na triggerowanie takiego builda po commicie. Jedyne co można zrobić to sprawdzać np. co te 20 minut czy pojawiły sie nowe commity i jeśli tak to budować aplikacje.

Z drugiej strony znów build na CI jest często "ciężki" bo odpala testy więc może nie chcesz mieć miliona buildów na raz, jeśli zespół jest duży, tylko np. zbiorczo co jakiś czas build z większą liczba zmian.

Shalom napisał(a):

Bo nie zawsze jest to możliwe? Jeśli masz CI sprzęgnięte jakoś z VCSem to można tak zrobić, np. gitlab + gitlab CI. Ale jeśli masz zupełnie niezależne rzeczy np. SVN + Jenkins to nie ma prostej metody na triggerowanie takiego builda po commicie. Jedyne co można zrobić to sprawdzać np. co te 20 minut czy pojawiły sie nowe commity i jeśli tak to budować aplikacje.

Z drugiej strony znów build na CI jest często "ciężki" bo odpala testy więc może nie chcesz mieć miliona buildów na raz, jeśli zespół jest duży, tylko np. zbiorczo co jakiś czas build z większą liczba zmian.

@Shalom
A nie można włączać takiego build'a ręcznie po commcie??? Np. jednym klikiem???

No można, ale komu by się chciało? ;)

Shalom napisał(a):

No można, ale komu by się chciało? ;)

@Shalom
Chmmm, ciekawa logika: nie klikniesz guziczka, bo Ci się nie chce i se poczekasz 20 minut dłużej... - Pomysłowe...

I też takie pytanie: co gdybym pisał w Java'ie skrypta i chciał sprawdzić czy na wszystkich wersjach lib'a pomocniczego mój skrypt działa... Pod czym mam googlać???