---
# System prepended metadata

title: Wasserbauer - Improvements

---

# Wasserbauer - Improvements
~ Thought collection

## RVM

#### Current Solution Cons:
- FTP based with single authentication scheme
- Data Abstraction via plain XML files which tend to get corrupted from time to time
- Artifacts are also stored on the FTP server in another directory
- Backup solution which just zips the xml files and reuploads them (to the same server)

#### Possible Solution:
- Seperate abstraction and artifacts
    - Abstraction (users, projects, versions) belong in a database (e.g. mariadb)
    - Artifacts (installers, application, binaries) belong in an object storage (e.g. minio)
- Create a simple user/role based authentication scheme
- Write a modern REST interface for manipulating all abstraction data and retrieving/storing new artifacts to the object storage
- the basic frontent applications can stay the same, but the abstraction layer has to be adopted (https based interface instead of plain old ftp)
- (Optional) Create a dashboard for maniging accesses, project relations, version changelogs... . This can easily be added due to the fact that REST can be used by any application regardless if its a web r a desktop application.

#### Benefits:

- We already implemented similar stacks multiple times -> experience + fast results
- Universal accessability due to usage of a REST api pattern (can be easily integrated into other products)
- No more version corruptions (db-patcher + ORM)
- No more classical RVM problems like char encoding or resource locking which were often caused by FTP misbehaviour or local XML parsing bugs
- No local abstraction logic
- State of the art framework usage for building the interface

## Gitlab CICD

Ment to be integrated by Alex, who is now gone :(

What pipelines can do:

- Build artifacts (installers, application, binaries) and store them in an object storage
- Run tests (unit, acceptance, e2e and compatibility tests)
- Deploy to any running system which is accessable over the internet

Typical workflow:

- Commit by a developer automatically creates a cicd job
- A idling Gitlab Runner picks up the job and starts the pipeline:
    1. The repo is cloned (containing the new changes)
    2. Tests are executed which ensure that the new changes broke nothing
    3. If the tests succeeded, a build script is executed
    4. The build artifacts get uploaded to an object storage for further distribution and persistence
    5. An optional deployment to a production (or test) system is performed
- Cleanup after build + runner switches back into idle mode

What's needed:

- Gitlab Runners
- YAML files describing the pipelines

What's possible besides the above:

- Automated daily/weekly tests
- Cross compatibility tests
- Auto releasing cycles