Ilu programistów przed ciągłą integracją staje się dla nas skuteczna?

Narzut związany jest z ciągłą integracją, np. Konfiguracją, ponownym szkoleniem, działaniami uświadamiającymi, przestojem w celu naprawy „błędów”, które okazują się problemami z danymi, wymuszonym rozdziałem stylów programowania itp.

W którym momencie ciągła integracja się zwraca?

EDYCJA: To były moje ustalenia

Ustawieniem był CruiseControl.Net z Nantem, odczyt z VSS lub TFS.

Oto kilka przyczyn niepowodzenia, które nie mają nic wspólnego z konfiguracją:

Koszt dochodzenia : czas poświęcony na sprawdzenie, czy czerwone światło jest spowodowane autentyczną logiczną niespójnością w kodzie, jakością danych lub innym źródłem, takim jak problem z infrastrukturą (np. Problem z siecią, czas oczekiwania z kontroli źródła, serwer strony trzeciej nie działa itp.)

Koszty polityczne związane z infrastrukturą : Rozważyłem przeprowadzenie kontroli „infrastruktury” dla każdej metody w trakcie testu. Nie miałem rozwiązania problemu z przekroczeniem limitu czasu oprócz wymiany serwera kompilacji. Utrudniła biurokracja i nie było wymiany serwera.

Koszt naprawy testów jednostkowych : Czerwone światło z powodu problemów z jakością danych może wskazywać na źle napisany test jednostkowy. Testy jednostkowe zależne od danych zostały ponownie zapisane, aby zmniejszyć prawdopodobieństwo wystąpienia czerwonego światła z powodu złych danych. W wielu przypadkach do środowiska testowego wstawiano niezbędne dane, aby móc dokładnie uruchomić testy jednostkowe. Sensowne jest stwierdzenie, że dzięki wzmocnieniu danych test staje się bardziej niezawodny, jeśli jest zależny od tych danych. Oczywiście działało to dobrze!

Koszt pokrycia, tj. Napisanie testów jednostkowych dla już istniejącego kodu : Wystąpił problem z pokryciem testów jednostkowych. Istnieją tysiące metod, które nie miały testów jednostkowych. Aby je stworzyć, potrzebna byłaby znaczna liczba osobodni. Ponieważ byłoby to zbyt trudne do uzasadnienia biznesowego, zdecydowano, że testy jednostkowe będą stosowane w każdej nowej metodzie publicznej. Te, które nie miały testu jednostkowego, zostały nazwane „potencjalnie w podczerwieni”. Interesujące jest tutaj to, że metody statyczne były spornym punktem, w jaki sposób można jednoznacznie określić, w jaki sposób zawiodła konkretna metoda statyczna.

Koszt wydań na zamówienie : skrypty Nant posuwają się do tej pory. Nie są one szczególnie przydatne w, powiedzmy, kompilacjach zależnych od CMS dla EPiServer, CMS lub dowolnego wdrożenia bazy danych zorientowanego na interfejs użytkownika.

Są to rodzaje problemów, które wystąpiły na serwerze kompilacji podczas cogodzinnych testów i kompilacji nocnej kontroli jakości. Cieszę się, że te, które są zbędne jako mistrz kompilacji, mogą wykonywać te zadania ręcznie w momencie wydania, zwłaszcza z jednoosobowym zespołem i małą kompilacją. Tak więc kompilacje jednoetapowe nie uzasadniają użycia CI w moim doświadczeniu. Co z bardziej złożonymi, wieloetapowymi kompilacjami? Może to być trudny do zbudowania, zwłaszcza bez skryptu Nanta. Tak więc, nawet po stworzeniu, nie odniosły już sukcesu. Koszty naprawy problemów z czerwonym światłem przewyższały korzyści. W końcu programiści stracili zainteresowanie i zakwestionowali ważność czerwonego światła.

Po rzetelnej próbie uważam, że CI jest drogi i że jest dużo pracy wokół krawędzi, zamiast po prostu wykonać zadanie. Bardziej opłacalne jest zatrudnianie doświadczonych programistów, którzy nie robią bałaganu przy dużych projektach, niż wprowadzać i utrzymywać system alarmowy.

Dzieje się tak nawet wtedy, gdy ci programiści odejdą. Nie ma znaczenia, czy dobry programista odejdzie, ponieważ śledzone przez niego procesy zapewniłyby, że zapisuje specyfikacje wymagań, specyfikacje projektowe, przestrzega wytycznych kodowania i komentuje swój kod, aby był czytelny. Wszystko to jest sprawdzane. Jeśli tak się nie dzieje, lider zespołu nie wykonuje swojej pracy, którą powinien odebrać jego menedżer i tak dalej.

