1. Tausta ja tavoite

1. Parantaa koodin eheyttä: kaikki buildit ja tuotantoon vienti (deploy) tapahtuvat GitHub Actionin kautta, jolloin paikallisen kehittäjän ympäristön virheet eivät suoraan päädy tuotantoon.
2. Keskitetty oikeuksienhallinta: kehittäjät eivät enää tarvitse erillisiä AWS IAM‑oikeuksia. GitHub on kytketty AI Commercen AWS‑tileihin suojatulla OIDC‑julkaisumallilla.
3. Tenant‑rajaus: jokainen haara (branch) on sidottu tiettyyn tenanttiin, joten vain kyseisen tenantin kehittäjätiimi voi tuoda koodeja tuotantoon.
4. Automatisoidut testit ja analyysit: uudet ja muokatut koodit käyvät läpi yksikkö‑ ja integraatiotestejä, lintteritarkistuksia ja mahdollisesti tekoälypohjaisen PR‑review’n (CodeRabbit).

2. GitHub‑haarat ja IAM‑oikeudet

• Jokainen tenant (verkkokauppias tai yhteistyökumppani) saa oman GitHub‑haaransa (branch).
• Kehittäjät, joilla on kirjoitusoikeudet tähän haaraan, voivat commitoida koodia.
• Kun haluat viedä koodit tuotantoon, lisää commit‑viestiin [deploy], jolloin GitHub Actions havaitsee deploy‑pyynnön ja käynnistää julkaisun.
• Taustalla GitHub Action‑pipeline roolittuu AWS IAM‑politiikoilla:
  • Pipeline tarkistaa, että branch = "adidas-dev" (esimerkki) → pipeline käyttää ps-github-deployer-adidas‑roolia → vain ledstore‑tenantin resursseihin.
  • Näin varmistetaan, ettei kukaan muu pysty deployaamaan toisen tenantin ympäristöön.
• Pyydä @petrosoft-fi‑käyttäjältä (CodeOwner) uutta haaraa, jos tarvitset täysin uuden tenantin. Perustelut (kauppias, projektin nimi tms.) sähköpostilla tai tikettijärjestelmässä.

3. Build‑ ja testivaihe

3.1 CI: kommittien tarkastus

1. Lintterit (ESLint, svelte‑check jne.) tarkistavat koodin syntaksin, turhat importit ja potentiaaliset logiikkavirheet.
2. Yksikkötestit (Vitest tms.) varmistavat, että sovelluksen moduulit käyttäytyvät odotetulla tavalla erillisinä.
3. Integraatiotestit simuloivat tärkeimpiä käyttöpolkuja (mm. tuotekortin lisääminen ostoskoriin, sisäänkirjautuminen tms.).
4. Mahdollinen tekoälypohjainen PR‑review (CodeRabbit AI) lukee PR:t ja antaa korjausehdotuksia.

Jos yksikin vaihe epäonnistuu (lint‑virhe, testin punainen tulos), deploy pysähtyy.
→ Tarkista GitHub Actions‑lokista, mikä meni pieleen, korjaa koodi ja commitoi uudestaan.

3.2 Manuaalinen testaus

Vaikka automaattiset testit kattavat ison osan, on tärkeää testata lokaalia ympäristöä ennen commitointia. Testit eivät välttämättä kata kauppakohtaisia erikoislogiikoita. Käy siis läpi keskeiset polut (esim. ”Lisää tuote ostoskoriin” ‑polku) varmistaaksesi, että lisäyksesi toimii odotetulla tavalla.

4. Deploy‑prosessi

1. Komittoi koodi haaraasi (<tenant>-dev tai <tenant>-prod) ja liitä commit‑viestiin [deploy] tai vastaava deploy‑merkintä.
2. GitHub Actions havaitsee deploy‑tagit commit‑viestissä ja aloittaa putken:
   • Lint‑ ja testivaiheet
   • Jos kaikki on OK, siirrytään deploy‑vaiheeseen, jossa sls deploy ajetaan GitHubin puolelta.
3. Serverless päivittää vain <tenant>‑nimisiä AWS‑resursseja → roolitus varmistaa, etteivät naapuribranchin resurssit kärsi.

Jos deploy epäonnistuu, GitHub Actions‑lokista näet virheen. Tyypillisiä virheitä:

• Test Fail: jokin Vitest‑lauseke epäonnistui.
• Lint: koodityylivirhe, ESLint‑lintteri ei läpäisty.
• IAM‑lupa puuttuu: yrität muokata resurssia, johon roolisi ei salli.
• CloudFormation: resurssi puuttuu tai sitä on muokattu käsin ja stack on epäkonsistentti.

5. CodeOwners ja rajoitetut tiedostot

• Tietyt projektin ydintiedostot (mm. SSR‑lähdekoodit, serverless‑ydinkonfiguraatiot) on lukittu CodeOwner‑vaatimuksella.
• Niiden muokkauksesta pitää tehdä Pull Request, jonka CodeOwner‑tiimi hyväksyy.
• Vain CodeOwnerit voivat lisätä tai poistaa serverless‑lähdekoodin kriittisiä osia ja luoda uusia environmentteja (haaroja).

6. Näin aloitat työskentelyn

1. Pyydä koodioikeudet omalle haarallesi: tenantname-dev.
2. Kloonaa repo ja tee kehitystyöt lokaaliin ympäristöön.
3. Aja paikallisesti: npm install → npm run dev → testaa …
4. Komitoi normaalisti → GitHub Actions ajaa lintterit ja testit.
5. Käynnistä tuotantoonvienti lisäämällä commit‑viestiin merkintä [deploy].
6. Seuraa GitHub Actions‑sivulta, onnistuiko build + deploy.
   • Virhetilanteessa katso loki, korjaa koodi ja commitoi uudestaan.

7. Usein kysytyt kysymykset

Q: Miten saan uuden haaran (tenantin)?

A: Lähetä pyyntö @petrosoft-fi‑käyttäjälle (tai muulle CodeOwnerille). Kerro, mihin tarpeeseen haara tehdään.

Q: Voinko estää, ettei Lambdan lokidataa keräänny?

A: Ei suositeltavaa, mutta retentiota voi pienentää (esim. 1 vrk). Emme halua estää Lambdan oletuslogien luomista, koska se rikkoo CloudFormationin hallintaa.

Q: Miksi commit‑viestiin tarvitaan [deploy]?

A: GitHub Actions on konfiguroitu tunnistamaan merkinnän, joka käynnistää virallisen deploy’n. Muutoin se ajaa vain testivaiheet.

8. Yhteenveto

Tämä malli pitää koodin laadun korkealla (autom. testit, lintterit, AI‑review) ja erottaa kehittäjien lokaalit erot varsinaisista tuotantorutiineista. Jokaisen kauppiaan (tenantin) resurssit on rajoitettu juuri sen haaran kehittäjille. Näin kukaan ulkopuolinen tai toisen tenantin kehittäjä ei vahingossa riko kauppasi instanssia.

Avainkohdat partnereille:

• Huolehdi testien ja lintterien läpäisystä ennen [deploy]‑merkinnän commitointia.
• Testaa lokaalia ympäristöä myös manuaalisesti, etenkin kauppakohtaiset erikoistoiminnot.
• Jos tarvitset uuden tenantin tai joudut muokkaamaan CodeOwner‑lukittua tiedostoa, tee PR ja pyydä CodeOwnerin hyväksyntä.