A CI nem haszontalan, de a "full coverage" és az energiatakarékosság között alapvető ellentét van. A legkisebb elengedhetetlen teszthalmaz megállapítására kellene törekedni. A normál fejlesztési folyamatban amúgy is szerepel integrációs és egyéb teszt; az ilyen teszteredmények érvényességét kellene adott esetben átmenteni a beolvasztás idejéig. Illetve le kell nyelni, hogy az energiatakarékosság ára néha az, hogy a lefedettség hiányos, és emiatt regressziók vannak.
Megfelelő instrumentálás mellett ezt simán lehetne automatizálni. Ha az összes tesztedről tudod, hogy melyik sorokra fut rá, akkor azt is tudod, hogy a megváltozott kóddal melyik teszteket kell lefuttatni. Nem tudom, hogy csinált-e már valaki ilyet, de az eszközök szerintem rendelkezésre állnak. A kérdés csak az, hogy az extra tooling miatt nem kellene-e ehhez több erőforrás, mint simán lefuttatni az összes tesztet. Unit tesztek egy közepes méretű projecten egyébként sem kellene, hogy néhány másodpercnél tovább fussanak.
Integrációs/E2E tesztek meg soha nem fognak teljes lefedettséget adni a tesztpiramis miatt. Lassabbak is, több erőforrás is kell nekik, ezért inkább ezeket próbálnám ritkábban futtatni.
Ami még fontosabb: végre fel kell ismerni, hogy a CI nem helyettesíti az alapos peer review-t. A github ebben a tekintetben elképesztő károkat okozott a fejlesztési morálban és folyamatokban. [...] A peer review valóban nagyon nehéz, és szűk keresztmetszetet is jelent, de a környezeti lábnyoma elenyésző (etetni, itatni, aludni hagyni kell a reviewer-t). Alapos kódbírálat jó hatékonysággal meg tud fogni regressziókat. Ez valóban lassítja a fejlesztést, de az miért baj? Megint ott vagyunk, hogy"time to market", vagyis a lehető legtöbb $$$ kihúzása egységnyi idő alatt.
A CI nem csak a regressziók csökkentésére jó, lehet vele code stylet, test coverage-t, egyéb nem funkcionális dolgokat ellenőrizni, mindezt szinte valós időben. Így egy PR el sem jut review-ig, amíg a formai követelményeket nem teljesíti. Egy alapos review egy nemtriviális kódon minimum fél óra. Fejlesztőként, ha aznap még dolgozni is akarok, praktikusan nem tudok egy nap 2-3-nál több reviewt csinálni (szerencsére nem is kell). Ha ezen felül még az ilyen apróságokkal is foglalkozni kell, az növeli a review idejét, növeli a visszadobott PR-ek számát, ezáltal növeli a review-k számát. Arról már nem is beszélve, hogy egy gépnek nehezebb ellentmondani, mint egy embernek (pl. ha nem tetszik a code style).