Hallo,
ich hätte hier mal eine Frage zur Verwendung von Python für automatisierte Build/Test Umgebungen.
Ziel ist eine Umgebung, die identisch unter Windows und Linux läuft.
Source-Verwaltung momentan mit svn, evtl. später auf Hg.
Die Compiler/Linker Aufrufe erfolgen transparent für das jeweilige System.
Die Targets werden geordnet an bestimmten Pfaden, passend zur Source-Verwaltung, abgelegt.
Grober Ablauf:
Jedes Projekt enthält ein xml-File welches alle notwendigen Referenzen, Import, Build-Optionen,... enthält
Python-Scripte zusammen mit den xml-Files bilden das gesamte Konzept (z.B. pysvn für source-pull, calls für compiler/makes, test-umgebung updaten, ergebnisse ablegen)
Es gibt zwar hierzu jede Menge "große" Alternativen (CC.NET, MSBuild, Hudson, ...). Keine paßt für mich so wirklich.
Sinn und Zweck ist hier eher eine kompakte Umgebung, die auch bei Kunden einfach aufzusetzen sein soll. Kein Server, keine große Installation.
Ideal wäre, eben nur Abhängigkeit zur python-Umgebung und dann eben noch die Skripte samt xml-Files zur Ergänzung der Projekte.
Wer kennt sowas, oder hat auch Bedarf an solch einer Umgebung?
Danke,
lightos
Python als Auto-Build/Auto-Test/Deployment Umgebung
-
lunar
@lightos: So kann man Dir nicht helfen. Zum einem wirfst Du verschiedene Dinge zusammen. MSBuild ist ein Buildsystem und mithin etwas vollkommen anderes als CI-Systeme wie Hudson und CC.Net. Ein Buildsystem steuert den Übersetzungsvorgang eines Programms, ein CI-System dagegen Test-, Entwicklungs- und teilweise auch Deploymentprozesse. Suchst Du also nun lediglich ein Buildsystem, oder ein CI-System, oder ein magisches „mach alles, und zwar so wie ich das möchte“-System?
Außerdem sind Deine Anforderungen und Erklärungen so grob, dass man letztlich alles empfehlen könnte, auch Hudson, denn ich erkenne nichts, was dem Einsatz von Hudson entgegen stehen würde. Komischerweise hängst Du Dich dann wiederum an letztlich vollkommen unwichtigen kleinen Details auf, u.a. Python als Implementierungssprache und XML als Steuerungssprache für das System. Ist es nicht vollkommen egal, in welcher Sprache die Konfiguration Deines Was-auch-immer-Systems erfolgt, und noch viel unwichtiger, in welcher Sprache es implementiert ist?!
Beschreibe als doch bitte mal möglichst detailliert die Anforderungen an Deine Umgebung, und insbesondere auch, warum für Dich offenbar weder ein existierendes Buildsystem wie MSBuild noch ein existierendes CI-System wie Hudson in Frage kommt. Diese Ausgangssituation ist nämlich – nun ja – eher ungünstig, da es abseits der Standardlösungen wenig bis gar keine Alternativen gibt. Und in eine Eigenentwicklung von Build- und CI-System kannst Du ganz locker ein paar Jahre investieren, wie Du unschwer an der Entwicklungsgeschichte von Systemen wie Hudson, CMake oder MSBuild erkennen kannst. Gerade die Implementierung eines plattformunabhängigen Buildsystems ist aufgrund all der kleinen und größeren Unterschiede und Eigenheiten verschiedener Kombinationen aus Betriebssystem und Architektur eine ziemlich komplexe und ungeheuer aufwendige Angelegenheit.
Außerdem sind Deine Anforderungen und Erklärungen so grob, dass man letztlich alles empfehlen könnte, auch Hudson, denn ich erkenne nichts, was dem Einsatz von Hudson entgegen stehen würde. Komischerweise hängst Du Dich dann wiederum an letztlich vollkommen unwichtigen kleinen Details auf, u.a. Python als Implementierungssprache und XML als Steuerungssprache für das System. Ist es nicht vollkommen egal, in welcher Sprache die Konfiguration Deines Was-auch-immer-Systems erfolgt, und noch viel unwichtiger, in welcher Sprache es implementiert ist?!
Beschreibe als doch bitte mal möglichst detailliert die Anforderungen an Deine Umgebung, und insbesondere auch, warum für Dich offenbar weder ein existierendes Buildsystem wie MSBuild noch ein existierendes CI-System wie Hudson in Frage kommt. Diese Ausgangssituation ist nämlich – nun ja – eher ungünstig, da es abseits der Standardlösungen wenig bis gar keine Alternativen gibt. Und in eine Eigenentwicklung von Build- und CI-System kannst Du ganz locker ein paar Jahre investieren, wie Du unschwer an der Entwicklungsgeschichte von Systemen wie Hudson, CMake oder MSBuild erkennen kannst. Gerade die Implementierung eines plattformunabhängigen Buildsystems ist aufgrund all der kleinen und größeren Unterschiede und Eigenheiten verschiedener Kombinationen aus Betriebssystem und Architektur eine ziemlich komplexe und ungeheuer aufwendige Angelegenheit.
-
lightos
- User
- Beiträge: 39
- Registriert: Montag 12. Dezember 2011, 19:39
- Wohnort: Raum Bruchsal
- Kontaktdaten:
Also im Prinzip weder noch.
Auf keinen Fall aber eine Server-basierte Lösung, da verschiedene Pakte eben auch zum Kunden müssen und dort automatisch erzeugt werden.
Da wäre eine Lösung wie Hudson einfach zu überdimensioniert.
Momentan läuft das unter Linux über .sh skripte und unter Windows mit cmd-files.
Komplett fix codiert und somit recht unflexibel.
angedachter Ablauf mit python:
- Lese project-xml-file (Pfade zu den Sources (svn), Arbeitsverzeichnis, build-Aufrufe (make, bzw. devenv mit den kompletten Optionen)
xml-files einfach nur, um über Schema-Validierung die korrekten Inhalte sicher zu stellen
- Hole Sources und alle abhängigen Libs/Sources/... in ein arbeitsverzeichnis. Das kann entweder svn:externals sein, oder auch Referenzen zu anderen Paketen (z.B. boost)
- Starte den angegebenen Build des Projekts (Parameter aus dem xml, aber abhängig vom OS)
- Kopiere die erzeugten Binaries/Libs/Header ins TargetVereichnis (Pseudo-Deployment, da evtl. nur Sub-Teile)
- Cleanup Arbeitsverzeichnis
- Installer-Projekte sehen ähnlich aus, referenzieren aber aben nur auf die targets und bauen daraus das setup, zip oder tar
- Alle Targets werden entsprechend der Version aus dem svn (tag, head, ..) 1:1 abgelegt um das genau zuordnen zu können.
- Die Reihenfolge muß manuell korrekt festgelegt werden, da es keine automatischen Abhängigkeitsprüfungen gibt. Ansonsten eben Fehler.
Damit das auch gut zu Testen ist, kann man jeden Schritt (evtl. einzelne Python-Scripte) auch separat ausführen.
Ich hoffe, das ist nun etwas klarer.
Danke,
lightos
Auf keinen Fall aber eine Server-basierte Lösung, da verschiedene Pakte eben auch zum Kunden müssen und dort automatisch erzeugt werden.
Da wäre eine Lösung wie Hudson einfach zu überdimensioniert.
Momentan läuft das unter Linux über .sh skripte und unter Windows mit cmd-files.
Komplett fix codiert und somit recht unflexibel.
angedachter Ablauf mit python:
- Lese project-xml-file (Pfade zu den Sources (svn), Arbeitsverzeichnis, build-Aufrufe (make, bzw. devenv mit den kompletten Optionen)
xml-files einfach nur, um über Schema-Validierung die korrekten Inhalte sicher zu stellen
- Hole Sources und alle abhängigen Libs/Sources/... in ein arbeitsverzeichnis. Das kann entweder svn:externals sein, oder auch Referenzen zu anderen Paketen (z.B. boost)
- Starte den angegebenen Build des Projekts (Parameter aus dem xml, aber abhängig vom OS)
- Kopiere die erzeugten Binaries/Libs/Header ins TargetVereichnis (Pseudo-Deployment, da evtl. nur Sub-Teile)
- Cleanup Arbeitsverzeichnis
- Installer-Projekte sehen ähnlich aus, referenzieren aber aben nur auf die targets und bauen daraus das setup, zip oder tar
- Alle Targets werden entsprechend der Version aus dem svn (tag, head, ..) 1:1 abgelegt um das genau zuordnen zu können.
- Die Reihenfolge muß manuell korrekt festgelegt werden, da es keine automatischen Abhängigkeitsprüfungen gibt. Ansonsten eben Fehler.
Damit das auch gut zu Testen ist, kann man jeden Schritt (evtl. einzelne Python-Scripte) auch separat ausführen.
Ich hoffe, das ist nun etwas klarer.
Danke,
lightos
-
lightos
- User
- Beiträge: 39
- Registriert: Montag 12. Dezember 2011, 19:39
- Wohnort: Raum Bruchsal
- Kontaktdaten:
Hallo BlackJack,
danke für den Tipp. Das kannte ich noch nicht.
Könnte in die richtige Richtung zu gehen. Allerdings sind meine Projekte alles C++. Ich schau mir das aber trotzdem mal genauer an.
danke für den Tipp. Das kannte ich noch nicht.
Könnte in die richtige Richtung zu gehen. Allerdings sind meine Projekte alles C++. Ich schau mir das aber trotzdem mal genauer an.