Automatizuokite savo saugyklą naudodami „Git Hooks“ sistemoje „Windows“

PCHardwarePro » Windows » Automatizuokite savo saugyklą naudodami „Git Hooks“ sistemoje „Windows“

Įsivaizduokite, kad turite asmeninį asistentą, kuris peržiūri kiekvieną jūsų kodo eilutę, patikrina, ar jūsų pakeitimų pranešimai nėra netvarkingi, ir atlieka vienetų testus prieš pat jums įkeliant pakeitimus į serverį – visa tai jums net piršto nepajudinant. Na, būtent tai ir daro „Git Hooks“ : tie maži scenarijai, kurie slypi jūsų saugykloje, kad automatizuotų nuobodžias užduotis ir neleistų jums padaryti klaidų blogiausiu įmanomu momentu.

Nesvarbu, ar dirbate vienas prie asmeninio projekto, ar kaip didelės komandos dalis, šių automatizavimų integravimas į „Git for Windows“ yra didžiulis žingsnis į priekį. Tai ne tik laiko taupymas, bet ir darbo eigos standartizavimas , kad jūsų kodas būtų švarus, nuoseklus ir, svarbiausia, be išvengiamų klaidų, kol jis nepasiekė pagrindinės šakos.

Susijęs straipsnis:

Kas yra sistemos kabliukai ir kaip jie naudojami skirtingose ​​aplinkose?

Kas, po galais, yra „Git“ kabliukai ir kaip jie veikia?

Iš esmės, kabliai yra pasirinktiniai scenarijai, kuriuos „Git“ automatiškai paleidžia, kai kūrimo gyvavimo cikle įvyksta konkretus įvykis. Įsivaizduokite juos kaip įvykių paleidiklius : kai jūs commit'inate, įkeliate arba sujungiate, „Git“ ieško atitinkamo scenarijaus konfigūracijos aplanke ir, jei toks yra, jį vykdo. Jei scenarijus grąžina klaidą (išėjimo kodą 1), „Git“ blokuoja operaciją , priversdama jus išspręsti problemą prieš tęsiant.

Šie scenarijai saugomi paslėptoje jūsų projekto srityje, konkrečiai kataloge „.git/hooks“ . Kuriant saugyklą, „Git“ jau pateikia kelis šablonus su plėtiniu „.sample“ , todėl jums nereikia pradėti nuo nulio. Jums tereikia juos pervadinti, pašalinti plėtinį „.sample“ ir pridėti savo logiką, naudodami „Bash“, „Python“ ar „Ruby“, jei sistema gali juos vykdyti.

Susijęs straipsnis:

„GitHub“ saugumo incidentas: reali rizika ir kaip apsaugoti savo saugyklas

Kabliukų tipai: kurį pasirinkti priklausomai nuo progos?

Siekiant išvengti painiavos, svarbu atskirti kabliukus, esančius jūsų kompiuteryje (kliento pusėje), nuo tų, kurie yra nuotoliniame serveryje.

Kliento pusės kabliukai

Tai yra dažniausiai pasitaikantys kasdieniame kūrėjo darbe naudojami metodai, nes jie leidžia akimirksniu aptikti klaidas, nelaukiant, kol CI/CD serveris jus įspės:

• iš anksto įsipareigotiTai kodo sergėtojas. Jis paleidžiamas prieš sukuriant commit. Jis idealiai tinka paleisti linteriai arba formatavimo įrenginiai kaip „Prettier“ ar „ESLint“, užtikrinant, kad niekas neįkeltų kodo su keistais įtraukimais ar sintaksės klaidomis.
• paruošimo-pakeitimo-žinutėNaudinga automatiškai pildant patvirtinimo pranešimą, pavyzdžiui, pridedant „Jira“ užduoties numerį arba šakos pavadinimą.
• įsipareigoti žinuteTai užtikrina, kad pranešimas būtų aprašomasis. Galite priversti juos laikytis metodologijos, pateiktos Įprastiniai komitetai (naudojant tokius prefiksus kaip „feat:“ arba „fix:“), vengiant klasikinių „įvairių pakeitimų“ pranešimų, kurie nieko nepasako.
• po įsipareigojimoŠi komanda paleidžiama patvirtinus pakeitimus. Ji naudojama pranešimams siųsti arba vietinei dokumentacijai atnaujinti.
• išankstinis stumdymasTai paskutinė gynybos linija. Prieš siųsdama kodą į nuotolinio valdymo pultą, ji atlieka išsamesnius testus, taip užkirsdama kelią... sugriauti konstrukciją iš savo klasiokų.
• po apmokėjimo ir po sujungimoIdealiai tinka atnaujinti submodulius arba išvalyti aplinkos talpyklas kiekvieną kartą keičiant šakas arba sujungiant kodą.

Serverio pusės kabliai

Jie konfigūruojami serverio „tuščioje“ saugykloje ir yra privalomi visai komandai, nes jų negalima apeiti naudojant komandą „--no-verify“:

• išankstinis gavimas: Patvirtina, kad siuntimas atitinka griežtas taisykles prieš jį priimant serveryje.
• atnaujinimasPanašus į ankstesnįjį, bet jis vykdomas vieną kartą kiekvienai atnaujinamai šakai.
• po gavimoAutomatikos karalius. Jis naudojamas... rodyti kodą automatiškai žiniatinklio serveryje arba siųsti įspėjimus „Slack“ sistemai, informuojančius apie naujus pakeitimus.

Žingsnis po žingsnio vadovas, kaip surinkti savo pirmąjį kabliuką

Jei norite iš karto pradėti dirbti su „Windows“, procesas yra gana paprastas. Pirmiausia eikite į aplanką .git/hooks jūsų projekto. Jei norite suaktyvinti išankstinį įdiegimą, sukurkite failą su tokiu pačiu pavadinimu, be jokio plėtinio. Kad „Git“ jį atpažintų, turite įsitikinti, kad jis yra vykdomasis„Unix“ pagrindu sukurtose sistemose arba naudojant „Git Bash“ sistemoje „Windows“, komanda yra chmod +x .git/hooks/pre-commit.

Sukūrę failą, atidarykite jį naudodami mėgstamą redaktorių ir pridėkite šebangas pradžioje (pvz., #!/bin/bash), kad sistemai nurodytumėte, kurį interpretatorių naudoti. Tada parašykite logiką. Pavyzdžiui, jei naudojate PHP, galite integruoti PHP kodo snifferis kad commit nepavyktų, jei stilius neteisingas. Atminkite, kad jei scenarijus baigiasi exit 0Operacija tęsiama, bet jei ji baigiasi exit 1„Git“ nedelsdamas sustabdys procesą.

Integracija su CI/CD ir diegimas žiniatinklyje

Nors kabliai yra galingi, jie neturėtų pakeisti nuolatinės integracijos ir nuolatinio teikimo (CI/CD) platformos , tokios kaip „Jenkins“, „GitHub Actions“ ar „GitLab CI“, o veikiau ją papildyti. Ideali strategija yra hibridinis metodas : naudoti vietinius kablius greitam patvirtinimui (linting, paprastiems vienetiniams testams) ir leisti CI/CD platformai atlikti sudėtingus testavimo, kūrimo ir diegimo darbus testavimo ir gamybos aplinkoje.

Norėdami automatizuoti pagrindinį žiniatinklio diegimą, galite nustatyti kabliuką po gavimo jūsų serveryje. Scenarijus galėtų vykdyti komandą git checkout -f Eikite į aplanką, kuriame yra jūsų svetainė, ir paleiskite „Nginx“ arba „Apache“ serverį iš naujo. Tai žymiai sumažina rankinio įvedimo klaidų skaičių ir leidžia atnaujinimams pasiekti produkciją per [trūkstamas laiko tarpas]. minučių klausimas.

Gudrybės, kaip išvengti išprotėjimo su kabliukais

Yra problema: aplankas .git nėra įkeltas į saugyklą, todėl priedai yra vietiniai ir kiekvienas kūrėjas turėtų juos konfigūruoti rankiniu būdu. Norint išvengti šio chaoso, yra du pagrindiniai sprendimai. Pirmasis – sukurti atskirą aplanką projekte (pvz., .githooks), įkelkite jį į saugyklą ir paleiskite komandą git config core.hooksPath .githooks kad „Git“ galėtų ieškoti skriptų ten.

Antras variantas, ir galbūt profesionaliausias, yra naudoti tokius įrankius kaip „Husky“ (skirtas „Node.js“) arba išankstinio įdiegimo sistemą. Šie įrankiai leidžia apibrėžti kabliukus YAML faile, todėl visai komandai lengva automatiškai naudoti tą pačią konfigūraciją diegiant projekto priklausomybes.

Tačiau būkite atsargūs ir nepersistenkite. Jei sukursite pernelyg didelius kabliukus, kurių vykdymas užtrunka kelias minutes, kūrėjai jų nekęs ir pradės naudoti `--no-verify`, kad juos apeitų. Stenkitės, kad jūsų scenarijai būtų lengvi, kruopščiai dokumentuokite kiekvieno iš jų veiksmus README faile ir teikite pirmenybę greičiui, kad įrankis būtų pagalba, o ne kliūtis.

Privalumai, rizika ir geriausia praktika

Šios metodologijos įdiegimas suteikia aiškių privalumų: sumažina serverį pasiekiančių klaidų skaičių, kodas yra daug nuoseklesnis, o komanda mažiau laiko skiria paviršutiniškoms rankinėms peržiūroms . Tačiau kyla rizika sukurti pernelyg didelę priklausomybę nuo vietinės aplinkos arba įdiegti nesaugius scenarijus, kurie atskleistų prisijungimo duomenis, jei jie netinkamai tvarkomi naudojant aplinkos kintamuosius.

Siekiant išvengti problemų, protingiausias būdas yra moduliarizuoti srautus, atskiriant kūrimo, testavimo ir diegimo etapus. Mėlynai žalių diegimo strategijų įgyvendinimas kartu su serverio prijungimais leidžia sklandžiai keisti srautą ir greitai atšaukti atliktus veiksmus, jei kas nors nepavyksta, taip sumažinant prastovas.

Visiškas „Git“ įvykių valdymas naudojant pasirinktinius scenarijus daro kūrimo darbo eigą daug sklandesnę ir saugesnę, pašalinant žmogiškųjų klaidų faktorių atliekant pasikartojančias užduotis. Derindama vietinių kabliukų greitį su CI/CD serverio patikimumu ir valdymo įrankiais, tokiais kaip „Husky“, bet kuri komanda gali užtikrinti, kad produkciją pasiektų tik griežčiausius standartus atitinkantis kodas, taip optimizuojant produktyvumą ir galutinę programinės įrangos kokybę.