Add proper Migrations to database

[luksamuk]

(This development ashould only end after the discussion and implementation on multi-tenant approach is finished. Database migrations should be generated taking tenant fields into account.)

Currently, the project uses GORM for modelling the database, but migrations occur by using the AutoMigrate process on the related microservice. This is not healthy behaviour nor is it organized.

It is imperative to research the proper tool for creating migrations, and also the best way to handle them on a microservices approach, or even replace GORM with something else entirely, provided that it would be more robust.

A few links related to the discussion:

• Atlas, a way to manage migrations: https://atlasgo.io
  • GORM bits: https://atlasgo.io/guides/orms/gorm
• Ent, an entity framework for Go (could replace GORM): https://entgo.io

[luksamuk]

This article may come in handy: https://codefresh.io/blog/database-migrations-in-the-era-of-kubernetes-microservices/

Long story short, it recommends a different lifecycle for performing migrations. This could mean the return of the RUNONCE "service" from the Rust version, though this time it will probably be more flexible. Perharps having a Job definition would not be so bad at all, since Golang programs tend to be quick to compile and run.

[luksamuk]

Migrations are being handled with Atlas, after all. The tool is very decent, and using it on plain Alpine Linux works like a charm.

So far everything seems to be working, but I still need to sort out the tenant issue before merging this. There is no way that we can do an initial database migration without having a column for tenant_id, if so needed.

[luksamuk]

Await merge of #7

[luksamuk]

Continuing with this project since #7 has been merged.