Continuous Integration

[Boa]

Hallo,

Ich habe mich heute nach einem günstigen Server umgesehen, auf dem ich die Tests meines Projektes laufen lassen kann (die dauern bis zu 30 Min).
Ich bin direkt fündig geworden. Insbesondere http://www.Cloudbees.com hat mir vom Angebot sehr zugesagt. Meine Tests benötigen Netzwerkzugang und haben einige Abhängigkeiten zu anderen Python Modulen. Cloudbees stellt dafür die richtige Umgebung zur Verfügung mit insgesamt 300 Gratis Minuten pro Monat, ohne dass man Kreditkarten Informationen angeben muss. Für Open Source Entwickler gibt es sogar noch ein besseres Angebot.
Ich hoste mein Projekt bei http://www.github.com. Cloudbees bietet eine Weboberfläche (Jenkins) an , bei der man einstellen kann, dass sobald das Projekt auf Github geändert wird sich der Server automatisch die neueste Version holt, installiert und meine Tests laufen lässt. Dabei habe ich gleich gemerkt, dass ein Test fehlschlug, den ich schon lange nicht mehr habe laufen lassen. Das ist denke ich insbesondere dann wertvoll, wenn man mit mehreren Leuten im Team arbeitet. Außerdem sieht es schick aus, weil man sehen kann, dass sich der Entwickler um die Qualität seiner Software kümmert.
Anscheinend kann man das Projekt danach automatisch bei Google in der Cloud laufen lassen, was bis zu einem gewissen Grad auch kostenfrei ist. Das habe ich jedoch noch nicht probiert.
Jenkins unterstützt viele Versionierungssysteme, verschiedene Testsysteme (ich nutze nosetests), und virtualenv für die Installation beliebiger Python Module. Man kann bei jeder Projekt Änderung beliebigen Python Code oder Linux Kommandos laufen lassen. Die Weboberfläche lässt sich gut bedienen, aber man muss sich erst einmal zurechtfinden. Ich vermute, dass es auch diverse Youtube Videos dazu gibt. Aber ich bin auch so zurecht gekommen.
Was ich bisher noch nicht gefunden habe sind E-Mail Benachrichtigungen, falls die Tests fehlschlagen. Soweit ich weiß, kann man seine Änderungen direkt an Cloudbees senden, wo sie getestet werden. Falls die Tests erfolgreich sind, wird dann automatisch die Version in einem öffentlichen Versionierungssystem veröffentlicht. Das wäre noch etwas schicker als meine Lösung.

Auf Github habe ich eine kleine Infografik vom Test Server eingebunden (ganz unten), sodass man sehen kann, ob die aktuelle Version Fehler aufweist:
https://github.com/joe42/CloudFusion
Grobe Übersicht:
https://joe42.ci.cloudbees.com/
Letzte Änderungen:
https://joe42.ci.cloudbees.com/job/Cloudfusion/changes
Ergebnisse der letzten Tests:
https://joe42.ci.cloudbees.com/job/Clou ... estReport/

So macht testen mehr Spaß

Gruß,
Boa

[jens]

Gibt eine reihe andere Dienste die ähnliches machen. Ich nutzte für python-creole z.B.:
https://jenkins.shiningpanda.com/python-creole/
http://travis-ci.org/jedie/python-creole

[Boa]

Cool, Travis hat beinahe unbegrenzte Laufzeit und bietet dedicated machines an, das sieht interessant aus. Mich hat bei der Recherche abgeschreckt, dass die Webseite sehr unübersichtlich ist (auf dem Home Link sieht man statt allgemeiner Informationen hektisch ablaufende build Prozesse, die mich kein Stück interessieren). Außerdem nutzen sie eine eigene Sprache für builds, anstatt einfach Shell Skripte auszuführe. Die Buildskripte müssen dann zusätzlich in dem jeweiligen Repository abgelegt werden, was mir auch nicht besoders gefäll, da man sie so nicht auf die Schnelle verändern kann, was insbesondere praktisch ist, wenn man sie das erste Mal schreibt und vermutlich mehrere Syntax Fehler darin hat.
Bei Shiningpanda gefällt mir, dass das FOSS Programm keine Kosten/Monat veranschlagt. Allerdings bekommt man nur etwa 12 Stunden/Monat gratis statt der 33 Std. bei Cloudbees.
Weißt du zufällig ob die beiden Anbieter Netzwerk Zugang bieten?

[lunar]

Außerdem nutzen sie eine eigene Sprache für builds, anstatt einfach Shell Skripte auszuführe.

Auch bei Travis kannst Du Shell-Skripte ausführen:

Code: Alles auswählen

script:
    - sh ./my-super-cool-build-script.sh

Nebenbei bemerkt, auch ein Jenkins-Build fällt nicht einfach vom Himmel, sondern muss konfiguriert werden. Dafür verwendet Jenkins, man höre und staune, ebenfalls eine eigene Sprache. Sieh Dir mal eine Jenkins-Konfiguration im Editor an…

Die Buildskripte müssen dann zusätzlich in dem jeweiligen Repository abgelegt werden, was mir auch nicht besoders gefäll, da man sie so nicht auf die Schnelle verändern kann, was insbesondere praktisch ist, wenn man sie das erste Mal schreibt und vermutlich mehrere Syntax Fehler darin hat.

