Ecomm UI

Frontend for Sunrun's ecommerce site (solar, battery, EV charger, etc.), and Ford EV charger installation.

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying pages/index.tsx. The page auto-updates as you edit the file.

Environments

| Landing Page | Development | Staging | Production | | ------------ | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------- | | eComm | devmaj-shop.sunrundev.com/solar/ | majstg-shop.sunrun.com/solar/ | shop.sunrun.com/solar/ | | Ford | devmaj-shop.sunrundev.com/ford/ | majstg-shop.sunrun.com/ford/ | shop.sunrun.com/ford/ |

Testing

Unit tests

Any code that contains significant business logic or conditions should be covered by unit tests in a file that lives next to it (ie, the unit tests for src/components/Foo.tsx should live in src/components/Foo.test.tsx). You can run unit tests by calling:

npm test

Unit tests are run as a pre-commit hook.

Storybook component test

create your file under the folder /stories and import your component to test then run:

npm run storybook

End-to-end tests

End-to-end tests are located in the tests/e2e folder, and named witih the format <section>.<element>.spec.ts (ie, tests/e2e/foo/foo.button.spec.ts). Tests are written using the Playwright testing library, and will hit the URL that corresponds to the ENV_NAME environment variable. To run tests against your local instance of Chrome, make sure the site is being served locally and run:

npm run test:e2e:local

If you want to run the integration tests against a full suite of browsers, make sure the site is being served locally and run:

npx playwright install # only need to run this if you haven't done so already
npm run test:e2e

You may find that as we add more tests and browsers, request latency builds up and causes test failures. If so, choose the browser that you want to test from the project names in the configuration file, and supply it as the project attribute in the command:

npm run test:e2e -- --project=chrome

To hit a given environment, add it as the ENV_NAME environment variable in the command:

ENV_NAME=devmaj npm run test:e2e -- --project=chrome

To run in debug or inspect mode:

npm run test:e2e:local:debug // Allows you to see tests as they run, optionally stepping through

npm run test:e2e:inspect // Allows you to inspect the DOM as Playwright sees it

CI/CD Process

Deploys run automatically via the website deploy Github Action after a PR is merged to the develop, release, or master branch.

Branching Strategy

| Branch Type | Branch From | Merge To | Naming Convention | Environment | | ----------- | ----------- | ----------------- | -------------------------------------------------------------------- | ----------- | | Feature | develop | develop | feature/JIRA#-titledescription e.g feature/MARCD-363-contentful-root | local | | Bugfix | develop | develop | fix/JIRA#-titledescription | local | | Hotfix | master | release & develop | hotfix/JIRA#-titledescription | local | | Develop | master | release | develop | development | | Release | develop | master | release{SEMVER} e.g. release1.0.1 | staging | | Master | - | - | master | production |

Lifecycle of a Feature

1. Pull changes into the develop branch, to make sure it is up-to-date.
2. Create a feature branch from develop, and work on it locally.
3. When completed, create PR to merge to develop. Must receive two approvals before merging.
4. Merge to develop branch to deploy to the development environment. Send to QA or design if a review is necessary.
5. After approval, create a PR of develop into the current release. The release branch will contain all the features and fixes that are ready to be released into production.
6. QA can perform end-to-end tests of releases. The team will coordinate with QA to test and release code into production. This will be done with a PR from release to master.
7. After a production release, merge all changes into develop, so it can stay up-to-date with master.

Bugfix vs. Hotfix

A hotfix is a bugfix that needs to be released into production as soon as possible. It should be merged into both a release branch and develop.

Release branches

There may exist more than one release branch at a time. Generally, one for the current release being developed, and another for testing hotfixes in stage before deploying to production. With the use of Github labels, we can control which release branch is deployed to the staging environment.

Pre-existing Branches

The master, release, and develop branches should pre-exist, and do not need to be created by the developer.

Learn More

To learn more about Next.js, take a look at the following resources:

• Next.js Documentation - learn about Next.js features and API.
• Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Disaster Recovery

Please read the disaster recovery plan.