Umstrukturierung der CI für Production Branch und Version Checking

slobinger
2017-09-14T12:37:16Z

# Grundsätzliche Annahmen

1. Die Version des Python-Paketes entspricht der Version eines eventuell zu bauenden Debian-Paketes
ohne eventuelle tilde.
2. Die zu bauende Version in alle Branches ist neuer als die des letzten Builds im production Brnach.
3. Wird ein commit getagged, ist es ein Releas und geht in production. Der tag name ist gleich der
Debian-Paketversion.
4. Die Version eines zu bauenden Paketes in einem Feature-Branch ist neuer als die im Master-Branch
5. Die aktuellste produktiv einsetzbare Version lässt sich immer über den gleichen API-Aufruf holen ohne Kenntnis über die aktuelle Versionsnummer.

# Notwendige Änderungen

Die .gitlab-ci.yml muss an einigen Stellen angepasst werden, damit alle diese Annahmen auch tatsächlich zutreffen.

1. Eine saubere Trennung zwischen build, test und deploy ist sinnvoll.
- Im Build-Stage wird das Paket gebaut. Dabei können Unittests statt finden
- Im Test-Stage wird das Paket getestet. Hier wird auch die Versionsnummer geprüft.
Außerdem kkönnten Hier Funktionstests oder Integrationstest laufen.
- Im deploy-Stage wird lediglich bereitgestellt. Deploy-to-production pusht den aktuellen code in
production oder deploy-deb-releas stellt ein artifakt des Debian-Paketes im Release Stadium bereit.
2. Die Versionsnummerüberprüfung wird in den passenden Jobs im test stage durchgeführt.
3. Das Debian-Paket-Release findet erst auf Production statt. Dadurch wird eine einheitliche URL für
das Downloaden über die API ermöglicht + es kann auch einfach ein checkout des Produktiven Codes
erfolgen.