Flyt - (aka VSM/Value Stream Mapping)

Links

• 🌱 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)

Background

Mission statement: Empower everyone on all levels to improve the way we work - process by process

Tech stack

	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

Developing

To get up and running, run:

yarn && yarn use-dev

Running different environments locally

Env.	command
DEV	yarn use-dev
TEST	yarn use-test
QA	yarn use-qa
PROD	yarn use-prod

Branching and deploying stuff

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

Docker

# 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

Runtime environment variables

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.

Read more ...

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 ...

Semantic Commit Messages

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

Example

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:

• https://www.conventionalcommits.org/
• https://seesparkbox.com/foundry/semantic_commit_messages
• http://karma-runner.github.io/1.0/dev/git-commit-msg.html