AI-ийн бичсэн кодыг merge хийхээс өмнө долоон шалгалт хий

AI-ийн үүсгэсэн кодыг merge хийхээс өмнө GitHub-ийн AI код шалгах зааварт дурдсан ажлыг долоон шалгалтад нэгтгэж болно: кодыг ажиллуулах, зорилготой нь тулгах, тестийг нягтлах, хамаарлыг шалгах, лицензийг баталгаажуулах, API болон аюулгүй байдлын замыг үзэх, эцэст нь хүнээр зөвшөөрүүлэх. Энэ дараалал нь баг PR бүрт давтаж хэрэглэх шалгах хуудас юм.

Эхлээд автомат шалгалтын үр дүнг авч, дараа нь хүссэн өөрчлөлт үнэхээр зөв хэрэгжсэн эсэхийг diff дээр тогтоо. Шалгалт бүрийн үр дүн сүүлийн commit-д хамаарах ёстой: тест ажилласны дараа код өөрчлөгдсөн бол өмнөх үр дүн шинэ хувилбарыг батлахгүй. Эрх, төлбөр, хувийн мэдээлэл эсвэл байршуулалтад хүрсэн PR-д илүү нарийн тест, нэмэлт хүний review шаардах дүрмийг баг урьдчилан тогтооно.

Merge-ийн өмнөх долоон шалгалт

1. Build болон автомат шалгалтыг ажиллуул. Өөрчлөгдсөн салбарт compile эсвэл build, автомат тест, lint, статик шинжилгээг ажиллуулж, шинэ алдаа болон анхааруулгыг шалга. CI амжилттай дууссан эсэхээс гадна аль ажил огт эхлээгүй, аль нь алгасагдсан, ямар файлыг шалгасан болохыг хар. Тухайн PR-ийн шалгах ёстой зам CI-ийн хамрах хүрээнээс гадуур байвал үр дүнг ногоон гэж тэмдэглэх нь хангалтгүй. Илэрсэн алдааг зассаны дараа шалгалтыг шинэ commit дээр дахин ажиллуул.
2. Өөрчлөлтийг хүссэн зорилготой тулга. Issue эсвэл хүлээн авах нөхцөлд заасан зан төлөвийг бодит diff-тэй харьцуул. Код зөв ажиллаж байсан ч өөр асуудлыг шийдсэн, төслийн тогтсон загварыг эвдсэн, эсвэл хүсээгүй файл өөрчилсөн байж болно. Бүх өөрчлөгдсөн файлыг үзэж, lockfile, CI тохиргоо, өгөгдлийн шилжилт, холбоогүй формат засвар орсон бол PR-ийн зорилгод яагаад хэрэгтэйг нь тайлбарлуул. Хэрэггүй өөрчлөлтийг салгавал review хийх хүрээ тодорхой болно.
3. Тест зөв зан төлөвийг баталж байгааг нягтал. Амжилттай тестийн тооноос илүүтэй өөрчлөлтийн гол нөхцөлүүд хамрагдсан эсэхийг хар. Тухайн логикт хамаарах хил заагийн утга, буруу оролт, хоосон үр дүн, зөвшөөрөлгүй хэрэглэгчийн тохиолдлыг шалга. Унаж байсан тест устсан, алгасагдсан, assertion нь сул болсон эсвэл шалгах ёстой хамаарлыг mock-оор сольсон бол шалтгааныг нь diff-ээс тогтоо. Код болон тестийг AI нэг дор бичсэн үед хүлээгдэж буй үр дүнг тестийн бичвэрээс бус, шаардлагаас нь бие даан тодорхойл.
4. Шинэ хамаарлыг яг нэр, хувилбараар нь шалга. Package-ийн нэр бүртгэлд байгаа эсэх, lockfile-д аль хувилбар болон татах эх үүсвэр орсныг нягтал. Арчилгааны байдал, мэдэгдсэн эмзэг байдал, төслийн баталсан хамаарлын бодлогыг мөн үз. OWASP-ийн AI кодын аюулгүй байдлын зөвлөмж зохиомол package-ийн нэр, хуучирсан хувилбар, сулруулсан тест болон даалгавраас гадуурх файлын өөрчлөлтийг тусгайлан анхааруулдаг. Dependabot PR ч байсан хамаарлын өөрчлөлтийн хамрах хүрээг тусад нь нягтал.
5. Лиценз болон кодын гарал үүслийг баталгаажуул. Шинээр нэмсэн package-ийн лицензийг төслийн түгээлт, ашиглалтын нөхцөлтэй тулга. Лиценз нь байхгүй эсвэл тодорхойгүй бол эзэмшигчээс нь мэдээлэл авч, багийн шийдвэр гарахаас өмнө тухайн хамаарлыг оруулахгүй. AI-ийн санал болгосон том кодын хэсэг олон нийтэд байгаа хэрэгжүүлэлттэй төстэй бол гарал үүслийг шалгаж, шаардлагатай мэдэгдэл, зөвшөөрлийг төслийн журмаар шийд. Build амжилттай болсон нь лицензийн нийцлийг тогтоохгүй.
6. API болон эмзэг логикийг бодит хувилбартай тулга. Шинээр ашигласан method, endpoint, тохиргооны нэрийг тухайн library эсвэл үйлчилгээний хэрэглэж буй хувилбарын баримттай харьцуул. Дараа нь буруу параметр, алдаа боловсруулах салаа, эрхийн шалгалт, өгөгдлийн хувиргалт ямар үр дүн өгөхийг мөрдөж үз. Тестэд хамрагдаагүй код compile болох боломжтой тул уншихад үнэмшилтэй харагдсанаар нь зөвшөөрч болохгүй. Нууц мэдээлэл, гадаад хүсэлт, build script эсвэл deployment тохиргоонд хүрсэн бол тухайн замын оролт, эрх, алдааны үр дүнг тусгайлан шалга.
7. Сүүлийн diff-д хүний approval ав. Reviewer PR-ийн тайлбар, AI-ийн хураангуй эсвэл Copilot-ийн comment-оор хязгаарлахгүйгээр өөрчлөгдсөн файл бүр, тестийн өөрчлөлт, шийдээгүй саналыг үзнэ. Аль шалгалт хийгдээгүйг PR-д ил тод тэмдэглэж, засвар шаардлагатай бол approval өгөхөөс өмнө шийд. Review-ийн дараа шинэ commit орсон бол хүн шинэ diff болон түүнд хамаарах CI-ийн үр дүнг дахин харна. Кодын зөв ажиллагаа, аюулгүй байдал, цаашдын арчилгааг хариуцах хүн тодорхой байх ёстой.

