TODO: Link Epic here
❓Unmet needs
The micro services architecture is fine, however it is impacting the time-to-deploy at times. Changes that require manipulation of all repos (submodules) are generally rare, but possible - especially for big maintenance.
Additionally, one example maintenance we can envision in this case is the upgrade of traefik from v1.7.4. to v2.x. Traefik v.1.7.4 reached EOL and it should be replaced asap.
🏹 Objectives
Have a repository structure where a global change does not involve changing multiple repositories.
This could mean: bring the submodules in MyAEGEE adopting a mono repo way of handling the project
It could also mean: create a repository of MyAEGEE that is exclusively for production use
Upgrade traefik to v2.10 and the labels on each exposed container
⚠️ Dev-prod parity
With this change there is a high chance to have parity between production and development highly swaying: for instance, currently our VMs for development run Ubuntu18.04 LTS (and this should be bumped to 20.04), whereas our production machine is running Ubuntu16.04!
Docker version:
This means that a work to implement in production all the changes should happen soon after the development has been completed.
🗺 Previous attempts
See https://github.com/AEGEE/myaegee-nomodules-test. Note: the scope of the repo was for quick infrastructure tests; not for development
🔙 Fallback plan
About point 1a: the worst case scenario is to make repos of the submodules read-only, and remove the submodules + re-adding them, therefore losing history “in-repo” and only reading them by going to the archived module.
↔️ Alternative plan
We could have http://github.com/aegee/myaegee renamed to MyAEGEE-dev; and v2 is simply (like) the one previously tested.
Which has a pro point: why should there be code in production?
🗓 Releases (monorepo way)
No matter what is the path we take, we have to make sure about the following:
there should be a FEATURE FREEZE for all development
The goal for dev-prod parity is set to Saturday night of Autumn Agora i.e. Last weekend of October
The released version will be as following
Service name | Current release | Feature planned before feature freeze | Status | Completed date |
---|---|---|---|---|
core | 1.36.12 | feature flag, releasing 1.37.0 | PR WAITING FOR FEEDBACK | |
MyAEGEE | 0.8 | proper prometheus scripts, releasing 1 ? | IN PROGRESS | |
frontend | 1.34.0 | adding board change to body | WAITING FOR FINAL CHECKS | |
?? | ?? | ?? | TO DO / IN PROGRESS / BLOCKED / PR WAITING FOR FEEDBACK / DONE |
This table means that after releasing v1.37.0 of core, no more code will be checked in/merged and the repo will be frozen. The next changes that can happen is either
MyAEGEE v2 will be a monorepo
MyAEGEE v2 is a different repo
👣 Next steps
- The goal for dev-prod parity is set to Saturday night of Autumn Agora i.e. Last weekend of OctoberSET A STATUS