Aby CI działał, nie wystarczy pisać testy jednostkowe, próbować utrzymać pełne pokrycie i zapewnić działającą infrastrukturę dla dużych systemów.

Podsumowując: Można zadać pytanie, czy naprawienie jak największej liczby błędów przed wydaniem jest nawet pożądane z punktu widzenia biznesu. CI wymaga wiele pracy, aby uchwycić garść błędów, które klient może zidentyfikować w UAT lub firma może otrzymać zapłatę za naprawę w ramach umowy serwisowej po wygaśnięciu okresu gwarancji.

Ustawienie silnika CI jest podobne do ustawienia alarmu przeciwpożarowego w domu.

Moim zdaniem korzyści nie korelują z wieloma programistami, ale z dużą bazą kodu. Silnik CI aktywnie wykonuje nudne prace, których sam nie chcesz wykonywać, i wykonuj je za każdym razem.

Jeśli zepsujesz moduł zdalny, którego nie dotknąłeś przez długi czas, zostaniesz o tym natychmiast poinformowany. Nie tylko pod względem kompilacji, ale także funkcjonalnie, jeśli skonfigurowano testy jednostkowe.

Pamiętaj również, że jeśli pozwolisz silnikowi CI wykonać całą nudną pracę, w tym konfigurację instalatorów itp., Nie musisz tego robić ręcznie. Możesz po prostu sprawdzić swoje źródło i czekać na gotowy produkt budowany w standardowej lokalizacji. (EDYCJA: Silnik CI działa również w dobrze zdefiniowanym środowisku, unikając jakichkolwiek konfiguracji specyficznych dla programisty, zapewniając powtarzalność)

To także część zapewnienia jakości.

EDYCJA: Po napisaniu powyższego miałem doświadczenie z narzędziem do budowania Maven dla Javy. Zasadniczo pozwala nam to zachować pełną konfigurację CI w projekcie (z pom.xml), co znacznie ułatwia utrzymanie instalacji CI i / lub migrację do innego silnika CI.

Nie chodzi o to, ilu programistów, ale ile kroków potrzeba, aby przejść od 1 do n (włącznie), gdzie 1 & n to ...

1: Sprawdzanie kodu
I
n: posiadanie instalowalnych \ wdrożalnych pakietów

Jeśli n <2, być może nie potrzebujesz CI, w
przeciwnym razie potrzebujesz CI

Aktualizacja
Po przeczytaniu twoich ustaleń mogę jedynie stwierdzić, że podszedłeś do CI z niewłaściwego kierunku iz niewłaściwych powodów.

Może to być warte wysiłku nawet dla jednego zespołu. Jest to szczególnie prawdziwe, gdy tworzysz kod dla wielu platform i musisz upewnić się, że zmiany będą działać na obu platformach. Na przykład kompilator C ++ firmy Microsoft jest bardziej akceptowalny niż GCC, więc jeśli tworzysz w systemie Windows, ale musisz także obsługiwać Linuksa, posiadanie systemu CI poinformuje Cię, kiedy kompilacja ulegnie awarii w Linuksie.

Niektóre systemy CI są dość łatwe do skonfigurowania, więc koszty ogólne nie są tak duże. Spróbuj na przykład Jenkins lub Hudson.

Jak mówisz, istnieje koszty ogólne związane z jego konfiguracją i utrzymaniem.

Ale pytanie, gdzie jest próg rentowności, nie jest funkcją liczby osób, które masz w zespole, ale raczej funkcją długości twojego projektu.

To powiedziawszy, część kosztów konfiguracji można wykorzystać we wszystkich przyszłych projektach, więc w długim okresie koszty ogólne mogą zbliżyć się do zera.

W tym tygodniu skonfigurowałem Jenkinsa, aby zbudować mały projekt .NET, nad którym pracuję. Zintegrowałem go z moją kontrolą źródła Git, aby uruchamiał kompilację przy każdym zatwierdzeniu. Zintegrowałem testy jednostkowe z kompilacją. Zintegrowałem analizę statyczną w postaci naruszeń FxCop i StyleCop.

Teraz za każdym razem, gdy się melduję, sprawdza cały mój kod, buduje go, zwiększa numer wersji we wszystkich zestawach, testuje go, analizuje pod kątem naruszeń FxCop i StyleCop, archiwizuje kompilację i zapisuje wyniki na wielu wykresach, więc Mam widoczność w czasie wyników testów i naruszeń.

