Czy istnieje narzędzie CI, które gwarantuje brak regresji na poziomie jakości branży?

10

Tradycyjnie systemy CI wykonują monitorowanie poziomów jakości tylko w gałęzi integracji, wykonując weryfikacje jakości w bazie danych, w której zmiany zostały już zatwierdzone, obserwując regresje i wysyłając powiadomienia o interwencji człowieka.

Ale kiedy te regresje zostaną wykryte, oddział już ma problemy, przynajmniej od czasu rozpoczęcia odpowiedniej weryfikacji jakości i pozostanie w takim stanie (lub nawet gorzej!), Dopóki nie zostaną zidentyfikowani wszyscy sprawcy, popełnione naprawy i nowa weryfikacja jakości potwierdza, że poziom jakości oddziału został przywrócony. Oddział można uznać za zablokowany dla normalnego rozwoju przez cały ten czas.

Czy istnieje narzędzie CI, które może faktycznie zapobiec takim regresjom, które przeprowadzałyby weryfikacje jakości przed zatwierdzeniem i pozwalały zatwierdzać tylko wtedy, gdy baza kodów zaktualizowana o odpowiednie zatwierdzenia przechodziłaby również te weryfikacje jakości przed zatwierdzeniem, gwarantując w ten sposób minimum poziom jakości branży?

Aktualizacja: zakłada się, że odpowiednie zautomatyzowane weryfikacje jakości z odpowiednim zakresem umożliwiające wykrycie odpowiednich regresji są dostępne do wywołania przez narzędzie (narzędzia) CI.

continuous-integration software-recommendation

— Dan Cornilescu
źródło

Zastanawiam się, jak właściwie zrozumieć to pytanie (i własną rekomendację we własnej odpowiedzi). Gdybym zamienił „monitorowanie” na „po faktach” i „zapobieganie” na „prvent im się zdarzyć”, czy to mniej więcej to samo pytanie? A może możesz dodać przykładowy scenariusz wyjaśniający różnicę?

— Pierre.Vriens

@ Pierre.Vriens Czy to jest lepsze?

— Dan Cornilescu

6

O ile mi wiadomo, szukasz narzędzia, które odrzuci zatwierdzenia, które przerywają kompilację - narzędzie CI prawdopodobnie nie będzie w stanie zapobiec regresjom poprzez naprawienie kodu, ale może powstrzymać cię przed dodaniem złego kodu do repozytorium.

Atlassian ma kilka interesujących zastosowań haków Git :

Haki do odbioru wstępnego po stronie serwera są szczególnie potężnym uzupełnieniem ciągłej integracji, ponieważ mogą uniemożliwić programistom wypychanie kodu do nadrzędnego, chyba że kod spełnia określone warunki - na przykład elitarni strażnicy ninja, chroniąc go przed złym kodem.

Jeśli korzystasz z Git, haki są bardzo potężne (i są podobne haki dla SVN , Mercurial i innych systemów kontroli wersji), i może być przydatne, aby użyć ich do uruchomienia kontroli przed zatwierdzeniem.

Dokumentacja Gita zawiera stronę dotyczącą tworzenia haka do odrzucania wypychań, jeśli nie spełniają one określonych kryteriów, które można łatwo dostosować do tego przypadku użycia.

Jednak wiele osób twierdzi, że odrzucanie zatwierdzeń jest złym pomysłem dla featuregałęzi - po prostu marnujesz czas na walkę z systemem CI, gdy kompilacja z jakiegoś powodu się psuje, zamiast naprawiać błąd.

W masteroddziale sensowne może być odrzucenie zepsutych scaleń, ponieważ możesz chcieć mieć pewność, że zawsze się kompiluje. Dla featurebranży, to będzie nieuchronnie złamać rzeczy, a ponieważ kod nie trafią do produkcji teraz , to ma większy sens tylko ostrzec, niż faktycznie odrzucić popełnić zupełnie.

— Aurora0001
źródło

Cóż, jaki jest dobry obraz SW, który buduje, ale czy DOA może być testowane? Deweloperzy nie mogą testować swoich zmian kodu, nawet jeśli budują, więc byliby tak samo zablokowani. Ogólnie rzecz biorąc, odrzucam zatwierdzanie na wszystko, co nie przejdzie minimalnej kontroli jakości, wybraną przez zrównoważenie 2 sprzecznych wymagań: tak wysokie, jak to możliwe, aby zmaksymalizować liczbę programistów chronionych przed blokowaniem i tak niskie, jak to możliwe, aby opóźnienia weryfikacji jakości nie powodowały za bardzo spowalnia proces.

— Dan Cornilescu,

