Main-haara omistaa yhteisen storefront-käyttäytymisen

AI Commerce Svelte -storefrontin main-haara omistaa jaetun käyttäytymisen, rakenteen ja peruskomponentit. Jokaisella tuotantokaupalla on oma tenant-haara, jossa säilytetään vain todistettu kauppakohtainen esitystapa, konfiguraatio tai aidosti tenantille kuuluva komponentti. Tenant valitaan Git-haaralla, ei ympäristötiedostolla, joka yrittäisi jäljitellä toista kauppaa.

Yhteinen korjaus tehdään main-haaraan kerran ja levitetään tenant-haaroihin hallitulla merge-ajolla vain Petron pyynnöstä. Tämä vähentää päällekkäistä työtä, mutta päivitys ei ole konfliktiton eikä automaattisesti valmis tuotantoon. Jokaisen tenant-haaran merge, tarkistus, push ja deploy ovat erillisiä vaiheita, ja tenantkohtainen toiminta pitää säilyttää konfliktinratkaisussa.

Svelten ja Viten tree shaking voi jättää käyttämättömän koodin pois tuotantobundlesta. Se ei ole peruste kerätä main-haaraan tulevaisuuden varalle reservikomponentteja. Repossa on lisäksi käyttämättömien Svelte-tiedostojen siivoustyökalu, joten uusi yhteinen komponentti tehdään vasta, kun todellinen nykyinen kuluttaja tai hyväksytty yhteinen tarve on osoitettu.

Valmistele main-haaran levitys tenant-haaroihin

Main-haaran levitys aloitetaan puhtaasta main-työpuusta. Tarkista aktiivinen haara ja git status; committoi omat muutokset ja selvitä kaikki vieraat keskeneräiset muutokset ennen haaraskriptejä. deploy/merge.sh pysähtyy heti, jos työpuu ei ole puhdas, koska skripti vaihtaa haaroja ja voi luoda merge-committeja.

Jaa vain yksi koherentti yhteinen muutos kerrallaan. Älä yhdistä tenant-mergeen komponenttien nimeämistä, siivousta, riippuvuuspäivityksiä tai tiedostojen poistoja, jotka eivät kuulu samaan korjaukseen. Jos tenantilla on oma riippuvuusversio, säilytä se ja generoi kyseisen haaran package-lock.json tarvittaessa npm install -komennolla.

Oletusajo on ./deploy/merge.sh -r, mutta se suoritetaan vain Petron nimenomaisesta pyynnöstä. Skripti hakee originin, päivittää paikallisen main-haaran fast-forwardilla ja käsittelee originin tenant-haarat. Kehitys-, ominaisuus-, Codex-, Claude-, Dependabot-, *-dev- ja *-wp-haarat rajataan tästä tuotantotenanttien kierroksesta pois.

Yhdistä main tenant-haaraan turvallisesti

Tenant-haaran yhdistämisessä tenant on nykyinen haara ja main on saapuva muutos. deploy/merge.sh päivittää ensin tenantin originista fast-forwardilla ja tekee sitten main-mergen. Jos yhdistäminen onnistuu ja indeksi sisältää muutoksia, skripti luo commitin viestillä chore: auto-merge main into <tenant>.

-r eli --resolve ratkaisee automaattisesti vain delete/modify-ristiriitoja. Jos tenant on tarkoituksella poistanut main-haarassa muuttuneen tiedoston, poisto voidaan säilyttää. Jos tenant on muuttanut tiedostoa, jonka main on poistanut, tenantin versio voidaan säilyttää. Kahden muokatun version ristiriita jää aina kehittäjän ratkaistavaksi, eikä skripti saa vaihtaa tenantin importteja tai komponentteja oikopolkuna.

Jos ratkaisemattomia tiedostoja jää, skripti pysähtyy kyseiseen tenant-haaraan. Korjaa vain kyseisen yhteisen muutoksen aiheuttama ristiriita, säilytä tenantin aiempi käyttäytyminen ja varmista importin sekä tiedoston muodostama pari. Jatka keskeytyksen jälkeen komennolla ./deploy/merge.sh -f <haara> tai oletusratkaisulla ./deploy/merge.sh -r -f <haara> sovitun prosessin mukaan.

Säilytä tenantin komponentit ja tarkoitukselliset poistot

Tenant-haara voi jättää pois komponentin, jota kyseinen kauppa ei käytä. Esimerkiksi kauppa voi käyttää vain ProductConsumerPrices.svelte-komponenttia ja poistaa ProductBusinessPrices.svelte-vaihtoehdon. Tällainen poistaminen on turvallista vain, jos kaikki importit, testit ja ajonaikaiset polut osoittavat, ettei poistettua komponenttia tarvita tenantissa.

Main-mergen automaattinen delete/modify-ratkaisu saa säilyttää tällaisen tarkoituksellisen tenant-poiston. Se ei saa päätellä uutta poistoa, palauttaa vanhaa ajonaikaista koodia testin vuoksi tai vaihtaa tenantin valitsemaa komponenttia toiseen. Jos main lisää uuden importin tiedostoon, jonka tenant on poistanut, ristiriita ratkaistaan käyttäytymisen perusteella eikä vain ottamalla kokonaan jompikumpi versio.

Yhdistämisen jälkeen tarkista erityisesti tenantin header, valikko, navigaatio ja komponentti-importit. Komennon onnistuminen todistaa vain Git-tilan, ei käyttöliittymän oikeellisuutta. Tenantkohtainen puuttuva komponentti tai testi korjataan kyseisessä tenant-haarassa; yhteistä tarkistusskriptiä ei heikennetä haarapoikkeaman peittämiseksi.

