New directory structure for altinn studio

[mijohansen]

Description

Altinn Studio started with a single team and a mono repo and have lately split into several teams with their dedicated parts of the system. This leaves us with a directory structure that no longer is optimal for the Studio Team and the parts of the code they are working with. Therefore we are suggesting a new directory structure to more closely resemble how our product is structured.

MOVE to other repos

OLD	NEW (repo)	Comment
src/Altinn.Apps/AppTemplates/ProcessTemplates	altinn-studio-docs	Team Studio (only examples)
src/Altinn.Apps/KubernetesWrapper/	-	Team Apps
src/Altinn.Common/Altinn.EFormidlingClient	-	Team Apps #131
src/Altinn.Common/Altinn.Common.AccessToken	altinn-accesstoken	Team Platform #9499
src/Altinn.Common/Authentication	Altinn/altinn-authentication/pull/151	Team Auth
src/Altinn.Platform/	-	Team Platform
src/studio/AppTemplates/	app-template-dotnet	Team Studio #9443 #3647
src/test/K6/	?	Team Platform / Team Apps
src/test/Postman/	-	Will be deleted #9535
src/development/LocalTest/	?	#9485 Its not so clear that LocalTest should live in the Altinn Studio repo

Restructure inside altinn-studio

OLD	NEW	Comment
src/development/docker-compose.yml	docker-compose.yml	One compose to rule them all
src/development/loadbalancer/	development/loadbalancer/	#9433
src/studio/docker-compose.yml	docker-compose.yml	One compose to rule them all
src/studio/src/designer/backend.Tests/	backend/studio/test/	#9467
src/studio/src/designer/backend.Tests/_TestData/	testdata	#9467
src/studio/src/designer/backend/	backend/studio/src/	#9467
src/studio/src/designer/datamodelling.Tests/	backend/datamodelling/test	#9467
src/studio/src/designer/datamodelling.Tests/_TestData/	testdata	#9467
src/studio/src/designer/datamodelling/	backend/datamodelling/src	#9467
src/studio/src/designer/frontend/	frontend/	#9442
src/studio/src/load-balancer/	development/loadbalancer/	#9433
src/studio/src/repositories/	gitea/	-
src/test/cypress/	frontend/cypress	#9442

Additional Information

No response

Tasks

No response

Acceptance Criterias

No response

[nkylstad]

src/Test/K6 and src/Test/Postman seem to be a mix of tests for Studio, Apps and platform. Suggest that we do a review of which of these tests to keep for Studio, although this is something we can so separately.

[mijohansen]

src/Test/K6 and src/Test/Postman seem to be a mix of tests for Studio, Apps and platform. Suggest that we do a review of which of these tests to keep for Studio, although this is something we can so separately.

Guess that enforces why its important to keep tests close to the code they are supposed to test, and not siloed away? Think the best way to proceed there would be to isolate our tests. I am also not sure that we need K6-tests on Altinn Studio (like ever)... we know that at some load we would break the system, but what would we do with that information? Do we want to optimize for 1000 of thousands of simultanious users at this point of development? Or is that premature?

[mijohansen]

It actually looks like none of the K6-tests are for studio... so atm they are fare, fare away from the code they are supposed to test.

[altinnadmin]

Split table in two to make it more readable. @mijohansen Should we rename loadbalancer ==> nginx, same as repos ==> gitea ? Be more explicit?

Only remaining now is getting datamodelling and backend with tests in shape.

[mijohansen]

I guess when we are discussing "gitea" we are using the term "gitea", while when discussing the loadbalancer we mostly referre to it as "loadbalancer", so that was the reasoning about the naming.

[olemartinorg]

Isn't LocalTest just a local mock/simple replacement of the platform services used to run an app? I don't see how that belongs in the studio repo, and especially not how it belongs in the shared docker-compose file. I guess I can see the need to run it when previewing an app, but remember that LocalTest is mostly run by (external) apps developers, which have no need for running Studio locally.

[mijohansen]

@olemartinorg that depends on distribution strategy for localtest. The way I see it development of the tools that is needed to do development of Altinn Apps resides in the altinn-studio-repo. Localtest is one of them. The issue is that we that develop the tools that is needed to develop Altinn Apps sometimes/often need to switch between developing localtest and develop altinn studio. That is why we want to be able to run these in parallell instead of having to stop docker compose for studio and start the one for localtest.

For an app developer that doesn't want to change altinn-studio or localtest, checking out altinn-studio should be unnecessary. Ideally localtest should be startet through the app you are developing, not needing to deal with this repo at all. Untill we have a better solution, starting localtest with something like docker compose -d localtest should be an ok solution. We could probably just distribute localtest through dockerhub and make a docker compose/ readme change to the app-template.

[altinnadmin]

For an app developer that doesn't want to change altinn-studio or localtest, checking out altinn-studio should be unnecessary.

Yes, for most app developers that is true, but wouldn't it be extremely cool for "power app devs" to be able to run Studio Designer locally, and have the cloned repos that Designer is working against locally, AND be able to use vscode on the same clone locally.

Then devs can avoid the "ping-pong" when working locally and in Studio on the same app.

The question is: Could we get this working while Designer locally is still talking to altinn.studio/repos in the cloud? Then we'd be golden, and this could be extremely efficient.

//cc: @nkylstad @FinnurO