Ymmärrä nykyinen julkaisuraja

AI Commerce -storefrontin GitHub-työnkulku rakentaa ja julkaisee koodin AWS:ään vain erikseen merkitystä push-tapahtumasta. Työnkulku käyttää GitHubin OIDC-tunnistautumista AWS-roolin ottamiseen, joten tavallinen julkaisu ei tarvitse kehittäjän henkilökohtaisia pysyviä AWS-avaimia.

Commit-viestin [deploy]-merkintä käynnistää saman työn lint-, testi-, build- ja julkaisuvaiheet. Ilman merkintää koko deploy-job ohitetaan: nykyinen työnkulku ei aja silloin pelkkiä testejä. Työnkulussa ei myöskään ole muutospyynnön käynnistintä. Paikalliset portit ja katselmointi on siksi tehtävä ennen deploy-commitia.

Storefront-repon nykyinen paikallinen haarapolitiikka on main-only. Asennettava git-hook estää uuden paikallisen haaran luonnin ja merge-commitit main-haarassa, ellei ihminen tee nimenomaista ohitusta. Älä noudata vanhaa ohjetta, jonka mukaan jokaiselle tenantille luodaan kehityshaara automaattisesti.

Varmista oikeudet ja kohde ennen muutosta

AI Commerce -storefrontin CI/CD-oikeudet ja kohde varmistetaan pyytämällä repositorion kirjoitusoikeus sekä tarvittavan ympäristön julkaisulupa järjestelmän omistajalta. CODEOWNERS nimeää @petrosoft-fi-omistajaksi muun muassa GitHub-konfiguraatiolle, serverless.yml- ja package.json-tiedostoille, shell-skripteille, staattisille resursseille sekä sovelluksen ydin- ja SSR-koodille.

Nykyinen työnkulku johtaa tenantin Git-refin nimestä: -dev-pääte poistetaan ja main tulkitaan AI Commercen oletuskohteeksi. Se muodostaa tämän perusteella AWS-roolin ja hallinnan alkuperän. GitHub Environmentin, AWS-roolin ja S3-bucketin pitää olla valmiiksi määritettyjä samalle kohteelle.

Älä päättele käyttöoikeutta pelkästä mahdollisuudesta puskea commit. Varmista kohdeympäristö, hyväksyjä, muutosikkuna ja palautussuunnitelma ennen [deploy]-merkinnän käyttöä. Uuden tenant-ympäristön perustaminen on infrastruktuurimuutos, ei tavallinen haaran luonti.

Valmistele paikallinen ympäristö

AI Commerce -storefrontin paikallinen CI/CD-työ alkaa hyväksytyn aicc-svelte-repositorion kloonaamisesta ja oikean refin varmistamisesta. Storefrontin testit edellyttävät vähintään Node.js-versiota 22. Asenna riippuvuudet projektin nykyisellä npm-työnkululla. Asennus luo paikalliset kehitysasetukset ja asentaa repositorion git-hookit.

Käynnistä kehitysympäristö komennolla npm run dev ja testaa muutettu käyttäjäpolku selaimessa. Kauppakohtainen toiminta, maksupalvelu, paluuosoite, autentikointi tai muu ulkoinen integraatio tarvitsee hyväksytyn testiympäristön ja testitunnukset; älä käytä tuotannon salaisuuksia paikallisesti.

Tarkista ennen committia, että muutokset kuuluvat pyydettyyn scopeen eikä työhakemistossa ole muiden keskeneräisiä tiedostoja. Älä muokkaa ympäristö-, CI- tai deploy-tiedostoja ilman CODEOWNERS-katselmointia.

Aja lint, testit ja build paikallisesti

AI Commerce -storefrontin vähimmäisportit ovat npm run lint ja npm test. Lint ajaa ESLintin ilman sallittuja varoituksia sekä Svelte Checkin varoitukset estävässä tilassa. Testikomento muodostaa reittikarttojen testitiedot ja ajaa Vitestin kerran.

Aja lisäksi muutoksen julkaisutapaa vastaava build ennen deploy-pyyntöä. Työnkulku rakentaa asiakasosan, muodostaa reittien chunk-kartan, ajaa lintin ja testit sekä rakentaa lopuksi palvelinosan. Paikallisen todisteen pitää kattaa vähintään muuttunut komponentti, integraatioraja ja olennainen smoke-testi.

Jos portti epäonnistuu, korjaa juurisyy ja aja se uudelleen. Älä ohita testiä, vaimenna lint-sääntöä tai löysennä odotusta vain julkaisun jatkamiseksi. Kirjaa ajetut komennot ja tulokset katselmointiin.

Commitoi ja pyydä katselmointi

