Færri uppfærslubeiðnir — flokkaðu háða pakka áður en vélmennið ræsir

Flokkaðu sjálfvirkar pakkauppfærslur eftir því hvaða breytingar teymið getur prófað og samþykkt saman. Láttu skylda pakka fara í sömu beiðni, haltu aðalútgáfum í sérstakri yfirferð og settu hámark á opnar beiðnir um venjulegar útgáfuuppfærslur. Gættu þess um leið að viðgerðir vegna þekktra veikleika hafi virkt, aðgreint flæði.

Í GitHub-verkefni með fáa pakkastjóra er Dependabot oft einföld byrjun. Renovate hentar þegar teymið vill nýta tilbúna pakkahópa, setja ítarlegri reglur eða vinnur á öðru studdu hýsingarkerfi. Í fjölpakkasafni ræður samþykktarferlið mestu: sameinaðu uppfærslur þvert á möppur aðeins þegar sömu prófanir og sömu ábyrgðaraðilar ná yfir breytingarnar.

Veldu vélmenni eftir hýsingu og verkefnaskipan

Ef verkefnið er á GitHub og pakkaskrárnar eru á fáum stöðum skaltu fyrst kanna hvort Dependabot nægi. Þar má skilgreina möppur, uppfærslutíðni, hópa og hámark opinna beiðna án þess að reka sérstakt uppfærsluvélmenni. Ef verkefnið er á GitLab eða öðrum hýsingarkerfum sem Renovate styður, eða ef teymið vill byggja á tilbúnum hópum, er Renovate eðlilegri leið.

Samanburður Renovate lýsir þessum mun á hýsingu og tilbúnum hópum, en fullyrðir líka að Dependabot geti ekki sameinað uppfærslu sama pakka úr mörgum möppum. Núverandi valkostayfirlit GitHub skilgreinir hins vegar group-by: dependency-name fyrir einmitt það tilvik: möppurnar þurfa að nota sama pakkastjóra, reglan á við útgáfuuppfærslur og ósamrýmanleg útgáfuskilyrði geta leitt til aðskildra beiðna.

Fjölpakkasafn kallar því ekki sjálfkrafa á nýtt verkfæri. Ef sami npm-pakki er notaður í nokkrum undirverkefnum sem fara saman í prófanir og útgáfu getur sameinuð beiðni sparað endurtekna yfirferð. Ef undirverkefnin hafa ólíka eigendur eða útgáfudaga er skýrara að halda breytingunum aðskildum, þótt nafn pakkans sé hið sama.

Afmarkaðu hópinn áður en þú stillir tíðnina

Hópur ætti að svara einni yfirferðarspurningu: geta sömu aðilar samþykkt allar breytingarnar eftir sömu prófanir? Pakkar úr sömu umgjörð eru oft skýrara viðfangsefni en allir þróunarpakkar verkefnisins í einni beiðni. Víðtækur hópur getur fækkað beiðnum en gert erfiðara að finna hvaða breyting olli bilun í prófunum.

Haltu þremur stillingum aðgreindum. Flokkun ræður því hvað fer saman, áætlun hvenær venjulegar uppfærslur koma til vinnslu og hámark hversu margar slíkar beiðnir geta verið opnar samtímis. Vikuleg yfirferð ein og sér sameinar ekki skyldar breytingar; lágmark á opnum beiðnum leysir heldur ekki upp safn beiðna sem enginn hefur tíma til að samþykkja.

Skilyrt byrjunarregla fyrir teymi sem notar @angular-pakka væri að hópa minniháttar uppfærslur og plástursuppfærslur þeirrar pakkafjölskyldu. Láttu aðalútgáfur birtast sér, því þær geta kallað á breytingar í forritskóða eða prófunum. Þetta er ákvörðun um yfirferð, ekki loforð um að allar breytingar innan minni útgáfu séu áhættulausar.

Dependabot: ein afmörkuð regla fyrir npm

Fyrir skilyrt npm-verkefni með pakkaskrá í rót má vista eftirfarandi í .github/dependabot.yml. Dæmið er á þéttu flæðissniði YAML; breyttu slóð, pakkamynstri og hámarki eftir raunverulegu verkefni. {"version":2,"updates":[{"package-ecosystem":"npm","directory":"/","schedule":{"interval":"weekly"},"open-pull-requests-limit":3,"groups":{"angular":{"patterns":["@angular/*"],"update-types":["minor","patch"]}}}]}

