Ciągła integracja: która częstotliwość?

Zawsze uruchamiałem kompilacje po każdym zatwierdzeniu, ale w tym nowym projekcie architekci poprosili mnie o zmianę częstotliwości na „jedna kompilacja co 15 minut” i po prostu nie rozumiem, dlaczego byłby to dobry powód kontra „ opierając się na każdym zatwierdzeniu ".

Po pierwsze, kilka szczegółów:

• Projekt Objective-C (iOS 5)
• 10 programistów
• każda kompilacja zajmuje ~ 1 min i obejmuje kompilację i testy jednostkowe.
• Serwer integracyjny to Mac Mini, więc moc obliczeniowa nie jest tak naprawdę problemem
  • używamy Jenkinsa z wtyczką XCode

Moje argumenty były takie, że jeśli budujesz przy każdym zatwierdzeniu, możesz teraz zobaczyć, co poszło nie tak, i bezpośrednio poprawić swoje błędy, nie przeszkadzając innym deweloperom zbyt często. Ponadto nasz tester jest mniej przeszkadzany w ten sposób błędami UT. Argumentował, że deweloperzy zostaną zalewani wiadomościami „z błędami kompilacji” (co nie jest do końca prawdą, ponieważ Jenkins można skonfigurować tak, aby wysyłał pocztę tylko dla pierwszej zepsutej kompilacji) i że metryki nie można poprawnie wykonać, jeśli częstotliwość kompilacji jest zbyt wysoki.

Jakie jest twoje zdanie na ten temat?

Szybka awaria jest dobrą zasadą - im wcześniej dowiesz się, że kompilacja jest zepsuta, tym szybciej można zidentyfikować przestępstwo i naprawić kompilację.

Opieranie się na każdym zatwierdzeniu jest właściwą rzeczą.

Budowanie co 15 minut może być bezcelowe, jeśli projekt ma dużą liczbę zatwierdzeń w takim przedziale czasowym - śledzenie nieprawidłowego zatwierdzenia potrwa dłużej i może być trudne do ustalenia (jedna może być również w sytuacji, gdy wiele zatwierdzeń ma różne rzeczy, które: przerwać kompilację). Istnieje również możliwość, że w spokojnych porach (w nocy?) Odbudujesz, chociaż nie wprowadzono żadnych zmian.

Jeśli kompilacja psuje się tak często, że stanowi problem, odpowiedz na nią, aby ponownie wyszkolić zespół, jak ważne jest nie przerywanie kompilacji, oraz w technikach, które zapewnią, że tak się nie stanie (częste pobrania, sprawdzanie tańca, kompilowanie i uruchamianie testów jednostkowych lokalnie itp ...).

Kompilacja co 15 minut nie ma dosłownie sensu, jeśli nic się nie zmieniło. Ale równie dobrze, nie ma wady, afaik, Jenkins będzie wysyłał e-mail tylko w przypadku niepowodzenia, a następnie sukcesu, a nie wszystkiego pomiędzy (np. 10 nie powiedzie się).

Robimy to przy każdym zatwierdzeniu. Jednak sondujemy repozytorium co piętnaście minut i sprawdzamy, czy nie ma zmian, być może o to mówią koledzy.

Oczekujesz, że twój 10 programistów popełnia więcej niż raz na piętnaście minut? To brzmi jak raczej wysoka ocena. 10 dev oznacza, że ​​po każdych 150 minutach ta sama osoba ponownie się angażuje, czyli 2,5 godziny. Tak więc w twoim przeciętnym dniu każdy programista popełnia 3 razy. Osobiście robię jedno zobowiązanie ~ 2 dni ... czasem więcej, czasem mniej.

Będzie zalewać programistom więcej poczty, jeśli tylko co 15 minut. Jest tak, ponieważ nie wiadomo na pewno, kto złamał kompilację, a tym samym wysyła więcej osób.

Jeśli chodzi o metryki, jeśli to naprawdę problem - czego nie mogę powiedzieć, ponieważ nie wiem, z którymi metrykami sądzą, że jest problem - zawsze możesz podjąć inną pracę w celu zebrania metryk.

