Migrate to monorepo setup for Opla project

[mikbry]

See

Yarn Workspaces
https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/

https://hackernoon.com/one-vs-many-why-we-moved-from-multiple-git-repos-to-a-monorepo-and-how-we-set-it-up-f4abb0cfe469

[licarth]

About merging front and backend. (not zoapp for now, no libs)

Benefits

saves precious development time

• avoid .circleci/config.yaml duplication.
• make PR / changes easier and easier to test (proper e2e testing)
• easier management of certificates, and allows wildcard certificates in an easy-ish way.
• de-duplicates ingress.yaml
• de-duplicates README.md
• makes dev onboarding simpler
• removes the necessity for an infra branch in opla/opla.
• allows easy preview deployments of Pull Requests (link added by a bot in the comments)

makes the app easier to install for users/admins

• allows a single point of entry for someone who wants to deploy opla as an application (who wants only the backend or only the front)

Risks

1 commit for 2 releases. Beware of downtime due to api changes. Every change should be retrocompatible with the previous version(s), between backend and front.
--> good news is that we could automate that testing against version n-1 and/or n-2 of the backend or of the frontend if this becomes a problem, since we have a single repo.

How to proceed

Preparation Phase

• Try it with 2 given commits from front and backend. Fix all the myke.yaml and circleci configs.
• deploy to a singlerepo namespace.
• communicate about changes (show the example repo that deploys to a test namespace)
• Close as many PRs as possible and warn that they will need to be moved.
• Copy issues from front and back to opla

Real transition (to do at night or over the weekend)

• Update code from backend and front with an approach that keeps git history (see https://stackoverflow.com/a/10548919)
• Really deploy to qa, preprod, prod.
• Redirect users from Opla/front and Opla/backend without removing the code.

[licarth]

About commit history

The tricky point is not about moving the code into a single repo, but is about moving the code into subfoldlers (front/ and backend/)

• Commits and SHAs will not get lost and stay the same :
  https://github.com/Opla/backend/commit/d3ea8cb1e159a57823df791dd62323649d5df080
  becomes https://github.com/Opla/opla/commit/d3ea8cb1e159a57823df791dd62323649d5df080.
• Rollback to a point before the merging of the repos will no longer be possible. (which is an argument for doing it early)
• Clicking on History will only show history since the repo merge. This is because github executes git log instead of git log --follow. Gitlab does use --follow. (see Support git --follow to preserve history across renames isaacs/github#900)

Short term github workaround : a chrome extension allows to add an easy link to the history before the file got renamed. Try it yourself with backend/package.json

Locally just run git log --follow <file> instead of git log <file> to get the complete history. To have it at all times : git config log.follow true

Long term fix : upvote this issue.

[mikbry]

Add docker setup and add in /README how to install it

[licarth]

@mikbry Docker like docker-compose (what's in community edition) or docker kubernetes ?

[mikbry]

docker-compose as in community-edition

[licarth]

This is done in #18.