Reglan sameinar samsvarandi minniháttar uppfærslur og plástursuppfærslur í hópinn angular. Aðalútgáfur og pakkar utan mynstursins geta enn fengið eigin beiðnir. open-pull-requests-limit takmarkar aðeins opnar beiðnir um útgáfuuppfærslur; öryggisbeiðnir teljast hvorki með í hámarkinu né stöðvast vegna þess.

Rótarslóðin / vísar að pakkaskrám í rót verkefnisins. Ef skrárnar eru í undirverkefnum þarf að skilgreina réttar slóðir með directory eða directories. Fyrir sameiginlega uppfærslu sama pakka í fleiri möppum má bæta group-by: dependency-name við hópreglu, að uppfylltum skilyrðunum um sama pakkastjóra og samrýmanleg útgáfuskilyrði.

Renovate: sérregla ofan á tilbúna hópa

Stillingaleiðbeiningar Renovate skilgreina packageRules fyrir val á pökkum og tegundum uppfærslna, prConcurrentLimit fyrir samtímis opnar venjulegar beiðnir og schedule fyrir leyfilega tíma til að stofna greinar. Áætlunin ræsir Renovate ekki sjálf; of þröngur tímagluggi getur því valdið því að keyrsla missi af honum.

Skilyrt dæmi fyrir sama npm-verkefni í renovate.json er: {"extends":["config:recommended"],"timezone":"Atlantic/Reykjavik","schedule":["* * * * 1"],"prConcurrentLimit":3,"packageRules":[{"matchPackageNames":["@angular/**"],"matchUpdateTypes":["minor","patch"],"groupName":"Angular uppfærslur"}]}

Í þessu dæmi er mánudagur opinn fyrir venjulegar uppfærslugreinar samkvæmt tímabelti Reykjavíkur, og sérreglan hópar tilgreinda @angular-pakka þegar uppfærslan er minniháttar eða plástur. config:recommended inniheldur einnig tilbúna hópa; skoðaðu hvaða beiðnir sú grunnstilling myndar áður en þú bætir við fleiri reglum. Aðalútgáfur eru sjálfgefið aðgreindar frá minni uppfærslum í Renovate, en tilbúnar hópreglur geta enn sameinað skyldar aðalútgáfur sín á milli.

Öryggisleiðin og síðasta yfirferð stillingarinnar

Í GitHub þarf að virkja viðvaranir og sjálfvirkar öryggisuppfærslur fyrir Dependabot sérstaklega; skrá fyrir venjulegar útgáfuuppfærslur kemur ekki í stað þeirrar stillingar. Renovate getur á GitHub búið til viðgerðarbeiðnir út frá veikleikaviðvörunum þegar dependency graph og Dependabot alerts eru virk og vélmennið hefur nauðsynlegan lesaðgang. Slíkar Renovate-beiðnir fara sjálfgefið fram hjá venjulegri tímaáætlun og almennu hámarki opinna beiðna.

Á öðrum hýsingarkerfum skaltu staðfesta hvaðan tilkynningar um veikleika koma og hver tekur við þeim. Sá þáttur er aðskilinn frá því hvort venjulegar útgáfuuppfærslur séu hópaðar. Lágt hámark og vikulegur gluggi gagnast aðeins ef viðgerð vegna þekkts veikleika getur áfram komist til yfirferðar.

• Staðfestu að skilgreindar möppur nái yfir þær pakkaskrár sem teymið ætlar að uppfæra.
• Berðu hvern hóp saman við prófanir og ábyrgð: sama beiðni á að eiga skýran samþykkjanda.
• Hafðu aðalútgáfur sýnilegar og kannaðu hvort tilbúnir Renovate-hópar nái þegar yfir sömu pakka.
• Tryggðu að viðvaranir um veikleika séu virkar og að öryggisbeiðnir hafi ábyrgðaraðila utan venjulegs yfirferðarglugga.
• Skoðaðu fyrstu beiðnirnar eftir virkjun. Ef óskyldar breytingar lenda saman skaltu þrengja mynstrið; ef venjulegar beiðnir sitja fastar við hámarkið þarf teymið að laga yfirferðina eða breyta fjöldanum.