Jak dlugo buduja sie wasze projekty?

Czesc, tak jak w temacie. Jestem ciekawe, czy macie podobnie do mnie ;P

Każdy mikroserwis między 10 a 20sek. Odpalenie każdego z nick w zdokeryzowanym środowisku kolejne 15sek.

no tak jakoś ponad godzinkę a co?

Mój projekt kilka sekund. Ale serwis klienta, który jest potrzebny po każdej zmianie potrzebuje ponad godzinę jeśli były jakieś zmiany w bazie.

Pytam, bo u nas kazda zmiana i przebudowanie trwa ok. 8 minut. Mamy wielka korpo kupe.

Zależy. Miałem projekty co poniżej minuty, ale obecny system ponad 3h(C#).

10 sekund z deploymentem.

duża platforma ecommercowa: średnio 15 sekund build, start: 5:00.

Jeden projekt na windowsie około 1 min +uruchomienie 30s na linuxie wszystko razem 45s
Drugi około 1min

W typowym cyklu (feedback) to mam sekundę max kilka - test -> wynik, restart servera z nowymi klasami, zmiana wyglądu lub zachowania w WEBie.

Pełny clean build z unit testami i start serwera - minuta, dwie.
Pełne testy zajmują dużo więcej (np. w ostatnim projekcie mam testy związane z dużym loadem i zajętością pamięci - musi system pomielić pare minut, żeby mieć pewnośc, że daje rade i nie ma wycieku).

Ale to w zdrowych projektach - mam takich kilka.

Mam / miałem też chore projekty - cykl zmień zobacz - 45 minut i to bez pewności, że zmiany faktycznie wlezą na serwer :-)
Deploy na srodowisko testowe kilka godzin (przy czym dodatkowo dużo pracy biurokratycznej).

Ogólnie jeśli feedback jest ponad kilka sekund to jest to nieefektywna praca. Powyżej 30 sekund baaardzo nieefektywna.
A powyżej 3 minut to już BDSM ( korpo norma).

Dawno temu w jednej pracy mieliśmy miarę znudzenia podczas czekania na build i notowaliśmy jak głęboko zaszliśmy w czytaniu
zakamarków internetu. Wyznacznikiem ostatecznym było dalekie zejście w archiwum grupy pl.rec.rowery (z przeczytaniem wszystkich wątków, aż do bieżących)..

Rookie numbers :P Pracowałem kiedyś przy projekcie pewnej dużej, trzyliterowej firmy i projekt to był taki mother of all monoliths i budował się ~3h. Taktyki były dwie:

1. Klepiesz cały dzień polegając tylko i wyłącznie na testach, puszczasz build na noc, rano modlisz się żeby się zbudowało i nie wywaliło testów integracyjnych / end to end
2. Hacker style, podmieniasz skompilowane klasy w jarach, niemniej to akurat nie zawsze było możliwe.

Okej, czyli co, szybkie buildy to male projekty albo mikroserwisy? Przeciez kazdy wiekszy system (starszy) to jeden wielki moloch. Plusy sa takie, ze nie ma wymowek przed TDD, skoro kompiluje sie tyle czasu, ale wez tu zrob release szybko..

Szybkie buildy to:

• Inwestycja, która się szybko(błyskawicznie) zwraca, ale ktoś musi się to leguralnie poprawiać,
• inwestycja konkretnie w: dopieszczone skrypty do buildu i ich konfiguracje/profile,
• poleganie na testach, robisz featury pisząc testy i ufasz, że zadziałają też na produkcji (ależ tu mam czasem zdziwienia :-)),
• odpowiednie technologie - jakikolwiek application server, wary, eary to dramat, (ale da się poprawić je korzystając np. z JRebel)

Generalnie jeśli firma/zespół nie inwestuje w szybki build to szkoda tam pracować, nie szanują twojego czasu, nie szanują pieniędzy.

Kilka razy udało mi się praktyczny build time skrócić z ponad 30 minut do kilku minut.
Przykład z ostatniej firmy: build incrementalny nie działał, trzeba robić full - 45 minut. Udało mi się z pomocą wielu magów uruchomić inkrementalny - zrobiły sie 3 minuty. Doszedł do zespołu nowy mag ( skubany młody zdolny) i dożyłował do kilku... sekund (przy typowym cyklu pracy w tym projekcie- dość specyficzne technologie). Full build na CI udało się skrócić do ok. 25 minut, czyli nadal był długi, ale to tak nie boli.

Jeszcze mała refleksja. Tam było 15 programistów, każdy build 45 minut. Praca na etat. Stawki za godzinę normalne, Szwajcarskie.