W którym momencie ciekawy jest serwer ciągłej integracji?

Czytałem trochę o serwerach CI takich jak Jenkins i zastanawiam się: w którym momencie jest to przydatne?

Ponieważ z pewnością w przypadku małego projektu, w którym miałbyś tylko 5 klas i 10 testów jednostkowych, nie ma prawdziwej potrzeby.

Tutaj mamy około 1500 testów jednostkowych, które przechodzą (na starych stacjach roboczych Core 2 Duo) w około 90 sekund (ponieważ tak naprawdę testują „jednostki”, a zatem są bardzo szybkie). Zasada jest taka, że ​​nie możemy zatwierdzić kodu, gdy test się nie powiedzie.

Dlatego każdy programista uruchamia wszystkie swoje testy, aby zapobiec regresji.

Oczywiście, ponieważ wszyscy programiści zawsze uruchamiają cały test, wychwytujemy błędy z powodu sprzecznych zmian, gdy tylko jeden programiści pobierze zmianę innego (jeśli taki istnieje).

Nadal nie jest to dla mnie jasne: czy powinienem skonfigurować serwer CI taki jak Jenkins? Co by to przyniosło?

Czy jest to przydatne do zwiększenia prędkości? (w naszym przypadku to nie problem)

Czy jest przydatny, ponieważ można tworzyć stare kompilacje? (ale możemy to zrobić za pomocą Mercurial, sprawdzając stare obroty)

Zasadniczo rozumiem, że to może być przydatne, ale nie rozumiem dokładnie, dlaczego.

Wszelkie wyjaśnienia uwzględniające powyższe kwestie byłyby bardzo mile widziane.

Czy jest to przydatne do zwiększenia prędkości? (w naszym przypadku to nie problem)

Każdy czas spędzony na cyklach to proces, który mógłbyś poświęcić na rozwój.

Zaoszczędzisz także czas na kamieniach milowych, ponieważ idealnie budujesz w pełni zapakowane i gotowe do wysyłki bity, które można nagrać bezpośrednio na płytę CD, przesłać do Internetu itp.

Czy jest przydatny, ponieważ można tworzyć stare kompilacje? (ale możemy to zrobić za pomocą Mercurial, sprawdzając stare obroty)

Nie, nie odtwarzasz kompilacji. Korzystasz z utworzonej przez siebie kompilacji i trzymasz ją do momentu, aż ustawienia przechowywania ją wyrzucą.

Budujesz go na serwerze kompilacji, a nie na pudełku Deva.

Tutaj mamy około 1500 testów jednostkowych, które przechodzą (na starych stacjach roboczych Core 2 Duo) w około 90 sekund (ponieważ tak naprawdę testują „jednostki”, a zatem są bardzo szybkie). Zasada jest taka, że ​​nie możemy zatwierdzić kodu, gdy test się nie powiedzie.

Ponadto, czy nie chciałbyś mieć możliwości przeprowadzenia automatycznej integracji lub kompleksowych testów kodu i wychwycenia problemów, których nie wykryją testy jednostkowe?

Nie chciałbyś uruchamiać ich na urządzeniach deweloperskich, ponieważ skonfigurowanie i utrzymanie tego środowiska byłoby uciążliwe. Testy integracji są również bardzo powolne.

w którym momencie jest to przydatne?

Jest to inwestycja jak każda inna.

Skorzystaj z niego raz, a możesz wyjść z tyłu lub nawet osiągnąć próg rentowności. Użyj go do wielu projektów, a prawdopodobnie wyjdziesz na przód.

Zależy to również od rodzaju tworzonych aplikacji.

Jeśli tworzysz aplikacje internetowe, które trzeba wdrożyć na serwerze aplikacji Java lub IIS, CI staje się oczywiste. To samo, jeśli masz bazę danych jako część swojego projektu. Wdrożenie jest bolesne, aby wykonać go ręcznie, a Twój zespół kontroli jakości (jeśli go masz) będzie go potrzebował tak często, jak codziennie w pewnym momencie.

