- 🌱 Internal repo
- 📥 Bug and feature tracker
- 🔢 Feature backlog (and prioritisation)
- 🎨 Figma design & prototype
- ⚡ API endpoints
- 💫 Development process
- 🏃 Running in Radix
- 📝 Architecture contract (old) / Architecture contract (new)
Mission statement: Empower everyone on all levels to improve the way we work - process by process
Comment | |
---|---|
Language | TypeScript |
Library | React |
Framework | Next.js |
Process renderer | React Flow |
State management | EasyPeasy |
Linting | ESLint |
Code-Style | Prettier |
Authentication | @azure/msal-react |
Styling | Sass |
Package manager | Yarn |
To get up and running, run:
yarn && yarn use-dev
Env. | command |
---|---|
DEV | yarn use-dev |
TEST | yarn use-test |
QA | yarn use-qa |
PROD | yarn use-prod |
The main
-branch contains the latest changes.
To release you you run one of the following scripts:
Environment | Release script | Deploy status | URL | Who should test what? | Comments |
---|---|---|---|---|---|
DEV | yarn release-dev |
dev.flyt.equinor.com | Developer | Developer is free to use this environment however they want to | |
TEST | yarn release-test |
test.flyt.equinor.com | Internal testing | Developer tags what needs to be tested for QA-tester in the team | |
QA | yarn release-qa |
qa.flyt.equinor.com | "Product Owner" or Customer | When said feature is ready, it gets released into QA so our PO can give feedback | |
PROD | yarn release-prod |
flyt.equinor.com | End-users | We wait with deploying to prod until everyone is happy |
# Building image
docker build -t equinor-flyt .
# Running image
## Dev
docker run -p 3000:3000 --env-file ./environment-variables/DEV.env equinor-flyt
## Test
docker run -p 3000:3000 --env-file ./environment-variables/TEST.env equinor-flyt
## QA
docker run -p 3000:3000 --env-file ./environment-variables/QA.env equinor-flyt
## Prod
docker run -p 3000:3000 --env-file ./environment-variables/PROD.env equinor-flyt
When using Next.js, the environment variables need to be set when building the image and not at runtime.
Generally you'll want to use build-time environment variables to provide your configuration. The reason for this is that runtime configuration adds rendering / initialization overhead and is incompatible with Automatic Static Optimization.
To work-around this we are disabling "automatic static optimization" at our root level. Adding this to _app.tsx
:
MyApp.getInitialProps = async (appContext: AppContext) => {
const appProps = await App.getInitialProps(appContext);
return { ...appProps };
};
Which disables "automatic static optimization" for all our pages. Read more ...
Copied from https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
feat: add hat wobble
^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
More Examples:
feat
: (new feature for the user, not a new feature for build script)fix
: (bug fix for the user, not a fix to a build script)docs
: (changes to the documentation)style
: (formatting, missing semi colons, etc; no production code change)refactor
: (refactoring production code, eg. renaming a variable)test
: (adding missing tests, refactoring tests; no production code change)chore
: (updating grunt tasks etc; no production code change)
References: