Mis on korduv ehitus?
Deterministlik ehitus või reprodutseeritav ehitus on veidi erinevad, kuid neid saab sellest artiklist mõista kui sama asja.
Reprodutseeritavad ehitused viitavadMitu ehitusprotsessi täitmist sama sisendi ja ehituskeskkonnaga võivad anda täpselt samad tulemused。 See tehnoloogia on oluline tarkvaraarenduses, levitamises ja turvalisuse valideerimises.
Build on reprodutseeritav, kui see annab täpselt sama väljundi sõltumata sellest, millal ja kus seda käivitatakse. Pole tähtis, millisel arvutil sa töötad, mis kellaajal päeval ja milliseid välisteenuseid võrgu kaudu kasutad, reprodutseeritavad versioonid annavad sama bait-baidi kaupa väljundi. See on suurepärane nii arenduseks (sest reprodutseeritavaid versioone on lihtne erinevate arendajate seadmete vahel jagada) kui ka tootmiseks (sest on lihtne tagada, et korduvate versioonide tulemusi pole muudetud – lihtsalt käivita versioon oma masinal ja kontrolli, et tulemused oleksid järjepidevad!). on väga kasulikud.
Korduvate ehituste kolm sammast
Sammas 1: Korduvad ehitused
Ehituse korduvus viitab sellele, mis juhtub ehitusmasinaga endaga. Eeldades, et meie ehituse sisendid on saadaval ja maailmas ei muutu midagi, kas meie ehitus annab sama väljundi, kui seda korrata?
Deterministlik paigaldusplaan
Esimene, lihtsaim ja ilmsem nõue korduva ehituse puhul on deterministlik sõltuvuse paigaldusplaan.
Enamikes keeltes on see sama lihtne kui lukustatud faili sisestamine. Kaasaegsed ehitustööriistad võimaldavad sageli projektidel väljendada otseseid sõltuvusnõudeid piirangutena ning seejärel lahendada need piirangud, et koostada paigaldusplaan (sõltuvuste nimede ja versioonipaaride nimekiri paigaldamiseks). Paljud neist tööriistadest genereerivad ka lukufaile seriaalsete paigaldusplaanide jaoks. Arendajad saavad need lukufailid esitada versioonihaldusele, et tulevased versioonid kasutaksid samu sõltuvusnimesid ja versioone.
Pane tähele, et deterministlik on vaja ka sõltuvusehituses endas (mitte ainult versioonide valikus), ja deterministlik paigaldusplaan ei võimalda seda saavutada!
Deterministlik konstruktsioon
Kui me teame, mida ehitada, peab meie ehitus ise (sh meie enda kood ja sõltuvuskood) tegelikult olema deterministlik.
See ei pruugi tegelikult probleemiks olla projektides, kus pole kompileerimisetappi! Näiteks Node'i projekt kõigi sõltuvustega on puhas JavaScript ning efektiivse deterministlikkuse saavutamiseks ei ole vaja täiendavat tööd.
Projektide puhul, mis sisaldavad kompileerimist või tõlkimist (allikast allikani kompileerimine), on determinismi tagamine kaugelt kõige keerulisem osa reprodutseeritava ehituse loomisel. Kompileerimisprotsess võib kaudselt tuua mittedeterminismi mitmel viisil, sealhulgas:
- Turingi täielikud programmi ehitusskriptid võivad kompileeritud väljundit soovi korral muuta.
- Järelinstalli skriptid, mis tuginevad käivitatavatele failisüsteemi päringutele või võrgukõnedele.
- C-sidumine süsteemi poolt paigaldatud paketiga, kus erinevate päistega süsteemide sidumised võivad anda erinevaid väljundeid.
- Sammud faili loomiseks, mis loeb väljaspool versioonihaldust.
- Loo samme ajatemplite genereerimiseks süsteemi aja abil.
- Sammud sõltuvuste loomiseks, mis ei ole võrgu allalaadimise paigaldusplaanis väljendatud (näiteks NPM-sõltuvuse allalaadimine GitHubist vahemällu salvestatud binaarehituse jaoks, mis on C-piiratud).
- Muuda käitumist vastavalt hetkel seatud keskkonnamuutujale, kuid ära esita buildi keskkonnamuutuja konfiguratsiooniga.
Kõik need käitumised ei tekita tingimata ebakindlust, kui neid õigesti seadistada, kuid ehitusprotsessi õige seadistamine võib olla keeruline ja keeruline. Näiteks võid lugeda seda blogipostitust Chromiumi ehituste ebakindlusest. Paljusid neist probleemidest saab leevendada kohaliku ehituskeskkonna kontrollimisega, mida käsitleme järgmises osas.
Sammas 2: Muutumatu keskkond
Isegi korduvate ehitustega peame veenduma, et ehitussisendid ei muutuks. Sageli tähendab see, et tahame olla kindel, et ehitame ümber muutumatule hetkepildile oma ümbrusest.
Muutumatu kohalik keskkond
Nagu eespool arutasime, on ehituse ebakindluse levinud allikas "sõltuvused", mida ehitustööriist ei kajasta. C-piiratud süsteemiteegid on kõige levinumad näited, kuid ka teised kohalikud keskkonnategurid, nagu keskkonnamuutujate seaded ja failid, mis jäävad versioonihalduse raami, võivad samuti ehitust mõjutada.
Lihtne viis selle probleemi leevendamiseks on käivitada versioon tuntud muutumatus konteineris. Näiteks konteineri käitusaeg nagu Docker aitab tagada, et kõik kasutavad samu süsteemisõltuvusi, samu keskkonnamuutujaid ja töötab samal failisüsteemil. Lisaks on lihtne kontrollida, et konteineri sisu vastab teadaolevale heale ehituskonteinerile, ning vajadusel saab konteineri hõlpsasti eemaldada tuntud heas pildis ja uuesti luua.
Pane tähele, et oleme väga selged tuntud konteinerite või tuntud konteineripiltide osas. Ei piisa ainult Dockerfile'i esitamisest! Miks? Sest Dockerfile ise ei kirjelda täielikult reprodutseeritavat ehitusprotsessi Dockeri piltide jaoks, sest need ei tööta muutumatus globaalses keskkonnas.
Muutumatu globaalne keskkond
Ehitussüsteemid suhtlevad sageli väliste teenustega, et täita ülesandeid nagu versioonide lahendamine ja sõltuvuste allalaadimine. Kuid välised teenused muutuvad sageli.
Apt install nodejs'i käivitamine täna annab sulle teistsugused tulemused kui eelmisel aastal ja tõenäoliselt ka järgmisel aastal on tulemused teistsugused. Sellepärast ei suuda Dockerfiles ise kirjeldada reprodutseeritavaid ehitusi – sama Dockerfile'i käivitamine erinevatel ajahetkedel annab erinevaid ehitustulemusi!
Lihtne lahendus on konfigureerida ehitus võimalusel, määrates täpse versiooni (ideaalis ka täpse sisuräsi), et tulevased versioonid kasutaksid sama versiooni nagu praegune versioon. Kuid välised teenused võivad ka ootamatult oma käitumist muuta – tõeliselt pessimistlik reprodutseeritav versioon haldab sisemist kuvandit, kasutades võimalikult palju oma võrguressursse.
Sammas 3: Ressursside kättesaadavus
Oletame, et meie ehitus on korduv ja maailm meie jalge all ei muutu. Kõik, mida nüüd vajame, on ligipääs ehituse sisendile. See tundub lihtne, eks? Hästi......
Register mõnikord ebaõnnestub
Enamik Node'i arendajaid on kogenud vähemalt ühte NPM-tõrget, mille käigus ehitustoru ilma NPM-pakette vahemällu salvestamata või peegeldamata on häiritud. Paljud Node'i arendajad on kogenud ka vasaku padja ja võltsija eemaldamist, mis on tõsiselt kahjustanud NPM-i ökosüsteemi ja sisuliselt viinud katkestuseni.
Ainus usaldusväärne viis selliste ehituskatkestuste leevendamiseks on käivitada oma pakettide registri peegel. Kui välised teenused pole saadaval, võib pilt jääda internetti; Kui ametlik register kustutab vana paketi, saab peegel jätkata teenuste pakkumist. Sama põhimõte kehtib ka teiste kaugteenuste kohta: kui sa ei käivita oma pilti, on ehitustoru kättesaadavus võrreldav ainult selle teenuste kättesaadavusega.
Teenuse kuvandi haldamine on alati delikaatne kompromiss. Ühelt poolt on sellistel registritel nagu NPM pühendunud inseneri- ja operatsioonimeeskonnad, kellel on pädevus hoida neid süsteeme töös hoida. Teisest küljest on palju lihtsam käivitada väike pilt väikese sõltuvuste komplekti jaoks kui käivitada kõiki NPM pilte. Sa peaksid tegema peegeldavaid otsuseid iga teenuse spetsiifika põhjal, arvestades ajalooliste väliste teenuste usaldusväärsust ning meeskonna ehituse kättesaadavust ja personalivajadusi.
Tarnijad tagavad maksimaalse kättesaadavuse
Lihtne viis tagada oma projekti sõltuvuste maksimaalne kättesaadavus on lisada need oma tarnijale. Enamik paketihaldureid toetab mingisugust "vendoringut", mis tähendab, et selle asemel, et tugineda väliste teenuste allalaadimistele, salvestame sõltuvuse lähtekoodi versioonihaldusse, eksisteerides koos meie lähtekoodiga. Näiteks Node'is võib see tunduda node_modules sidumisena lähtekoodihaldusele.
Kuigi see lahendus pole täiuslik (sõltuvalt sellest, kuidas sinu tarnija ja projekt on üles ehitatud, mis võib versioonihaldusele palju koormust panna), on see sageli kõige lihtsam ja lihtsam lahendus maksimaalse kättesaadavuse saavutamiseks.
Viide:
Hüperlingi sisselogimine on nähtav.
Hüperlingi sisselogimine on nähtav. |
Postitatud 2025-4-30 10:09:27
|
|
|
|
Üürileandja|
Postitatud 2025-4-30 10:10:23
|