Możesz także chcieć zobaczyć, jak twoje potrzeby i problemy są zgodne z 12 krokami Joela Spolsky'ego do lepszego kodu . W szczególności 2, 3 i 10 (choć wszystkie są interesujące i ważne).

W którym momencie jest to przydatne?

• Cykl kompilacji + testowania trwa kilka minut. Dzięki 5-minutowemu testowi nie będziesz już musiał uruchamiać wszystkich testów samodzielnie, szczególnie w przypadku drobnych zmian.
• Zaczynasz budować wiele wariantów. Jeśli masz kilku klientów z różnymi dostosowaniami, powinieneś uruchomić testy dla każdego wariantu, aby ilość pracy zaczęła rosnąć dość szybko. Następnie uruchom pakiet testowy dla jednego wariantu na komputerze programisty i pozostaw go CI, aby uruchomił go na pozostałych.
• Piszesz zautomatyzowane testy integracyjne, które wymagają trochę niebanalnych konfiguracji środowiska testowego. Niż chcesz przetestować na jednym kanonicznym środowisku testowym, ponieważ programiści mogą modyfikować swoje środowisko na różne sposoby z powodu zmian programistycznych. CI jest najbardziej odpowiednim miejscem dla środowiska kanonicznego.
• Testerzy mogą po prostu pobrać najnowszą wersję z CI. Dlatego nie muszą mieć, uczyć się i używać narzędzi programistycznych, ani też żaden programista nie musi przesyłać im swoich wersji ręcznie.
• Kiedy przygotowujesz się do wydania:
  • Testowanie staje się ważniejsze, więc posiadanie jednego miejsca z przygotowanymi kompilacjami do testowania jest jeszcze bardziej przydatne.
  • Jesteś pewien, że wszystkie kompilacje są budowane w tym samym środowisku kompilacji, dzięki czemu unikasz problemów, które mogą wynikać z subtelnych różnic między instalacjami programistów.
  • Jesteś pewien, że budujesz dokładnie to, co jest sprawdzane w systemie kontroli wersji. Jeśli podczas programowania ktoś zapomni coś sprawdzić, znajdziesz dość szybko, ponieważ nie powiedzie się to dla następnego programisty. Ale jeśli taka kompilacja przejdzie do kontroli jakości lub produkcji i zgłosi błąd, bardzo trudno będzie namierzyć.

Prawdopodobnie nie potrzebujesz jeszcze CI, ale myślę, że przyda się, gdy przejdziesz do fazy testowania. Jenkins jest konfigurowany w ciągu kilku godzin, co uprości testowanie i pomoże uniknąć głupich błędów (dzieje się tak zwłaszcza, gdy spieszycie się z szybką poprawką do produkcji).

Dla mnie CI staje się interesujące, jeśli twój zespół ma więcej niż 1 członka.

Musisz przestać myśleć o CI jako o „innym komputerze z uruchomionymi dla mnie testami”. CI o posiadaniu zdefiniowanego i zautomatyzowanego procesu kompilacji i zarządzania wydaniami.

CI to jedyny autorytatywny podmiot, który tworzy wersję oprogramowania. Jeśli nie opiera się na CI, to po prostu się nie stało.

Dzięki CI masz ograniczenia w automatyzacji wszystkiego, co pokaże wszystkie ręczne poprawki, hacki i skróty, które masz na swoim miejscu i po prostu nie działają z CI i należy go przede wszystkim unikać.

Problemy, których unika:

• Kto jest odpowiedzialny za budowę wydania
• Czy ta osoba jest dostępna 24/7
• Ale opiera się na syndromie mojej maszyny
• Usuwa wszelkie niejasności dotyczące wydanej przez nas wersji

Zalety (po prostu zbyt wiele, by wymienić wszystkie):

• Zautomatyzowane numerowanie wersji
• Integracja śledzenia problemów
• Zautomatyzowane generowanie metryk
• Analiza kodu statycznego
• Zautomatyzowane wdrażanie
• Konfiguracje wielostopniowe

