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.