Эрсдэлээс хамаарах approval дүрэм

Багийн дүрэмд бага эрсдэлтэй өөрчлөлтийг зөвхөн нөлөөгөөр нь тодорхойл: хэрэглэгчийн эрх, хувийн өгөгдөл, өгөгдлийн бүтэц, шинэ хамаарал, CI болон байршуулалтын тохиргоонд хүрээгүй жижиг засвар байж болно. Ийм PR-д шалгах хуудасны үр дүн бөглөгдсөн, CI сүүлийн commit дээр амжилттай дууссан, өөр хөгжүүлэгч diff-ийг үзээд approval өгсөн байх нөхцөл тавь. Кодын хэмжээ бага байх нь эрсдэл бага гэсэн баталгаа биш; нэг мөрийн эрхийн өөрчлөлт ч энэ ангилалд багтахгүй.

Өндөр эрсдэлтэй өөрчлөлтөд нэвтрэлт, зөвшөөрөл, төлбөр, хувийн мэдээлэл, өгөгдлийн шилжилт, шинэ package, CI болон deployment script-ийг хамруул. Ийм PR-д кодын эзний review дээр аюулгүй байдал эсвэл холбогдох системийг хариуцдаг өөр хүний approval нэмэхийг багийн дүрэм болго. Өөрчлөлтийн онцлогт тохирсон сөрөг тестийн үр дүн, буцаах төлөвлөгөө шаардлагатай эсэхийг мөн PR дээр шийд. Энэ бол бүх repository-д автоматаар үйлчлэх GitHub-ийн тохиргоо бус, баг өөрийн merge нөхцөлдөө хэрэгжүүлэх санал юм.

Copilot-ийн review-г хүний зөвшөөрөлтэй ялга

GitHub-ийн Copilot code review зааварт ердийн тохиргоонд Copilot «Comment» review үлдээдэг бөгөөд энэ нь PR-ийн required approval-д тооцогдохгүй гэж заасан. Тусгайлан тохируулбал Copilot «Approve» review өгч болно. Тийм тохиргоо техникийн merge нөхцөлийг хангаж байсан ч AI-ээр бичсэн кодод хүний approval заавал авахыг баг тусдаа дүрэм болгон тогтоох хэрэгтэй.

Copilot өмнө нь үзсэн PR-д шинэ push орсныг тохиргоогүй үед автоматаар дахин review хийхгүй. Шинэ push бүрийг Copilot-оор шалгуулах бол automatic code review-ийн «Review new pushes» сонголтыг идэвхжүүл; шаардлагатай үед review-г гараар дахин хүсэж болно. Хүний reviewer мөн сүүлийн commit-ийг үзсэн эсэхээ баталгаажуулна.

PR template-д хуулах шалгах хуудас

Дараах мөр бүрийн ард үр дүн, тайлбар эсвэл холбогдох CI ажил, баримтын холбоосыг бөглө. Шалгалт хамаарахгүй бол яагаад гэдгийг товч бич; хоосон мөрийг баталсан мэт тэмдэглэх хэрэггүй.

• [ ] Сүүлийн commit-ийн build, тест, lint, статик шинжилгээний үр дүн: ___
• [ ] Шаардлага, өөрчлөгдсөн бүх файл, нэмэлт хүрээний тайлбар: ___
• [ ] Хил зааг ба сөрөг тест; устгасан эсвэл сулруулсан тестийн шалтгаан: ___
• [ ] Шинэ package-ийн нэр, хувилбар, бүртгэл, эмзэг байдлын шалгалт: ___
• [ ] Код болон хамаарлын лиценз, гарал үүслийн шийдвэр: ___
• [ ] API-ийн бодит хувилбар, эрх ба алдаа боловсруулах замын шалгалт: ___
• [ ] Эрсдэлийн ангилал, сүүлийн diff-ийг үзсэн хүний approval: ___

Merge хийх шийдвэрийг жагсаалтын тэмдэглэгээний тоогоор бус, мөр бүрийн нотолгоо болон тухайн эрсдэлийн ангилалд шаардсан approval-аар гарга. Засвар орсон бол өөрчлөгдсөн мөрийн үр дүнг шинэ commit-д тааруулж шинэчил.

Мөн уншаарай:

• Dependabot PR-ийг шууд бүү merge хий: production scope-оо эхлээд шалга
• GitHub secret scanning олсон түлхүүрийг устгах нь оройтсон: эхлээд revoke хий
• AI API-ийн зардлыг 50% бууруул: яаралгүй ажлыг batch-д шилжүүл