Jest jeden podstawowy problem związany z ciągłą integracją (CI), który jest doskonale odzwierciedlony w twoim pytaniu: praktyki CI są trudne do wdrożenia i obrony, ponieważ oprogramowanie serwera CI nie jest łatwe do skonfigurowania, ani nie jest łatwe do uruchomienia i uruchomienia projektów przez CI serwer. Dzięki temu trudno jest naprawdę zrozumieć, gdzie w ogóle jest korzyść z przyjmowania CI.

Przede wszystkim CI dotyczy wglądu i jakości. Dobry CI przybliża Cię do twojego projektu, zapewnia odpowiednią informację zwrotną na temat wskaźników jakości, dokumentacji, zgodności ze standardami kodowania itp. Powinien zapewnić narzędzia do łatwej wizualizacji tego wszystkiego i umożliwić szybkie rozpoznanie i łatwe rozpoznanie powiąż zestaw zmian z określoną migawką wszystkich tych wskaźników projektu.

Jest nie tylko o bieganiu testy jednostkowe. Ani trochę! Co prowadzi mnie do jakości. CI obejmuje błędy, nie omija ich ani nie wyrzuca. To, co robi, to po prostu zapewnia narzędzie do wcześniejszego błędu, zamiast później. Tak więc tak naprawdę nie zatwierdzasz wcześniej przetestowanego kodu na serwerze CI. Chociaż powinieneś dążyć do zatwierdzenia czystego i nieuszkodzonego kodu, tak naprawdę używasz serwera CI, aby automatycznie uruchamiać program budujący integrację automatycznie za pomocą twojego kodu i sprawić, aby wszystko poszło dobrze. Jeśli tak, to fajnie! Jeśli nie, nie ma problemu - dobre praktyki CI mówią, że Twoim następnym priorytetem powinno być naprawienie tego, co się zepsuło. Które, na dobrym serwerze CI, powinno być dla ciebie łatwe do wskazania.

Wraz ze wzrostem wielkości zespołu integracja kodu każdego staje się naturalnie trudniejsza. Zadaniem scentralizowanego serwera CI powinno być testowanie wszystkich zintegrowanych części i odciążenie członków zespołu. Więc musisz mieć wszystkich, którzy zaczynają wcześnie (i jak najczystiej), a następnie monitorują status kompilacji (zwykle są wysyłane powiadomienia). I znowu, jeśli coś zostanie zepsute z powodu zatwierdzenia przez jakiegoś dewelopera, natychmiast staje się jego odpowiedzialnością, aby to naprawić i natychmiast przywrócić te automatyczne kompilacje do stanu OK.

Widzicie więc, moim zdaniem, każdy projekt korzysta z ciągłej integracji. Chodzi o to, że do tej pory i ze względu na zadziwiającą złożoność każdego serwera CI, którego znam, ludzie naprawdę odpierali praktyki CI przy mniejszych / prostszych projektach. Ponieważ ludzie mają lepsze rzeczy do roboty niż spędzanie dni na konfigurowaniu brzydkiego, zbyt złożonego, niedostarczającego i rozdętego oprogramowania.

Miałem dokładnie ten sam problem i to właśnie od około roku temu rozwijam Cintient w wolnym czasie. Moim założeniem było uproszczenie instalacji, konfiguracji i użytkowania oraz dostarczenie tych wskaźników jakości, których wszyscy inni zawodzą lub nie osiągają wyników. Tak więc po tej długiej odpowiedzi pojawia się moja bezwstydna wtyczka wskazująca łącze GitHub do projektu (który jest darmowy i open source, natch). Najwyraźniej ma też kilka fajnych zrzutów ekranu. :-) https://github.com/matamouros/cintient

Mam nadzieję, że ci pomogłem.

(UWAGA: Edytowane po komentarzu Bryana Oakleya na temat faktu, że powinienem poświęcić więcej czasu na opracowanie lepszej odpowiedzi. Myślę też, że miał rację.)