ghiduri
Nu mai reîncercați testele scazute
Reîncercările automate transformă o eroare reală într-una intermitentă și antrenează-ți echipa să nu aibă încredere în fiecare eșec.
{autor} · {rol} · {data} · {minute} {minuteLabel}
Reîncercările testelor generale sunt una dintre acele remedieri care rezolvă simptomul atât de eficient încât boala devine permanentă.
Ce fac de fapt reîncercările
Un test care eșuează 20% din timp și este reîncercat de trei ori eșuează vizibil în mai puțin de 1% din timp. Bug-ul este încă acolo. Acum este în producție, unde se întâmplă și în 20% din timp.
Ce să faci în schimb
- Urmăriți rata de eșec pentru fiecare test, astfel încât să știți care teste sunt de fapt scazute
- Puneți în carantină cei mai mari infractori într-un loc de muncă care nu blochează - fuziuni vizibile, dar fără blocare
- Remediați cauzele fundamentale: dispozitive partajate, ceasuri reale, aleatoriu nesemânțat, coliziuni de porturi, dependență de ordinea de testare
- Reîncercați operațiunile de rețea, care sunt cu adevărat nesigure. Nu reîncercați afirmațiile.
Următorul tău build poate fi de două ori mai rapid, la jumătate de preț
Începe gratuit. Plecarea înseamnă aceeași linie, iar acel diff îl publicăm și noi.
Similar
CI atunci când colegii tăi sunt agențiAgenții de codare AI forțează mult mai des decât oamenii. Iată cum modifică proiectarea conductei și controlul costurilor.De ce publicăm instrucțiuni pentru plecareFiecare pagină de migrare de pe acest site include diferența de a migra înapoi. Iată raționamentul.Ce am învățat gestionând un milion de locuri de muncă CITimpul în coadă, comportamentul în cache, dimensionarea corectă și modurile de eșec care apar doar la scară.Docker Limitele ratei hub sunt o problemă CI, nu o problemă DockerTragerile anonime sunt limitate la rate pe IP, iar alergătorii CI partajează IP-uri. Iată cum să nu mai aflați la 3 dimineața.