Päätä, muokataanko komponenttia vai luodaanko uusi

Svelte-komponentin pieni JavaScript- tai CSS-muutos tehdään ensisijaisesti olemassa olevaan komponenttiin. Jaettu rakenne ja käyttäytyminen kuuluvat main-haaraan, kun taas tenantin pienin todistettu ulkoasupoikkeama jää tenant-haaraan. Ennen uuden tiedoston luomista tarkista main ja relevantit tenant-haarat ja sovita lähin toimiva toteutus.

Uusi komponenttinimi voi olla perusteltu, jos rakenne ja käyttäytyminen eroavat aidosti niin paljon, että saman tiedoston ehdollistaminen aiheuttaisi jatkuvaa konfliktia, tai jos uusi yhteinen malli tarjoaa laajasti käytettävän mutta vanhan logiikan kanssa yhteensopimattoman ratkaisun. Pelkkä yhden tenantin ulkoasuero ei riitä jaetun rinnakkaiskomponentin perusteeksi.

Esimerkiksi Footer.svelte ja grid-rakennetta käyttävä FooterGrid.svelte voivat olla eri komponentteja vain, jos rakenteellinen ero ja vähintään nykyinen kuluttaja ovat todellisia. Jos ero on pelkkä väri, välistys tai muu esitysarvo, käytä yhteistä konfiguraatiota tai tenantin CSS:ää. Näin main säilyy yhtenäisenä eikä rinnakkaisversioista synny varjettua komponenttikirjastoa.

Nimeä uusi komponenttiversio kuvaavasti

Uuden Svelte-komponentin nimi säilyttää tunnistettavan yhteyden alkuperäiseen tehtävään ja kertoo olennaisen eron. Hyviä mallinimiä ovat HeaderTransparent ja FooterGrid, jos läpinäkyvä header tai grid-pohjainen footer ovat todella omia rakenteellisia mallejaan. Nimi auttaa löytämään läheiset toteutukset samasta tiedostoryhmästä.

Pelkkä numerointi, kuten Footer2.svelte, ei ole sallittu, koska se ei kerro omistajuutta, rakennetta eikä valintaperustetta. Älä myöskään nimeä komponenttia tenantin mukaan, jos mekanismi on jaettava. Aidosti tenantkohtainen komponentti voi jäädä tenant-haaraan ilman, että se nostetaan yhteiseksi vain nimen yhdenmukaistamiseksi.

AI Commercen ydinkehitystiimi katselmoi main-haaraan ehdotetun uuden komponentin ja sen nimeämisen. Katselmoinnissa osoitetaan nykyinen kuluttaja, ero lähimpään komponenttiin, omistava haara ja poistumis- tai yhdistämispolku. Uusi tiedosto ei ole oletusratkaisu mahdollisten merge-konfliktien välttämiseen.

Tee CSS-muutos pienellä diffillä

Tenantin CSS-muutos tehdään mahdollisimman pienellä diffillä ja yhteisen komponentin rakenteen säilyttäen. Jos olemassa oleva padding: 20px pitää poistaa visuaalisesti, historiallinen konfliktienhallintaohje suositteli arvon muuttamista muotoon padding: 0px rivin poistamisen sijasta. Tämä voi tehdä tenantin tarkoituksen näkyväksi myöhemmässä main-mergessä.

Sääntöä ei kuitenkaan sovelleta mekaanisesti kaikkeen CSS:ään. Tarpeeton deklarointi voidaan poistaa, jos poistaminen on pienin ja selkein ratkaisu eikä tenant tarvitse eksplisiittistä nollausta yhteisen tyylin kumoamiseen. Kun tenant laajentaa jaettua komponenttia, tenant-säännöt lisätään tyylilohkon loppuun, jotta lohkon alku pysyy käytettävissä main-päivityksille.

Käytä jaettuja brändi- ja design-token-arvoja komponenttikohtaisten kovakoodausten sijasta. Tarkista CSS-muutoksen vaikutus työpöytä-, tabletti- ja mobiilileveyksillä sekä komponentin vuorovaikutustiloissa. Rivin säilyttäminen voi vähentää tekstuaalista konfliktia, mutta vain renderöinti kertoo, säilyikö tenantin ulkoasu.

Tarkista, pushaa ja julkaise tenant-haarat järjestyksessä

Tenant-haarojen koko julkaisukierros alkaa puhtaasta main-haarasta ja etenee järjestyksessä ./deploy/merge.sh -r, ./deploy/check.sh, ./deploy/push.sh ja ./deploy/deploy.sh. Merge levittää yhteisen muutoksen, check ajaa tiukan tenant-kierroksen, push julkaisee haarat originiin ja deploy tekee julkaisumerkinnät tuotantohaaroihin.

Jos tarkistuskierros keskeytyy tenanttiin, jatka dokumentoidulla -f <haara>-valinnalla korjauksen jälkeen. Älä ohita epäonnistunutta tenanttia tai käytä paikallista nopeutusta CI-vaatimusten heikentämiseen. Tarkista merge-automaation jälkeen header, valikko, navigaatio ja komponentti-importit sekä muutoksen oma toiminnallinen pinta.

Myöhemmät deploy-marker-commitit eivät kuulu ennen niitä ajettujen tarkistusten todistusalaan. Varmista siis julkaisun lopullinen commit ja tuotantotila erikseen. Prosessin tavoite on yksi yhteinen korjaus, pienet tenant-poikkeamat, käsitellyt konfliktit ja toistettava julkaisu — ei lupaus siitä, että main siirtyisi automaattisesti kaikkiin kauppoihin ilman ihmisen hyväksyntää.