Improved trunk-based development

[altinnadmin]

Description

Currently we're doing feature-branches, testing locally and then merging them into master before testing in a test environment, and then deploying to production once a week.

This causes problems:

1. If we suddenly need to hotfix to production, we can risk that also untested code in master is deployed.
2. If two or more PRs are merged to master at the same time, we have several changes in master that are not tested, in worst case influencing each other.
3. Hotfixes are something "special" and "extraordinary", instead of just being the normal flow of continous changes.
4. The once-a-week deploys are "special", an event, instead of all changes just flowing continously, also to prod.

In scope

Improving our continous DevOps-flow so that we always can deploy from trunk with no fear.

Out of scope

What's out of scope for this analysis?

Analysis

There seems to be 3 ways we can go:

1. Test feature-branches in separate containers running in parallell with existing containers in existing environments.
2. Test feature-branches in its own environment that can be spinned up automatically.
3. Make it possible to deploy a feature-branch to production, containing only the code changes for the hotfix.

The first way seems like the way we want to go. This approach can also be used when testing apps deployed from Altinn Studio.

The second way can difficult to achieve, especially as long as we have Altinn 2 as a dependency and seperate clusters for Apps and Platform. Spinning up new clusters will also take time.

The third is easier, but seems like a temporary solution, only fixing the first problem listed. So dropped.

Solutions worth investigating:

• Deploying containers with Git short-hash as part of the container name.
  • Should work perfectly for apps in tandem with Branching: User experience in Altinn Studio #985, f.ex. https://ttd.apps.tt02.altinn.no/ttd/my-test-app-b6a97a4
  • Traefik middleware might be the solution for our Platform microservices, perhaps having the hash as an optional http header?
  • Add new pipeline/action for triggering deploy of branch from GitHub PR
• Linkerd canary release and Flagger. Seems good for A/B, but perhaps not this?

Conclusion

Deploying branches as separate containers in parallell seems like the way forward.

Tasks

• Is this issue labeled with a correct area label?
• QA has been done

[lvbachmann]

To be discussed in tech forum

[lvbachmann]

Goal for sprint: Identify and prioritise concrete measures as issues.

[lvbachmann]

To be reiterated in tech forum

[nkylstad]

I'm closing this issue now, since nothing new has come up here for a long while.
For Studio, this is something we work on continuously, and we will create issues when we see that we need them. We are running our e2e-tests in local containers that are spun up for each PR. Hotfixes are done as needed, and we have a production branch for just this need. We have bi-weekly deploys and are working towards continuous deploy.