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ę.)