Tässä artikkelissa käsitellään, miten AI-Commerce-Svelte -repositoriossa olevia frontend-haaroja ylläpidetään ja hallitaan ketterän ohjelmistokehityksen periaatteiden mukaisesti. Saat ohjeita siihen, miten automaattiset main -haaran muutosten merget toimivat, milloin tehdään kokonaan uusi komponenttiversio ja millä nimellä, sekä kuinka välttää turhia konflikteja muun muassa CSS-rivityksiä säilyttämällä.

Johdanto

• Jokainen AI Commerce -alustan frontend-projekti (tenant) on omassa branchissaan, ja kaikilla niillä on yhteinen main -haara.
• Main -haara toimii tuotantotason keskushaarana, josta kaikki ydinkoodin päivitykset jaellaan automaattisesti muille haaroille.
• Tämän ansiosta esimerkiksi yhden komponentin bugikorjaus täytyy tehdä vain kerran, jonka jälkeen se voidaan tuoda kaikkiin kauppoihin automaattisesti.
• Tree-shaking-ominaisuus Svelte-kehityksessä varmistaa, että tarpeettomat komponentit tiputetaan pois jo compile -vaiheessa, mutta silti voidaan tarvittaessa säilyttää ”reservikomponentteja” main-haarassa tulevaisuuden tarpeita varten.

Keskeinen toimintaperiaate

1. Yhteinen main-haara
   • Sisältää kaikki peruskomponentit ja ydinkoodin.
   • Kun main-haaraan tehdään korjaus tai uusi toiminto, siitä ajetaan automaattinen bash-skripti, joka päivittää muutokset kaikille haaroille.
   • Mahdolliset konfliktit on kehittäjän ratkaistava manuaalisesti.
2. Tenant-kohtaiset haarat
   • Jokaisella kaupalla on oma branch, jossa voidaan säilyttää tai muokata vain heidän tarvitsemiaan komponentteja.
   • Joissakin tapauksissa poistetaan tai jätetään kokonaan pois vaihtoehtoinen komponenttiversio, jos sitä ei tarvita (esim. käytössä on vain ProductConsumerPrices.svelte, joten ProductBusinessPrices.svelte poistetaan tästä haarasta selkeyden vuoksi).
3. Automaattinen merge-skripti
   • Skripti ohittaa konfliktit, joissa uusi komponentti puuttuu joltakin haaralta (eli jos se on jo poistettu tarpeettomana).
   • Kehittäjä käsittelee vain ne tilanteet, joissa syntyy varsinainen muutoskonflikti.

Uusien komponenttiversioiden luominen

Usein muutokset voidaan tehdä samaan komponenttiin ilman erillistä versiota, etenkin jos ne ovat pieniä JavaScript- tai CSS-viilauksia. Jos kuitenkin:

• Muuttunut komponentti on niin erilainen, että main-haaraan tulevat myöhemmät päivitykset voisivat aiheuttaa jatkuvia konflikteja, tai
• Uudistus tuo merkittävää, laajasti hyödynnettävää lisäarvoa, mutta voi samalla rikkoa aiempaa logiikkaa,

on järkevämpää luoda main-haaraan uusi komponenttinimi. Esimerkiksi:

• Alkuperäinen komponentti: Footer.svelte
• Uusi, merkittävästi erilainen versio: FooterGrid.svelte (käyttää grid CSS -rakennetta flexin sijaan)

Nimeämiskäytännön säännöt

• Komponentin alkuperäinen nimi säilyy osittain, jotta tiedostot pysyvät loogisessa ryhmässä (esim. Header -> HeaderTransparent, Footer -> FooterGrid).
• Nimen tulee kuvailla komponentin oleellista eroa, pelkkä numerointi (esim. Footer2.svelte) ei ole sallittua.
• AICommercen ydinkehitystiimi valvoo komponenttien nimeämistä ja hyväksyy main-haaraan vietävät uudistukset.

CSS-muutosten hallinta

• Vähennä turhia merge-konflikteja säilyttämällä CSS-rivit, vaikka arvo muuttuisi (esim. älä poista padding: 20px -riviä kokonaan, vaan muuta se padding: 0px).
• Tämä helpottaa bash-skriptin ja kehittäjien työtä, kun on selkeää, mitä kohtaa rivillä on muokattu.

Suositeltu eteneminen kehittäjille

• Tarkista ensin, riittävätkö muutokset samaan komponenttiin vai tarvitseeko luoda kokonaan uusi versio.
• Varmista main-haaraan vietävien muutosten laajuus ja merkitys sekä niiden potentiaalinen hyöty muille kaupoille.
• Hyödynnä automaattista bash-skriptiä, joka päivittää main-haaraan tehdyt korjaukset kaikkiin tenant-haaroihin. Ratkaise vain mahdolliset konfliktit käsin.
• Noudata komponenttien nimeämiskäytäntöjä, jotta tiedostot pysyvät selkeässä järjestyksessä ja käytettävyyttä parantavat uudistukset voidaan jakaa laajemminkin.

Yhteenveto

Frontend-haarojen hallinta AI Commerce -alustalla tehostaa kehitystyötä: yksi keskitetty main-haara mahdollistaa ketterät päivitykset ja korjaukset, jotka skaalautuvat automaattisesti eri asiakkaiden projekteihin. Tarkoituksena on minimoida päällekkäinen työ, välttää konflikteja ja silti mahdollistaa kustomoitavien komponenttien jatkuva kehittyminen. Mikäli komponentti muuttuu perustavanlaatuisesti, kannattaa luoda siitä uusi, selkeän nimen omaava versio main-haaraan – mutta vain silloin, kun se on tarpeellista laajempien uudistusten tai lisäarvon kannalta.