Wie automatisieren oder erleichtern Multiplattform-Build/Test vor dem Commit?

Question

Unsere Software basiert auf Linux und Windows Plattformen. Je nach Vorliebe des Entwicklers wird auf beiden Plattformen ein Beitrag entwickelt und getestet, der dann in unser Subversion-Repository eingebunden wird. Es stellt sich dann heraus, dass der Beitrag nicht auf der anderen Plattform aufgebaut wird, und es muss eine Lösung gefunden werden. Die Fehlerbehebung auf der anderen Plattform kann den Build auf der ursprünglichen Plattform erneut unterbrechen und so weiter.

Ich würde lieber sehen, dass ein Beitrag auf der anderen Plattform erstellt (und Regression getestet) wird, bevor er festgeschrieben wird. Wir haben einen Continuous Build Server (CruiseControl), aber dieser Server baut aus dem Repository. Ich suche nach einer Lösung, bei der der Continuous-Build-Server auf der anderen Plattform als Pre-Commit-Prüfung aufbaut und dann die Inhalte festlegt, wenn Build und Test erfolgreich sind.

Irgendwelche Vorschläge?

Answer 1

Matheiu Godlewski einen guten Vorschlag am CruiseControl wiki

gemacht hat, wenn Sie seinen Vorschlag mit dem veto Elemente kombinieren, ich glaube, Sie eingestellt werden sollen.

Answer 2

Es könnte einfacher sein, zwei Zweige zu haben, eine, in der Leute einchecken, und eine andere, in die sie ihre Änderungen einfügen, nachdem sie die kontinuierliche Integration durchlaufen haben.

Answer 3

Teamcity behandelt vorab getestete Festschreibung, Sie können möglicherweise etwas mit den neuen Verkettungsfunktionen in 4.0 (http://www.jetbrains.com/teamcity/features/newfeatures.html) tun. Agents sind plattformübergreifend und können so konfiguriert werden, dass sie nur bestimmte Build-Bits ausführen. Sie können daher möglicherweise so konfiguriert werden, dass nur eine Teilmenge der Tests ausgeführt wird.

Bitte beachte, dass ich habe nicht wirklich das getan :)

Answer 4

Wir haben eine benutzerdefinierte Build und Test rig, die remote auf mehrere Betriebssysteme bereitstellen könnte (und mehrere Datenbankprodukte auf mehreren Betriebssystemen). Dies wurde als nächtlicher Build mit einer Regel gemacht, dass Sie Ihre Bugs am nächsten Morgen beheben.

Nein vollständig kontinuierlich dann, aber das ist möglicherweise eine Menge Arbeit auf einem Pre-Commit Hook. Vor allem, wenn das Quellcodeverwaltungsrepository die betroffenen Dateien für die Dauer der Ausführung des Pre-Commit-Hooks sperrt.

Ich denke, es gibt einen Unterschied zwischen einem kontinuierlichen Integrationstest, der während des Tages läuft, per-commit und einem Systemintegrationstest, der jeden Abend läuft.

Answer 5

Douglas Leeder schlug einen "Integration" Zweig vor - das Schöne daran ist, dass es möglich ist zu automatisieren. Wenn die Tests bestanden werden, fusionieren Sie mit dem 'Trunk'.

Einige Versionskontrollsysteme (z. B. bzr/hg/git) machen dies einfacher als andere, aber es ist bei den meisten möglich.