1. Background and objective

1. Improves code integrity: all builds and deployments are done through GitHub Actions, so errors in the local developer environment do not directly end up in production.
2. Centralized permissions management: Developers no longer need separate AWS IAM permissions. GitHub is connected to AI Commerce AWS accounts using a secure OIDC publishing model.
3. Tenant restriction: each branch is tied to a specific tenant, so only the development team of that tenant can bring code to production.
4. Automated tests and analysis: new and modified code goes through unit and integration tests, linter checks, and possibly an AI-based PR review (CodeRabbit).

2. GitHub branches and IAM permissions

• Each tenant (online retailer or partner) gets its own GitHub branch.
• Developers with write access to this branch can commit code.
• When you want to push your code to production, add [deploy] to the commit message, which will cause GitHub Actions to detect the deploy request and trigger the release.
• Behind the scenes, the GitHub Action pipeline is role-played with AWS IAM policies:
  • Pipeline checks that branch = "adidas-dev" (example) → pipeline uses ps-github-deployer-adidas role → only for resources in ledstore tenant.
  • This ensures that no one else can deploy to another tenant's environment.
• Please request a new branch from @petrosoft-fi user (CodeOwner) if you need a completely new tenant. Please provide reasons (merchant, project name, etc.) via email or ticket system.

3. Build and test phase

3.1 CI: Committee Inspection

1. Linters (ESLint, svelte-check, etc.) check the code for syntax, unnecessary imports, and potential logic errors.
2. Unit tests (Vitest, etc.) ensure that the application modules behave as expected in isolation.
3. Integration tests simulate the most important usage paths (e.g. adding a product card to the shopping cart, logging in, etc.).
4. A possible artificial intelligence-based PR review (CodeRabbit AI) reads PRs and provides correction suggestions.

If even one step fails (lint error, red test result), the deploy stops.
→ Check the GitHub Actions log to see what went wrong, fix the code, and commit again.

3.2 Manual testing

While automated tests cover a large portion, it's important to test your local environment before committing. Tests may not cover store-specific logic. So, review key paths (e.g., the "Add product to cart" path) to make sure your addition works as expected.

4. Deploy process

1. Commit the code to your branch ( <tenant>-dev or <tenant>-prod ) and append [deploy] or a similar deploy tag to the commit message.
2. GitHub Actions detects deploy tags in the commit message and starts the pipeline:
   • Lint and test phases
   • If everything is OK, we move on to the deploy phase, where sls deploy is run from GitHub.
3. Serverless only updates AWS resources named <tenant> → role-based ensures that resources in neighboring branches are not affected.

If the deploy fails, you will see an error in the GitHub Actions log. Typical errors:

• Test Fail: a Vitest statement failed.
• Lint: code style error, ESLint linter failed.
• Missing IAM permission: You are trying to modify a resource that your role does not allow.
• CloudFormation: The resource is missing or has been manually modified and the stack is inconsistent.

5. CodeOwners and restricted files

• Certain core project files (e.g. SSR source codes, serverless core configurations) are locked by the CodeOwner requirement.
• Their modification must be made as a Pull Request, which must be approved by the CodeOwner team.
• Only CodeOwners can add or remove critical parts of the serverless source code and create new environments (branches).

6. How to start working

1. Request code permissions for your own branch: tenantname-dev .
2. Clone the repo and do development in a local environment.
3. Run locally: npm install → npm run dev → test …
4. Commit normally → GitHub Actions will run linters and tests.
5. Start the production deployment by adding [deploy] to the commit message.
6. Follow the GitHub Actions page to see if the build + deploy was successful.
   • In case of an error, check the log, fix the code and commit again.

7. Frequently Asked Questions

Q: How do I get a new branch (tenant)?

A: Send a request to @petrosoft-fi (or another CodeOwner). Tell them what the branch is for.

Q: Can I prevent Lambda from collecting log data?

A: Not recommended, but you can reduce the retention (e.g. 1 day). We don't want to prevent Lambda from generating default logs because it breaks CloudFormation management.

Q: Why is [deploy] needed in the commit message?

A: GitHub Actions is configured to detect the markup that triggers the official deploy. Otherwise, it will only run the test steps.

8. Summary

This model keeps the code quality high (autom. tests, linters, AI-review) and separates local differences between developers from the actual production routines. The resources of each merchant (tenant) are limited to the developers of that branch. This way, no external or developer from another tenant will accidentally break your store instance.

Key points for partners:

• Make sure your tests and linters pass before committing the [deploy] entry.
• Also test the local environment manually, especially store-specific special functions.
• If you need a new tenant or need to edit a file locked by CodeOwner, make a PR and request approval from CodeOwner.