Wykonanie tego od zera zajmuje około godziny (może dzień w Google, jeśli wcześniej tego nie robiłeś). Nie kosztuje nic, ponieważ wszystkie narzędzia są dostępne za darmo.

Jeśli, jak i kiedy projekt się buduje, mam infrastrukturę wysokiej jakości, która będzie rosła wraz z nią bez żadnych kosztów. Jeśli lub kiedy nowi programiści dołączą do projektu, mogę uzyskać całkowitą widoczność ich pracy i ich wpływu na projekt bez żadnych kosztów.

Tak więc jedynym scenariuszem, w którym widzę, że CI nie jest warta czasu, jest albo projekt, który zajmie około dnia, a potem nigdy nie zostanie ponownie odwiedzony, lub taki w języku, w którym nie ma dostępnych / bezpłatnych narzędzi i koszt ich nabycia jest nieproporcjonalny do pracy.

Jeśli możesz zweryfikować wszystkie aspekty projektu po każdej zmianie, nie potrzebujesz CI.

We wszystkich innych przypadkach jest to wygrana netto.

Koszty ogólne są minimalne. Powiedziałbym, że przy projektach jednoosobowych byłoby to przydatne. Gdy osiągniesz dwa, jest to bezcenne.

Zgadzam się, że w przypadku projektów jednoosobowych, jeśli masz „jednoetapową kompilację / weryfikację”, możesz być w porządku z ciągłą integracją, ale w tych przypadkach wykonałeś większość ciężkiej pracy, aby skonfigurować CI, więc równie dobrze możesz po prostu położyć w systemie formalnym (CC, Hudson, TeamCity itp.).

Na pytanie, kiedy CI się zwraca, trudno jest odpowiedzieć na nowy projekt.

W istniejącym projekcie jest znacznie łatwiej zobaczyć. Jeśli znajdziesz krytyczny błąd w części rozwojowej łańcucha dostaw, wiesz, że problem istnieje jak najwcześniej. Koszt naprawy, który jest teraz najniższy. Jeśli ten problem występuje w środowiskach innych niż programistyczne, koszty są wyższe.

Teraz kierownictwo może zdecydować o wydaniu z błędem, ale to ryzyko biznesowe. Przynajmniej teraz można to złagodzić dzięki tej ocenie ryzyka, a nie późnym wieczorem telefonicznym / panikującym, które, gdyby były rozliczane według stawek godzinowych, okazałyby się być bardzo drogie.

Kolejna rzecz do rozważenia pod względem kosztów. Jaki jest twój dział kontroli jakości? Czy to testy ręczne? Jeśli przejdziesz na CI, możesz być w stanie obniżyć ogólne koszty kontroli jakości, automatyzując te skrypty w stosunku do twojego urządzenia deweloperskiego. Możesz być w stanie zmniejszyć liczbę osób odpowiedzialnych za kontrolę jakości projektu, angażując ich w fazę CI.

CI zawsze jest zawsze tego warte: poczucie bezpieczeństwa, które daje, pozwala pracować szybciej, niż byłoby to możliwe. Wydaje się, że masz problem z testami jednostkowymi. Zgadzam się, że testy jednostkowe są bardzo drogie, ale uważam również, że (pod wieloma względami) są one najgorszą opcją, jaką mamy. Osobiście i dla rodzajów systemów, nad którymi zwykle pracuję, przysięgam na testy na poziomie systemu działające na kombinacji rzeczywistych i (być może syntetycznych) przypadków patologicznych; Jest tańszy niż testy jednostkowe i trafia w te trudno dostępne zakątki wszechświata koncepcyjnego: „Nieznane nieznane” Donalda Rumsfelda.

Zawsze go używaj, niezależnie od wielkości zespołu. Jeśli tylko ty, na przykład, kto wie, być może kodujesz ze swojego laptopa w starbucks, to kontynuujesz pracę z bardziej rozbudowanym systemem w domu?

Koszty ogólne naprawdę nie są takie złe.

Jeden. Tak, wystarczy rozpocząć ciągłą integrację.

Nie chodzi o to, ilu programistów, ale o

za. Ile czasu oszczędzasz dzięki automatyzacji i jak często.

• Oszczędność czasu na budowaniu po integracji, przeprowadzaniu automatycznych testów i tworzeniu ustawień * częstotliwość zameldowania = procent zaoszczędzonego czasu.

b. Ile masz wersji / oddziałów / produktów.

• Jeśli masz jednego programistę pracującego w dwóch różnych gałęziach, zaoszczędzony czas zostanie podwojony, ponieważ każdy oddział będzie wymagał budowy, testowania i pakowania.