A Datadog új eszközökkel gyorsítaná és olcsóbbá tenné a CI/CD-t

A lassú pipeline-ok okait is megmutatja

A Datadog október 6-án bemutatott megoldása a platform-, fejlesztői élményért felelős és DevOps-csapatokat célozza. A vállalat szerint az AI-támogatott fejlesztés felgyorsíthatja a kód előállítását, ez azonban csak akkor javítja ténylegesen a szállítási sebességet, ha a folyamatos integrációs és szállítási rendszer, vagyis a CI/CD is képes lépést tartani a megnövekedett változásszámmal.

A több pull request több buildet, tesztet és pipeline-futtatást jelent. A CI/CD Optimization a futási időt, a várakozási időt, a hibaarányt és a megbízhatósági trendeket követi több CI-környezetben. Az egyes futtatásoknál a csapatok megvizsgálhatják, mely szakaszok és feladatok növelik a teljes időt, majd ezeket összekapcsolhatják a kapcsolódó commitokkal, hibákkal, naplókkal, futtatókkal és infrastruktúramérőszámokkal.

Ez segíthet megkülönböztetni a futtatókapacitás hiányából eredő várakozást a ténylegesen lelassult feladatoktól. A Datadog szerint így a csapatok nem feltétlenül több futtató hozzáadásával kezelik a problémát, hanem megkereshetik a regresszió mögött álló kód-, függőség-, teszt- vagy infrastruktúraváltozást. A CI/CD- és tesztmonitorok a pipeline-ok vagy feladatok romlásakor is riaszthatnak.

A Datadog ügyfelei közül a Betterment az átlagos buildidőt közel 40 percről 10 perc alá csökkentette, a The Browser Company pedig 50 százalékkal rövidítette a CI-pipeline idejét.

A hibás tesztek kevesebb fennakadást okozhatnak

A gyors pipeline önmagában nem sokat ér, ha a fejlesztők nem bíznak az eredményében. A véletlenszerűen hibázó, úgynevezett flaky tesztek érvényes buildet is sikertelenné tehetnek, ami újrafuttatást és külön vizsgálatot igényel.

A CI/CD Optimization Flaky Management funkciója a flaky teszteket olyan mutatók mellett jeleníti meg, mint a pipeline-hibák, a CI-ben elvesztegetett idő és a hibaarány. Az Auto Test Retries beállítható számú alkalommal automatikusan újrapróbálja a sikertelen teszteket, és leáll, amikor a teszt sikerül vagy elfogynak a próbálkozások.

Az Early Flake Detection és a PR Gates a már ismert vagy újonnan megjelenő flaky tesztek kezelését támogatja. A Datadog leírása szerint az automatikus újrapróbálás az azonnali fennakadást mérsékli, a szabályok megakadályozhatják, hogy ismert hibák ismételten blokkoljanak más változtatásokat, az észlelés pedig segíthet megakadályozni a problémaállomány növekedését.

A Flaky Management Explorer a hibák pipeline-szintű hatását is követi, többek között a flaky tesztek okozta hibákat, az elvesztett CI-időt, az automatikus újrapróbálásokkal megmentett pipeline-okat és a tesztfuttatási fejlesztések révén megtakarított időt.

Kevesebb felesleges teszt, hatékonyabb párhuzamosítás

A fejlesztés gyorsulásával több változást kell feldolgoznia a CI-nek, de a nagyobb futtatóflotta önmagában nem csökkenti a szükségtelen munkát. A Test Impact Analysis a teszteket az általuk lefedett kódhoz rendeli, majd a változás alapján meghatározza, mely tesztek érintettek. A nem releváns tesztek kihagyhatók, így rövidülhet a visszajelzési idő és csökkenhet a felhasznált számítási kapacitás.

A Datadog példája szerint egy kizárólag README-fájlt módosító pull request esetében előfordulhat, hogy nincs szükség az alkalmazás tesztjeinek futtatására. A teljes tesztcsomag ilyenkor úgy növelheti a CI-időt, hogy közben nem ellenőrzi a módosított alkalmazáskódot, és független flaky hibáknak is kiteheti a buildet.

A Test Parallelization a szükséges teszteket várható futási idejük alapján osztja szét. A Datadog szerint a rendszer megbecsüli az optimális CI-munkások számát, majd úgy bontja fel a teszteket, hogy a validálás a lehető leggyorsabban és legkisebb költséggel fejeződjön be. A vállalat szerint a kevesebb és hatékonyabban végrehajtott munka révén ugyanaz a futtatóflotta több változást dolgozhat fel, miközben a fejlesztési volumen növekedése nem feltétlenül jár azonos arányú CI- és számításikapacitás-költséggel.