Być może zasugerowano wymóg „buduj najwyżej raz na 15 minut”. Może to mieć sens w przypadku projektów z bardzo częstą aktywnością zatwierdzania (tj. Wielokrotnymi zatwierdzeniami w ciągu kilku minut) i być może długim czasem kompilacji. Oczywiście zależy to również od sposobu użycia kompilacji. Dla testerów uzyskanie wielu kompilacji w ciągu 15 minut może być nieco mylące ...

Ale zgadzam się, że nie ma sensu budować, jeśli nic się nie zmieniło.

Niektórzy deweloperzy chcą mieć możliwość wykonywania zatwierdzeń w taki sposób, aby pliki należące do jednej zmiany funkcjonalnej nie były zatwierdzane w jednej, atomowej procedurze. Potrzebują dwóch lub trzech minut na wykonanie „logicznego zatwierdzenia”, które składa się z niektórych „fizycznych zatwierdzeń”. Zazwyczaj ma to miejsce, gdy deweloperzy bezpośrednio przypisują się do centralnego repozytorium, nie używając DVCS.

W takich przypadkach dobrym pomysłem może być pozostawienie serwera CI trochę czasu po ostatnim zatwierdzeniu przed rozpoczęciem nowej kompilacji. Ale 15 minut wydaje się być bardzo wysoką liczbą, 5 minut lub mniej powinno wystarczyć.

Lub, lepiej (!), Spróbuj poprowadzić swoich deweloperów do pracy tylko w małych porcjach, tylko jedna rzecz na raz, co znacznie ułatwi wykonywanie tylko „funkcjonalnie kompletnych” fizycznych zmian. Wtedy kompilacja po każdym zatwierdzeniu zadziała bezsensownie.

Nawet jeśli skonfigurowałeś Jenkinsa, aby opierał się na zatwierdzeniu kontroli źródła w projekcie lub którejkolwiek z jego zależności, nie uniemożliwia to deweloperowi wdrożenia w repozytorium artefaktów bez uprzedniej kontroli źródła. Jeśli wdrożą nieskoordynowaną zmianę interfejsu API lub błąd w zależności od repozytorium artefaktów, może to spowodować uszkodzenie kompilacji bez uruchamiania zadania Jenkins. Osobiście chciałbym wiedzieć o tym jak najszybciej.

Idealnie byłoby zbudować dla każdego zatwierdzenia, a także zgodnie z harmonogramem, aby sprawdzić sytuacje, które właśnie opisałem. Oznaczałoby to koncepcyjnie, że budujesz co najmniej raz na 15 minut .

Jeśli masz skonfigurowane zadania Jenkins do uruchamiania na artefaktach zależności (a jeśli wykonasz ... Bravo), możesz przetestować zaplanowaną kompilację, jeśli testy jednostkowe są solidne (co oznacza, że ​​nie testują zależności) i twoją testy integracyjne / funkcjonalne nie są częścią zadania Jenkins.

Jeśli chodzi o problem z „zalewaniem pocztą e-mail”, powiadam się, że zalanie e-mailem uszkodzonej wersji jest dobrą rzeczą. Upewnij się, że zmusisz programistów do odpowiedzi na wiadomość e-mail z opisem, a zobaczysz, że Twoje zepsute wersje spadają, zaufaj mi.

Powiedziałeś, że nie rozumiesz ich uzasadnienia, więc musisz ich zapytać. Nie tylko zgadnij, czego chcą i spróbuj to zaimplementować, a na pewno nie po prostu zrealizuj to, o co prosili, nie rozumiejąc, dlaczego o to poprosili.

To powiedziawszy, aby odpowiedzieć na ogólne pytanie, zależy od stosowanej filozofii rozwoju. Jeśli oczekuje się, że każde zatwierdzenie zadziała, każde zatwierdzenie powinno zostać przetestowane. Jeśli używasz DVCS z filozofią, że każde wypychanie powinno działać, przetestuj każde wypychanie.

Ogólnie rzecz biorąc, lepiej powiedzieć ludziom coś, czego nie wiedzą, niż powtórzyć to, co wiedzą. Na przykład, jeśli chcą zmniejszyć liczbę otrzymywanych nadmiarowych wiadomości e-mail, dostosuj ustawienia e-mail, a nie częstotliwość kompilacji.