Klíčové poznatky
- Psaní kódu již není pomalá část. Za 31 dní jsme sloučili 473 pull requestů do naší hlavní větve. 130 z nich potřebovalo, aby se někdo vrátil a sloučil hlavní větev do větve, celkem 239 merge commitů a 238 z nich vytvořila osoba.
- PR, které to potřebovaly, trvaly medián 44 hodin od otevření do sloučení. Ty, které ne, trvaly 2 hodiny. Ze 60 PR, která zůstala otevřená déle než tři dny, 51 potřebovalo alespoň jedno sloučení hlavní větve.
- babysit-pr rozděluje práci v jednom štítku:
LGTM, “looks good to me” (vypadá mi to dobře), který autor přidá, když je práce hotová. Před ním dovednost udržuje agenta na PR, dokud není CI zelený a na každého review bota je odpověděno. Po něm pracovní postup GitHub Actions udržuje PR slučitelný, dokud jej osoba neslučuje, a přidáRTM, “ready to merge” (připraven na sloučení), jakmile jej schválí někdo jiný než autor. - Pracovní postup nikdy neslučuje, nikdy nezavírá a nikdy nemění řádek, který napsal autor. Konflikt, který nemůže vyřešit kolem autorova kódu, jde zpět autorovi jako
REWORK. - Dovednost je veřejná, s MIT licencí: babysit-pr-skill on GitHub , se skriptem sledovače a návrhem pracovního postupu. Sám pracovní postup se stále spouští v suchém režimu na našem repozitáři a níže vysvětlím proč.
Proč zastaralé pull requesty zastarávají?
Psaní kódu přestalo být pomalá část. S vzorem architekta a agenty dělajícími většinu psaní, naš repozitář přijímá asi 13 commitů denně do hlavní větve. To je dobré pro doručování a špatné pro každý otevřený pull request, protože každý z těch commitů může vložit PR do konfliktu nebo jeho CI zčervenat.
Vytáhl jsem posledních 31 dní sloučených PR, aby viděl, kde se čas strávil.
44 proti 2 není příčina, je to korelace. PR, které zůstane otevřený déle, dá hlavní větvi více času na pohyb pod ním, takže je pravděpodobněji, že potřebuje sloučení. Ale samotné sloučení je skutečná práce, kterou nějaký člověk dělal 239 krát za měsíc. Pět lidí vytvořilo 238 z nich ručně. Jeden PR potřeboval osm sloučení hlavní větve během sedmi dní, kdy byl otevřený.
Samotné schválení bylo rychlé. Jakmile PR dostala své první schválení, medián času do sloučení byla nula hodin. Čekání se stalo předtím: autor skončil, pak PR seděl, dokud si jej recenzent nevzal, a zatímco seděl, hlavní větev se pohybovala. Začali jsme označovat hotová PR LGTM 20. října. Těch 20, které se od té doby sloučily, čekaly medián 38 hodin mezi LGTM a sloučením a jeden ze čtyř čekal více než 78 hodin.
To je mezera, pro kterou je to. Nikdo zde není bezohledný. Autor si myslí, že je hotov, recenzent jej ještě neotevřel a větev se v mezidobí kváší.
Připraveni rozšířit své podnikání?
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Proč neuzavřít zastaralé pull requesty pomocí actions/stale?
Obvyklá odpověď na zastaralé pull requesty je actions/stale : GitHub Action, která přidá štítek zastaralosti na problémy a pull requesty po určitém počtu dní nečinnosti a automaticky je uzavře o několik dní později, pokud někdo nekomentuje nebo netlačí.
To se hodí na pull request, na kterém nikdo nepracuje. Nedělá nic pro ty, které jsme měli. Ty naše byly hotová práce, která zastarala, zatímco čekala na recenzenta, protože hlavní větev se pod nimi pohybovala. Zavřít je znamená vyhodit práci pryč a zastaralý štítek říká autorovi to, co už ví. Co PR potřebuje, je aby někdo sloučil hlavní větev, znovu spustil červenou úlohu CI a udržel ji zelenou, dokud ji osoba neschválí. Takže místo zavírání zastaralých pull requestů je udržujeme slučitelné.
Jak babysit-pr udržuje pull requesty slučitelné
Rozdělení následuje, kdo čeká. Před LGTM je autor stále na PR, obvykle relace agenta, a dovednost udržuje tu relaci při užitečné práci místo aby prohlašovala vítězství, když se kód zkompiluje. Po LGTM se autor pohnul dál, takže práce jde k něčemu, co jej nemusí: pracovnímu postupu, který běží bez ohledu na to, jestli se na něj někdo dívá.
LGTM znamená “looks good to me” (vypadá mi to dobře). Na většině týmů recenzent to říká o něčím jiném kódu. Zde autor to dá na svůj vlastní PR jako štítek, který znamená “Jsem hotov, nic mi už nezbývá dělat”. Je to slovo osoby: agent jej přidá pouze pokud mu bylo řečeno, aby PR předal. Tento štítek je opt-in pro všechno po něm a je to věc, která vývoje udělá pohodlným nechat bota tlačit do své větve.
Přihlaste se k odběru newsletteru
Získejte nejnovější tipy, trendy a nabídky zdarma.
Před LGTM: dovednost Claude Code vede PR do stavu připravenosti
Dovednost začala jako dovednost babysit-pr v Thea Brownova tstack
. Zachoval jsem její sledovač a její hlavní pravidla a změnil jsem, kde se zastaví.
Jeden sledovač na pull request
pr-wait průzkumuje jeden pull request a tiskne jeden řádek na skutečné události: selhala kontrola, všechny kontroly skončily, někdo komentoval nebo recenzoval, hlavní větev se pohybuje pod soubory, které tento PR dotýká, větev zaostala nebo je v konfliktu, PR se sloučila. V Claude Code běží pod nástrojem Monitor, takže každý řádek probuzí agenta jednou. Událost, která nepotřebuje žádnou akci, skončí tah bez zprávy. “Stále čekám” není novinka a agent, který to říká padesátkrát, zaplní svůj vlastní kontext ničím.
Seřadit červenou úlohu CI před dotýkáním se kódu
Existují čtyři druhy červené a pouze jeden je oprava kódu:
- PR ji rozbitou. Opravte ji nejmenší možnou změnou.
- Běhová jednotka selhala. Znovu spusťte selhané úlohy jednou. Druhé selhání na stejné hlavě není selhání.
- Hlavní je červená. Neopravujte hlavní na funkční větvi někoho. Hlasujte to a čekejte.
- Proces je červený, například PR neodkazuje na schválené vydání. To je krok pro osobu.
Agenti ponechaní sami považují všechny čtyři za první a PR si vezme workaround pro test, který je rozbitý na hlavní větvi.
Prokázat zjištění recenze před opravou
Zjištění recenze, které agent přijme, nejprve dostane selhávající test a pak opravu. Zjištění, které odmítne, dostane psaný důvod. Toto je stejné pravidlo jako naše prokázané dovednosti recenze a je to to, co zastaví review boty od řízení PR podle objemu.
Udržet PR velikost jeho cíle
Smyčky recenzí rozrostou PR jeden levný vypadající opravit za čas: ochrana pro hraniční případ, který nikdo nenarazí, test na chování, které se nezměnilo, shim kompatibility. Dovednost opravuje skutečné chyby v zamýšleném případě a odmítá zbytek písemně. Ty hodné se stávají vydáními.
Připravenost je kontrolní seznam
Každá gating úloha CI zelená na aktuální hlavě, každý review bot skončil na této hlavě, nic nečeká na člověka, žádné nevyřešené vlákno, žádný konflikt. Když to drží agent to hlásí a zastaví sledování.
Po LGTM: pracovní postup GitHub Actions řeší konflikty při slučování
Pracovní postup má dvě práce.
Brána rozhoduje, co každý PR potřebuje
Brána je levná: žádný agent, žádné stažení kódu PR. Běží na každém pushnutí do hlavní, každém dokončení CI, každém štítku a recenzi, a každých 30 minut, a jeden GraphQL dotaz jej dá každý otevřený LGTM PR. U každého čistá funkce rozhoduje, co dělat. Přidejte RTM, pokud je schváleno někým jiným než autorem, zelený a bez konfliktů. Nechte jej o pokoji, pokud recenze běží. Znovu spusťte červené CI jednou. Pošlete konflikt nebo CI, které zůstane červené po svém opětovném spuštění, na opravovatele.
Opravující agent sloučí hlavní větev
Opravující agent je práce agenta pro jeden PR na jedné hlavě. Sloučí hlavní do větve bez potvrzení, dá agentovi konfliktní soubory a protokoly selhání a nechá jej upravit pouze konfliktní soubory a soubory, které PR již mění. Pak položí jednu otázku.
Může tento PR přistát bez změny řádku, který napsal jeho autor?
Pokud ano, rozhodnutí je MODERNIZE. Agent vyřeší konflikt kolem autorových řádků, validátor zkontroluje výsledek a pracovní postup tlačí normální merge commit. Pokud ne, protože hlavní smazala funkci, kterou PR upravuje nebo vlastní kód PR selže CI, rozhodnutí je REWORK. Nic se nenahraje, LGTM se sundá a autor dostane komentář s nejmenším přepsáním. Pokud hlavní už dělá to, co dělá PR, rozhodnutí je CLOSE a osoba jej zavře.
Validátor uchovává každý řádek, který napsal autor
Validátor je to, co dělá pravidlo. Odmítá jakékoli sloučení, které zahodí řádek, který PR přidal, nebo řádek, který hlavní přidala do konfliktního souboru. Odmítá úpravy mimo povolené soubory, zbývající značky konfliktů a změny v CI nebo bezpečnostních souborech. Agent, který se pokusí “opravit” kód autora, skončí se štítkem žádajícím člověka, nikdy s pushem. Pracovní postup tlačí bez síly a pouze pokud se větev od začátku pokusu nepohnula. Jeden pokus na hlavu a base, dva na hlavu, tři komentáře na PR za den.
Nikdy neslučuje
RTM, “ready to merge” (připraven na sloučení), je tvrzení brány, že PR má vše, co potřebuje: LGTM autora, schválení od někoho jiného, zelené CI a žádný konflikt. Osoba provádí slučování. To udrželo design malý a to udrželo argument o tom, zda by měl bot slučovat, mimo recenzi.
Co se změní pro autora, recenzenta a kohokoliv, kdo slučuje
Autor řekne hotov jednou. Nevracejí se za tři dny později, aby sloučili hlavní a čekali na CI znovu, a PR agenta se nerozkládá, protože relace, která ji otevřela, skončila.
Recenzent otevře PR, který je zelený a slučitelný na dnešní hlavní, takže jejich schválení je poslední krok a nikoli začátek dalšího kola.
Kterýkoli sloučí z jednoho seznamu. RTM zůstane, jakmile brána to přidá, a pokud hlavní PR rozbitou poté, pracovní postup ji opraví a štítek zůstane.
A autor si udržuje kontrolu nad svým kódem. Nejhorší, co bot může dělat s větví, je přidat merge commit, který validátor zkontroloval řádek po řádku.
Proč náš starý řešitel konfliktů při slučování nikdy neběžel
Měli jsme řešitel konfliktů před tím, než. Detektor našel konfliktní PR a komentoval je a řešitel běžel, když někdo přidal štítek, který jej požaduje. Ve stejném období běžel detektor asi 2500 krát. Řešitel běžel nulakrát.
Nemyslím si, že byl někdo líný. Vývojář, který považuje PR za hotový, se k němu nevrací, aby stiskl tlačítko. Automatizace, která čeká na vyžádání, nebude vyžadována. Proto to začíná z LGTM, moment, kdy autor říká, že je hotov, a dělá zbytek bez nich.
Co ještě nefunguje?
Dvě věci a raději to řeknu zde, než aby si to našel.
Pracovní postup je v suchém spuštění
Jeho brána pouze zaznamenává, co by dělala, dokud proměnná repozitáře neřekne jinak. Než se dostali tak daleko, recenze, která udržuje pouze zjištění, která může prokázat selhávajícím testem, našla v ní jedenáct chyb. Pár je warto vědět, zda si postavíte vlastní. Vyhledávání štítků GitHub zaostává, takže PR, který vrátí, mohl ztratit štítek před sekundami a rozhodnutí musí zkontrolovat živé štítky. “Tato hlava již měla svou re-run” značka napsaná před úspěšným voláním re-run dovolí jednomu neúspěšnému volání API použít jednu re-run hlavy. A kontrola “ztratit žádný řádek”, která nenásleduje přejmenování, vidí každý řádek přejmenovaného souboru jako ztracený.
Běhové jednotky agenta byly dolů
Od 19. října všechny úlohy zaměřené na naše běhové jednotky agenta selhaly, aby dostaly stroj: 406 zrušeno, 24 stále ve frontě, když jsem to zkontroloval. Brána běží jinde a je v pořádku, ale opravitel potřebuje běhovou jednotku agenta a mrtvá vypadá přesně jako tichý den. Nic nefungovalo hlasitě. Úlohy byly zařazeny do fronty a pak zrušeny. Pokud si to postavíte, upozornění na spuštění opravitele, která jsou zařazena do fronty.
Takže výše uvedená čísla jsou předtím obrázek. Právě teď máme 27 otevřených LGTM PR, 7 z nich s červeným CI a žádný s RTM. To jsou čísla, která by se měla změnit, a budu hlášit, co to dělalo.
Jak nainstalovat dovednost babysit-pr
github.com/LivinTribunal/babysit-pr-skill má:
SKILL.md, dovednost, s krátkou sekcí “konfiguruj jednou” pro vaše CI pracovní postupy, review boty a kontroly procesů.scripts/pr-wait, sledovač. Potřebuje Python a ověřenégh.docs/after-lgtm.md, design po-LGTMpracovního postupu: štítky, brána, opravitel, pravidlo, že nikdy nezmění autorovy řádky a jedenáct chyb.
Pracovní postup je design spíše než soubor, který má být zkopírován, protože ten náš běží proti štítkům jedné společnosti, běhovým jednotkám a CI. Postavte si svůj z dokumentu, odešlete jej v režimu pouze protokolu, přečtěte si jeden den jeho rozhodnutí a pak jej zapněte.
Páry s vzorem architekta , který rozhoduje, kdo napíše kód, a grain , který rozhoduje, jak kód vypadá. babysit-pr je to, co se stane poté, co kterýkoli z nich otevře pull request. Pokud ladíte sám agenta, CLAUDE.md A/B test a limit kontextu, který snížil používání tokenů o 17% pokrývají pokyny a náklady.
