Ich bin ein Qt / C ++ - Entwickler. Ich möchte eine Continuous Integration-Umgebung einrichten, bei der nach dem Commit des Quellcodes ein Build-Prozess ausgelöst wird, der den Code für die 3 Plattformen erstellt, die ich verwende:
Wenn möglich, wie richte ich diese Umgebung ein? Hinweise oder Links sind willkommen. Ich habe über Jenkins gelesen, aber ich kann kein gutes Tutorial dafür finden.
Ich schlage auch Jenkins aus verschiedenen Gründen vor:
Ein größeres Problem wird sein, dass AFAIK, Qt nicht wirklich gut für andere Plattformen kompiliert. Mit Jenkins (und den entsprechenden Plugins) sollten Sie in der Lage sein, dies zu lösen.
Eine Methode, die einem schnell einfällt, ist eine Instanz von Jenkins auf jeder Plattform. Jede Instanz ist verantwortlich für die Erstellung der Version für ihre eigene Plattform. Am Ende des Builds werden die erstellten Artefakte alle an einem gemeinsamen, gemeinsamen Ort abgelegt.
Jenkins unterstützt diese Funktion über Plugins für alle wichtigen Quellcodeverwaltungssysteme. Wenn Sie Jenkins ernsthaft in Erwägung ziehen (und ich kann es nur wärmstens empfehlen), ziehen Sie in Erwägung, John Ferguson Smart's Jenkins: The Definitive Guide .
Zwei Lösungen kommen mir in den Sinn:
BuildBot
BuildBot ist ein hochgradig anpassbares kontinuierliches Integrationssystem, das in Python geschrieben wurde. Die Master-Komponente bietet eine nette webbasierte GUI zum Überwachen und Auslösen von Builds. Slave-Komponenten werden auf den Zielmaschinen (normalerweise virtuelle Maschinen, aber sie könnten der Mac-Laptop eines der Entwickler sein) platziert. Docs sind gut genug, um ein Basissystem aufzubauen, die Anpassung könnte ein wenig schwierig sein (zumindest war es für mich). Mit Commit / Push-Hooks, die von VC-Systemen bereitgestellt werden, können Sie die Master- und Trigger-Builds über die Slaves problemlos aktivieren. Es unterstützt auch inkrementelle Builds (ein Muss, wenn Ihr Projekt groß ist).
CDash
Entwickelt von den Autoren von CMake, ist CDash eine Webanwendung, die Builds sammelt, die aus dem gesamten Netzwerk kommen, nicht genau das, wonach du gefragt hast aber ich denke, es ist einen Versuch wert. Sehr leistungsfähig, wenn Sie ein Team von Entwicklern haben, die kontinuierlich Build-Ergebnisse auf ihren Maschinen an den Server senden können (und wenn Sie CMake verwenden, ist es fast transparent). Sie können Builds nicht wie Buildbot vom Server auslösen, aber Sie könnten eine Reihe von VMs mit einem Cron einrichten, der nach Änderungen sucht und für den Fall, dass der Build ausgeführt wird und Ergebnisse an CDash sendet.
Sicher ist es möglich. Die meisten Versionskontrollsysteme können ein benutzerdefiniertes Skript auf der Serverseite ausführen. Einige von ihnen (Git, zum Beispiel), hat Haken, um das gleiche lokal zu erreichen. Werfen Sie einen Blick auf git's Post-Commit-Hook .
Sie müssen lediglich ein Skript erstellen, das plattformübergreifende Builds auslöst.
Die meisten Versionskontrollsysteme erlauben Hooks nach dem Commit, damit Sie Ereignisse wie Builds starten können. Alternativ können Build-Systeme so konfiguriert werden, dass sie regelmäßig ein Source-Control-Repository abfragen und ihre eigene Build-Planung verwalten (so verwenden wir Jenkins).
Es ist zu beachten, wie lange es dauern wird, um einen kompletten Build über Plattformen hinweg zu erstellen und wie viele Check-Ins in diesem Intervall typischerweise stattfinden. Sie können Batching-Check-Ins als eine bessere Möglichkeit für kontinuierliche Integrations-Builds finden, wenn Sie über ein Team mit einer angemessenen Größe oder über begrenzte Build-Server-Ressourcen verfügen. Andernfalls könnte Ihr Build-System am Ende versuchen, Aufholjagd zu spielen.
Ob es möglich ist, auf allen Zielplattformen zu bauen, hängt von Ihrer Werkzeugkette ab.
Tags und Links c++ qt build continuous-integration