Im Rahmen der Ausarbeitung dieses Projektes wurde unter anderem ein starker Fokus auf Continuous Integration (CI) gelegt.
Die Versionierung des Source Codes wurde durch Git, in Verwendung mit GitLab umgesetzt. Das Repository ist hierbei auf dem internen GitLab Server der FH Hagenberg gehostet. Um gewährleisten zu können, dass der Master Branch des Repository stets einen funktionierenden Zwischenstand darstellt, bietet sich die Verwendung von Continuous Integration an.
Überblick
Das Ziel ist es, jeden Commit auf das Repository auf Funktionsfähigkeit zu überprüfen. Vielfach in der Praxis in Firmen wird hierbei jede Änderung zuerst compiliert bzw. synthetisiert, Tests in Simulation durchlaufen, und teilweise auch direkt auf echter Hardware in Testaufbauten getestet. Am Ende wird oft noch ein Testreport mit detaillierten Ergebnissen erstellt.
In diesem Projekt beschränkt sich die CI jedoch nur auf den Teil des Synthetisieren.
Folgendes Blockdiagramm zeigt die Funktionsweise des CI Prozesses.
Sämtliche Entwickler arbeiten an einem gemeinsamen Repository. Der Build Server kann ein einfacher PC sein, auf dem ein Buildkite CI Client (siehe http://buildkite.com) installiert ist. Weiters müssen dort alle Programme installiert sein, die für die Ausführung der Synthese, Compilierung, oder Tests notwendig sind. Das sind beispielsweise g++, Xilinx Vivado und Mentor ModelSim.
Funktionsweise
Sobald Änderungen in Form eines Commits auf das Repository gepusht werden, wird ein GitLab Webhook getriggert. Der Buildkite CI Client hört auf diesen Webhook und startet einen Buildprozess, mit dem jeweiligen neuen Commit.
Der Buildprozess beginnt mit dem Vorbereiten des Repositorys auf dem Build Server. Hierbei werden möglicherweise bereits vorhandene temporäre Dateien gelöscht, und ein Checkout des aktuellen Commits gemacht. Der eigentliche Buildprozess wird danach gestartet, indem ein Bash-Script ausgeführt wird, welches im Repository liegt. Sämtliche Bash-Befehle, die in diesem Script stehen, werden nun lokal auf dem Build Server ausgeführt.
Alle Log Messages, die während des Prozesses in der Kommandozeile ausgegeben werden, können online unter http://buildkite.com eingesehen werden. Dafür ist natürlich ein entsprechender Login in das verknüpfte Konto nötig.
Nach Abarbeitung des Bash-Scripts werden die gewünschten Files wie Log-Outputs, Bitstream Files, Binaries und andere Produkte des Buildprozesses zu buildkite.com hochgeladen. Von dort können sie heruntergeladen werden.
Buildkite Online
Folgender Screenshot zeigt die Online-Oberfläche von Buildkite in der Build Übersicht.
Ein weiterer Screenshot im Folgenden zeigt die Detailansicht für einen bestimmten Commit.
