Technik CI CD

Continious Integration / Continious Deploy - vollautomatisch vom GitCommit auf den ESP -

Als Entwickler ist man faul. Die eigentliche Arbeit als Entwicklung an etwas Neuem macht Spass, aber der ganze Kram am Ende die Neuentwicklung breit zu testen und dann auch noch auf seine Devices auszurollen ist öde, langweilig, Ätzend und macht überhaupt keinen Spass. Dieses hat mich angetrieben einen vollautomatischen Prozess aufzusetzen. Vom Einchecken der CodeÄnderung, bis hin zum Ausrollen dieser Änderung auf einen oder alle meine ESP's.

Folgende Schritt werden und müssen im Einzelnen durchgeführt werden:

1. Einchecken der Code Änderung
2. Aufsetzen einer temporären Entwicklungsumgebung Installation der Board Cores Installation aller notwendigen Libraries Kompilieren des Binaries, der uploadbaren Firmware für den ESP
3. Erstellen des JSON Abschnitts für diese Firmware
4. Hochladen des Binaries und der JSON Datei in die AWS S3 Cloud
5. Generierung des kompletten releases.json files inclusive der neuen JSON Datei

Falls es sich um eine PreLive oder sogar um eine Produktive Stable Version handelt kommen noch folgende Schritte hinzu:

1. Erstellen eines neuen Releases (Prelive oder Prod)
2. Generierung der Releasebeschreibung aus dem Changelog
3. Hinzufügen des Binaries zum Release
4. Generierung eines library Packages und Hinzufügen zum Release
5. Generierung des Quellcode Packages und Hinzufügen zum Release

Um diese einzelnen Schritte automatisch auszuführen wurde der folgende Prozess eingeführt:

Das Ganze funktioniert mit dem folgenden Branching Model. Es gibt es 3 Branches:

• master Branch als Produktivbranch
• prelive Branch als Qualitätssicherung / QS
• development Branch als Entwicklungsumgebung

Entwickelt wird ausschliesslich im "development" Branch. Der master und prelive Branch sind für normale commits/Push über Branch permissions gesperrt. Diese können nur über PullRequests verändert werden.

Sobald ein Git Push in einem Branch eintrifft, wird über die Github Actions der Workflow "BuildAndDeploy" angeworfen. Dieser ist die Klammer über alles und vereint die oben zusammengestellten Schritte. Das Script dazu befindet sich im git Ordner ".github/workflows/BuildAndDeploy.yml".

Nachdem der Workflow die gesamte Entwicklungsumgebung aufgesetzt und den Code kompiliert und das Binary erstellt hat, kümmert sich das im selben Ordner befindliche Script "generateJSON.sh" um die Generierung des JSON Teils für dieses Binary. Anschliessend werden beide Dateien (Binary und JSON File) in die AWS S3 Cloud hochgeladen.

Im AWS Account muss ein neuer IAM User erstellt werden dem die neue Rolle aws_s3_policy.json zugewiesen wird.

Damit beim Hochladen eines neuen Releases in die AWS (Binaries + json File) das neue Release in die globale releases.json aufgenommen wird, muss ein Lamda Trigger erstellt werden der auf ein neues S3 Event reagiert. Sobald ein json File im S3 ankommt, wird die Funktion lambda_function.py ausgeführt. Diese Funktion löscht über die Unterfunktion delete_old_objects.py zuerst alle alten Releases. Nur die letzten 5 Releases pro Stage werden in der AWS gespeichert.
Anschließend werden in der lambda_function.py alle Einzel-Release-Json Files in der releases.json zusammengeführt.