AI Commerce -storefrontin CI/CD-muutos commitoidaan yhtenä pienenä tarkoituksena vasta vihreiden paikallisten porttien jälkeen. Älä lisää [deploy]-merkintää tavalliseen katselmointicommittiin. Pushaa nykyinen hyväksytty haara ja pyydä omistajan katselmointi muutoksen vaikutuksen sekä CODEOWNERS-sääntöjen mukaan.

Nykyinen GitHub-työnkulku ei takaa automaattista lint- tai testiajoa tavalliselle commitille tai pull requestille. Liitä siksi paikalliset tulokset katselmointiin. Riippumaton arviointi tarkistaa myös salaisuudet, tenant-rajan, palautussuunnitelman ja sen, ettei muutos laajenna deploy-oikeuksia.

Jos muutos koskee ydinreittejä, SSR:ää, serverless-konfiguraatiota, GitHub-työnkulkua, pakettipintaa, shell-skriptiä tai staattisia resursseja, @petrosoft-fi-hyväksyntä kuuluu tiedostokohtaiseen omistajuuteen. GitHubin haarasuojausasetukset ratkaisevat, onko hyväksyntä teknisesti pakollinen; pelkkä CODEOWNERS-tiedosto ei yksin todista suojausta.

Käynnistä hyväksytty deploy

Lisää [deploy] vain erikseen hyväksytyn julkaisun commit-viestiin ja pushaa commit nykyiseen kohderefiin. Työnkulku tunnistaa täsmälleen tämän merkinnän. Vanhan ohjeen ilmaus ”tai vastaava deploy-merkintä” ei pidä paikkaansa nykyisessä toteutuksessa.

Deploy-job asentaa riippuvuudet, luo reittikartat, johtaa tenantin ja vaiheen refistä, validoi hallinnan alkuperän, ottaa OIDC:llä AWS-roolin ja tarkistaa tenantin suhteessa serverless.yml-asetukseen. Sen jälkeen se rakentaa asiakasosan, ajaa lintin ja testit, rakentaa palvelinosan, synkronoi staattiset resurssit S3:een, suorittaa Serverless-julkaisun, päivittää asset-manifestin ja käynnistää resurssien kierron.

Älä käynnistä deployta uudelleen ennen kuin ensimmäisen ajon tila on selvä. Työnkulun concurrency-asetus ei peruuta käynnissä olevaa saman ref-ryhmän ajoa, joten uusi pyyntö voi jonoutua.

Seuraa ajoa ja pysähdy virheeseen

Seuraa GitHubin työnkulusta jokaisen vaiheen tulosta. Lint- tai testivirhe pysäyttää työn ennen varsinaista Serverless-julkaisua. Myös puuttuva ympäristömuuttuja, OIDC- tai IAM-roolivirhe, tenantin ja serverless.yml-asetuksen ristiriita, build-virhe, S3-siirto, Serverless tai resurssien kierto voi keskeyttää ajon.

Tallenna epäonnistuneen vaiheen nimi, commit, refi, tenant, ajon tunniste ja virheilmoitus. Älä korjaa infrastruktuurivirhettä muuttamalla tenantin nimeä tai laajentamalla IAM-oikeutta arvaamalla. Vie OIDC-, IAM-, S3-, CloudFormation- ja ympäristövirheet infrastruktuurin omistajalle.

Onnistunut job ei vielä todista liiketoimintapolkua. Tee hyväksytty julkaisun jälkeinen smoke-testi kohdeympäristössä ja dokumentoi tulos. Käytä palautussuunnitelmaa, jos asiakkaan kriittinen polku on rikki.

Hallitse lokit ja uudet ympäristöt erikseen

AI Commerce -storefrontin CI/CD-ohje ei määritä Lambda-lokien säilytysaikaa. Älä pienennä retentiota tai poista lokiryhmiä tämän ohjeen perusteella. Lokien säilytys on tietoturva-, kustannus-, auditointi- ja tietosuojapäätös, joka tehdään infrastruktuurin omistajan kanssa IaC-määrittelyssä.

Uusi tenant tarvitsee vähintään hyväksytyn GitHub Environmentin, salaisuudet ja muuttujat, tenanttiin rajatun AWS-roolin, storefront-bucketin, Serverless-asetuksen, hallinnan alkuperän ja käyttöoikeudet. Pelkkä <tenant>-dev- tai <tenant>-prod-niminen haara ei luo näitä resursseja eikä todista eristystä.

Pidä tenant-rajan todisteena AWS-roolin luottamus- ja oikeuspolitiikka, GitHub Environmentin suojaus sekä toteutunut kohderesurssi. Älä lupaa, ettei toinen kehittäjä voi vaikuttaa naapuriympäristöön, ennen kuin nämä asetukset on auditoitu.