Ensure we have a good deployment flow that includes chores

[arealmaas]

Introduction

Things get pretty messy when we have code and infra in the same repo and same releases, and we only trigger releases aka deployments when we add a fix/feat. This leaves chores that should maybe be pushed straight out to all environments stale until a new fix/feat is added.

How do we ensure that we have a good insight into all changes into our system, and at the same time ensure that we are deploying chores at the frequency we want.

Description

Some thoughts:

• Split versions of app and infra: A feat in infrastructure might not be something that will hit an end-user which makes it an uninteresting entry in a changelog. However, for us internally, it would be very beneficial to add that new infrastructure-feature in our changelog. Maybe consider splitting this? Another example: If we have a version 1.32.0 which has app changes, versions 1.33.0, 1.34.0 has only infra changes, version 1.35.0 has app changes, then the app deployment would jump straight from 1.32.0 to 1.35.0.
• Ensure chores are deployed: We need to ensure that chores are deployed without having to wait for a feat/fix. We could include chores in our changelog as "Other chores", bump the version with a sha or an RC-version, and create a release based on that.
• **Splitting infra and apps to separate repos 😬 **: The workflows has become quite complex as we have to deal with both infra and app deployments. We have to resolve what to deploy based on which files has changed, and for staging/prod which files has changed since the last version deployed. The solution for this now is to store released version number as a gh-variable so we can extract which version number is actually deployed in that environment. This requires a PAT for now which is unfortunate.

Implementation

Tasks

Beta Give feedback

1. Implementation tasks are added here
2. Prepare documentation (if relevant - either update working document, or add a new file in docs)
3. Add e2e-test (if relevant)

Threat modelling

Beta Give feedback

1. Does this change introduce any potential security issues?

Acceptance criteria

GIVEN ...
WHEN ....
THEN ...

GIVEN ...
WHEN ....
THEN ...