Przykładem tego może być model żądania ściągnięcia, w którym można wprowadzić pewne ograniczenia dotyczące możliwości połączenia żądania ściągnięcia. Na przykład, my (moja firma) używa Atlassian Bitbucket Server i istnieją opcje wymagające co najmniej N liczby zatwierdzeń i X liczby przekazujących kompilacji dla danego oddziału, zanim zezwolenie na scalenie będzie możliwe. To absolutnie tego nie odrzuca. Ale zapobiega przypadkowemu scaleniu, gdy testy zakończą się niepowodzeniem lub inne oczy jeszcze nie zobaczą kodu.

— Andy Shinn,

@AndyShinn: Tak, uważam to za bardzo przydatne - GitHub oferuje również chronione gałęzie i kontrole żądań ściągania , które często są pomocne.

— Aurora0001

1

Jednym z argumentów za dopuszczeniem zepsutego kodu w gałęziach funkcji jest to, że umożliwia deweloperom wypychanie kodu, nad którym pracują, do repozytorium, nawet jeśli nie jest jeszcze całkiem gotowy. Może to być przydatne do dzielenia się kodem z innymi we wczesnych przeglądach kodu / architektury, zanim wszystko będzie gotowe, pomoc w debugowaniu problemów lub dla kogoś, kto wyjeżdża na wakacje, aby oddać częściowo wykonaną pracę, aby inni mogli się do niej dostać. W przypadku gałęzi funkcji wstawiałbym tylko takie rzeczy, jak strzępki i haczyki przed zatwierdzeniem.

— bradym

2

Żadne narzędzie nie może zagwarantować braku regresji - zależy to znacznie bardziej od twoich testów niż narzędzie je wykonujące. Możesz jednak pomóc w zapobieganiu przechwyceniu regresji, które zostaną przechwycone, w gałęzi integracji. Możesz to zrobić za pomocą przechwytywania poprzedzającego zatwierdzenie, ale często jest to łatwiejsze przy żądaniach ściągania (które, mam nadzieję, już używasz do recenzowania kodu równorzędnego).

Jeśli oddział jest aktualny w swoim segmencie wydobywczym (do którego łączy się PR), a jego testy zakończą się pomyślnie, to nadal przejdą po scaleniu; stan gałęzi docelowej po scaleniu będzie zgodny ze stanem gałęzi źródłowej przed scaleniem.

Zasadniczo nie jest szczególnie trudne (w zależności od użytych narzędzi) wskazanie zarówno, czy gałąź źródłowa w PR jest zgodna z celem, jak i czy ma pomyślną kompilację CI. Możesz użyć tego jako wymogu (według zasad i / lub wymuszonego w oprogramowaniu) do scalenia żądania ściągnięcia.

— Adrian
źródło

„Jeśli oddział jest aktualny w swoim segmencie wydobywczym (do którego łączy się PR), a jego testy zakończą się pomyślnie, to nadal przejdą po scaleniu” - Dlaczego? Scalanie jest nieciągłością, niesie ze sobą nieznane. Jak konflikty - kod może nawet nie zostać skompilowany, dopóki nie zostanie rozwiązany. Ci potrzebne do przeprowadzenia testów i potwierdzić, że przechodzą one do każdej seryjnej oddziału. Powiedziałbym nawet o przewijaniu do przodu, jeśli chcesz grać bezpiecznie. Zobacz apartsw.com/insights/2016/11/16/…

— Dan Cornilescu,

Tak, taka gwarancja jest możliwa, sprawdź moją odpowiedź. Cóż, może powinienem wyjaśnić: przez regresję mam na myśli wyniki gorsze niż wyniki linii podstawowej (i ignorując możliwość fałszywych trafień, należy się nimi zająć, ponieważ mogą one wypaczyć linię podstawową, wykoleić całość i wymagać interwencji człowieka). Przerywane fałszywe negatywy to tylko uciążliwość, spowalniająca wszystko, ale można sobie z tym poradzić.

— Dan Cornilescu,

Nie możesz zagwarantować żadnych regresji, możesz jedynie zagwarantować brak wykrytych regresji. Jeśli zmiana powoduje regresję, której nie przechwycił test, jest to regresja, o której narzędzie CI nie może dać żadnych gwarancji. I chociaż scalenie dwóch zestawów zmian niesie ze sobą niewiadome, możesz to zrobić w gałęzi funkcji (poprzez połączenie w górę) przed scaleniem w innym kierunku. Jeśli źródło jest aktualne z celem, jest to zwykłe scalenie (szybkie przewijanie do przodu), a następnie stan docelowy będzie identyczny ze stanem źródłowym przed scaleniem, dlatego jeśli testy przeszły wcześniej, przejdą później.

— Adrian

Dzielenie włosów. Narzędzie CI można skonfigurować za pomocą testu do wykrywania, a tym samym ochrony przed regresją, na której Ci zależy. Nie będę się zbytnio kłócił o fuzje - moim celem jest uniknięcie ich w jak największym stopniu, to po prostu kłopoty w ogóle :)

— Dan Cornilescu

Chodzi mi o to, że to nie narzędzie CI oferuje tę ochronę, to Ty, pisząc testy. Narzędzie CI nie może zapewnić żadnych gwarancji poza testami, które udostępniasz.

— Adrian

1

Prawdziwe narzędzia do ciągłej integracji (w przeciwieństwie do ciągłego testowania), takie jak Reitveld i Zuul, mogą pomóc, choć są one tak dobre, jak pisane testy i recenzje.

— koderanger
źródło

Ale Reitveld wydaje się być narzędziem do weryfikacji kodu opartym na współpracy, a nie narzędziem CI, czy coś mi brakuje? Właśnie na to patrzyłem: github.com/rietveld-codereview/rietveld

— Dan Cornilescu

Zuul wydaje się być spokrewniony, przestudiuję go bliżej.

— Dan Cornilescu

Nie przeprowadza testów, ale obsługuje niektóre aspekty zarządzania oddziałami, działając jako system strażników, co jest najlepszym rozwiązaniem, aby powstrzymać zły kod przed dostaniem się przez zablokowanie scalania.

— coderanger

Rozumiem, co masz na myśli. Cóż, może pomóc w ogólnej jakości kodu, ale sam w sobie nie daje żadnej gwarancji. Dwie doskonale dobre zmiany, które niezależnie przechodzą wszystkie weryfikacje kontroli jakości, mogą nadal powodować awarie, gdy spotykają się w oddziale.

— Dan Cornilescu

1

Użyj GitLAB, możesz ustawić w ustawieniach projektu, aby zezwalać na scalanie tylko po pomyślnym zakończeniu potoku, dzięki czemu możesz mieć naprawdę ciągłą integrację, łącząc to z dodawaniem kontroli jakości do listy zatwierdzeń scalania i za pomocą środowisk dynamicznych, możesz mieć gwarancję jakości zanim połączysz się z mistrzem.

— Danny Goossen
źródło

Działa to, ale tylko wtedy, gdy nie zezwolisz na 2. scalenie na rozpoczęcie kontroli jakości przed zakończeniem poprzedniego, w przeciwnym razie 2. scalenie nie zobaczy pierwszego, pozostawiając miejsce na regresje. Innymi słowy, połączenia (w tym ich kontrole jakości) muszą być całkowicie zserializowane, co nie jest skalowalne dla dużych zespołów.

— Dan Cornilescu,

0

ApartCI to system CI zaprojektowany dokładnie w celu zapobiegania regresji, gwarantując tym samym płaski lub podnoszący poziom jakości oddział. Nadal w wersji beta.

Organizuje scentralizowane weryfikacje przed zatwierdzeniem w taki sposób, aby zapewnić, że zmiana zostanie zatwierdzona dopiero po jej zweryfikowaniu, wraz ze wszystkimi innymi zmianami dokonanymi przed nią, w celu osiągnięcia lub przekroczenia najnowszego poziomu jakości oddziału.

Jest to kluczowa różnica w porównaniu z tradycyjnymi weryfikacjami przed zatwierdzeniem opartymi na programistach, często wykonywanymi równolegle, co pozostawia miejsce na regresje spowodowane przez zakłócające zmiany, które nigdy nie były wspólnie testowane.

Narzędzie zaprojektowano również w celu łatwego skalowania - jest w stanie utrzymać bardzo wysokie wskaźniki nadchodzących zmian kandydujących i wspierać setki / 1000 programistów pracujących w tej samej gałęzi integracji.

Oświadczenie: Jestem autorem narzędzia i założycielem firmy, która go oferuje. Przepraszamy za reklamę.

— Dan Cornilescu
źródło

Dobrze, że dodałeś oświadczenie, ale osobiście rozważam zadawanie pytań i samodzielne udzielanie odpowiedzi poprzez promowanie własnej firmy lub produktów jako formy spamu.

— Święto

Zadałem pytanie dotyczące meta, czy jest to dozwolone, czy nie: meta.devops.stackexchange.com/q/59

— THelper

SnapCI też to zrobił. ROZERWAĆ.

— paul_h

@paul_h, chyba że coś mi brakuje SnapCI i jego zalecany zamiennik GoCD są oparte na weryfikacjach po zatwierdzeniu (wyzwalanych przez odpytywanie SCM), więc nadal są tylko do monitorowania. Z wyjątkiem może kontroli PR, ale o ile kontrole te nie zostaną całkowicie zserializowane, mogą jedynie zmniejszyć częstość występowania regresji, ale nie wyeliminować ich całkowicie.

— Dan Cornilescu,

Dan, nie sondując nie, haczyki. I do krótkotrwałej gałęzi PR, która nie została jeszcze połączona z trunk / master - trunkbaseddevelopment.com/game-changers/…

— paul_h