Am 31.07.2013 13:10, schrieb Felix Schwarz:
Am 31.07.2013 12:44, schrieb Thomas Guettler:
Die Aufgabe alle Tests aufzurufen und anschließend den Patch zu übernehmen soll automatisiert werden. Hier scheint mir git-flow nicht zu helfen.
Aus meiner Sicht versuchst du, ein soziales/Kompetenzproblem technisch zu lösen.
Insbesondere wird das automatische Zusammenführen nach dem erfolgreichen Test nicht immer funktionieren bzw. man muss sich eben auch um die Spezialfälle kümmern.
git mit Rebase: Von einem Zustand gibt es einen Übergang zum nächsten Zustand. Der Übergang von einem Zustand zum nächsten ist ein Patch. Besondere Spezialfälle gibt es hier aus meiner Sicht erstmal nicht. Wenn zwei Commits gegenseitig inkompatibel sind, gewinnt der schnellere: Der kennt das zweite Commit auch gar nicht. Der Langsamere muss per Rebase wieder einen passenden Commit erstellen. So kann der Branch von einem stabilen Zustand zum nächsten stabilen Zustand übergehen. Mit "stabil" ist hier das automatisierte Testen gemeint. Versteckte Bugs kann man damit natürlich nicht verhindern.
Daher war es bei allen Unternehmen, die ich bisher gesehen habe, üblich, dass die Entwickler letztlich selbst auf trunk committen (ggf. natürlich mit Entwicklung+Tests im Feature-Branch) und es dann eben auch Pflicht (ggf. des Teams) wird, dass die Trunk-Tests jederzeit laufen.
Wenn alle Tests durchlaufen werden, dauert das bei uns eine Weile. Darum werden selten alle Tests vor dem Commit ausgeführt. Das Problem: versteckte Seiteneffekte werden nicht gleich erkannt. Jetzt mit erhobenem Zeigefinger zu sagen "du böser Entwickler, du musst erst alle Tests ausführen vor dem Commit ..." bringt nichts. Mit Jenkins (oder einem ähnlichen Tool) sieht man dann im Fehlerfall eine rote Lampe ... schön, aber vielleicht hat inzwischen auch schon jemand den Code in ein Produktivsystem geschoben .... Das darf nicht sein. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/