Du kannst die Travis-Konfiguration jederzeit ändern und per Push einen neuen Build veranlassen. Wenn Du mit Travis experimentieren möchtest, dann erzeuge halt einen neuen Zweig, experimentiere mit "travis.yml", und pushe jeden Commit, um zu schauen, was auf Travis passiert.

Wenn Du dann fertig bist, kannst Du mit "git merge --squash" das Ergebnis Deiner Experimente in Deinen Hauptzweig übernehmen, und den experimentellen Zweig löschen.

[Boa]

Hallo lunar,

Soweit einen eigenen Branch für die ersten Versuche einzurichten habe ich nicht gedacht. Gut zu wissen, dass man auch Shellscripte ausführen kann.
Die Einrichtung in Jenkins fand ich dennoch einfacher, weil man für die Anpassung des Build Skriptes nicht die Webseite verlassen musste. Davon, dass es eine eigene Sprache verwendet habe ich nichts gemerkt. Ich konnte verschiedene Linux Befehle wie in einem Bash Skript angeben (cp, mv, perl).
Ich will Travis nicht herunterspielen. Wie gesagt, nachdem ich es mir genauer angesehen habe scheint es ziemlich gut zu sein. Bezüglich der Reproduzierbarkeit von Test Ergebnissen erscheint es mir auch sehr sinnvoll, die Skripte mit zu versionisieren. Nur wüsste ich dann nicht wie ich meine Passwörter in die Tests mit einbinden kann, ohne dass andere darauf Zugriff haben. Vielleicht gibt es dazu auch eine Lösung? Dann würde ich mir durchaus überlegen Travis zu nutzen.

[Boa]

Es scheint tatsächlich eine Lösung zu geben bestimmte Daten zu verschlüsseln. Dann werde ich Travis also eine Chance geben

[jens]

Was für Passwörter brauchst du denn in Tests?

[Boa]

Eine verständliche Frage Ich hatte das Subprojekt Cloudfusion als Showcase schon vorgestellt (https://github.com/joe42/CloudFusion), da es in Python programmiert ist.
Es geht um die Nutzung von Cloudspeicher von Linux aus über das Dateisystem. Man kann dabei auf alle Daten zugreifen, ohne dass sie tatsächlich lokal vorliegen und Speicher verbrauchen. Dropbox, Sugarsync sind implementiert und bieten gratis Speicher. Zur Nutzung des Cloud Storage muss man sich auch in den Tests authentifizieren. Das habe ich in der aktuellen Version soweit automatisiert, dass es ohne Nutzerinteraktion funktioniert. Man muss nicht Mal unbedingt root Rechte zur Installation haben, wenn man einfach virtualenv auf den Server schiebt
Es ist übrigens schon eine neue Version herausgekommen. Ich update Mal den Thread.

[lunar]

Die Einrichtung in Jenkins fand ich dennoch einfacher, weil man für die Anpassung des Build Skriptes nicht die Webseite verlassen musste. Davon, dass es eine eigene Sprache verwendet habe ich nichts gemerkt. Ich konnte verschiedene Linux Befehle wie in einem Bash Skript angeben (cp, mv, perl).

Nun ja, was passiert wohl mit den Eingaben, die Du in der Jenkins-Oberfläche machst? Sie landen in mehreren Konfigurationsdateien, die sich von "travis.yml" nicht großartig unterscheiden, abgesehen davon, dass sie wesentlich komplexer und schwieriger zu versionieren ist.

Das Buildscript selbst, welches Du in den entsprechenden Textboxen der Jenkins-Website einträgst, kommt bei Travis halt in eine richtige Skript-Datei, die dann in der Build-Konfiguration aufgerufen wird.

Der Vorteil daran ist, dass Travis wesentlich flexibler ist. Bei komplexeren Projekten nutze ich keine Shell-Skripte mehr, um die Build-Umgebung aufzusetzen, sondern Puppet-Manifeste. Damit kann ich dann relativ bequem die Travis-Umgebung aufsetzen, und gleichzeitig mit Vagrant eine lokale VM, in der ich meine Tests in isolierter Umgebung lokal laufen lassen kann.

[Boa]

@lunar: Die Puppet Manifeste sehen schick aus. Muss ich mir angucken, sobald ich wieder Zeit habe. Also irgendwann im nächsten Jahr.
Sieht so aus, als ob man bei Cloudbees nicht so einfach Pakete installieren kann. Mal sehen was der Support sagt (der war bisher sehr zuverlässig). Ich habe gesehen, dass Travis aus Deutschland kommt, das sollte man ja unterstützen (Wenn ich denn Mal Geld habe)
Ich experimentiere jetzt mit Travis rum. Auch wenn es meiner Meinung nach schon mehr als genug build Skript Sprachen gibt, scheint diese zumindest sehr einfach zu sein.
Ich komme gerade nicht weiter. Ich habe die travis build Datei in einen neuen branch development gepushed, aber es passiert nichts. Vielleicht habt ihr eine Idee was ich falsch mache?

[Boa]

Ah, es hat nur eine ganze Weile gedauert
Beim Syntaxcheck half: lint.travis-ci.org