Force stable trunk
Hallo, ich habe versucht eine deutsche Beschreibung für das Subject zu finden, konnte aber keine passende Formulierung finden. Vor ein paar Tagen habe ich eine Frage bei Stackoverflow gestellt, die ich gerne auch hier besprechen würde: http://stackoverflow.com/questions/17524869/force-stable-trunk-master-branch... Ich denke, ihr seit dem Englischen mächtig: {{{ Our development departments grows and I want to force a stable master/trunk. Up to now every developer can commit into the master/trunk. In future developers should commit into a staging area, and if all tests pass the code gets moved to the trunk automatically. If the test fails, the developer gets a mail with the failed tests. We have several repositories: One for the core product, several plugins and a repository for every customer. Up to now we run SVN and git, but switching all repos to git could be done, if necessary. Which software could help us to get this done? There a some articles on the web which explain how to use gerrit and jenkins to force a stable branch. I am unsure if I need both, or if it is better to use something else. Environment: We are 10 developers, and use python and django. Question: Which tool can help me to force a stable master branch? }}} Gruß, Thomas PS: Antworten bitte an die Liste, nicht nur an mich, danke! -- Thomas Guettler http://www.thomas-guettler.de/
Thomas Guettler schrieb:
ich habe versucht eine deutsche Beschreibung für das Subject zu finden, konnte aber keine passende Formulierung finden.
Vor ein paar Tagen habe ich eine Frage bei Stackoverflow gestellt, die ich gerne auch hier besprechen würde:
http://stackoverflow.com/questions/17524869/force-stable-trunk-master-branch...
Ich denke, ihr seit dem Englischen mächtig:
{{{ Our development departments grows and I want to force a stable master/trunk.
Up to now every developer can commit into the master/trunk. In future developers should commit into a staging area, and if all tests pass the code gets moved to the trunk automatically. If the test fails, the developer gets a mail with the failed tests.
We have several repositories: One for the core product, several plugins and a repository for every customer.
Up to now we run SVN and git, but switching all repos to git could be done, if necessary.
Which software could help us to get this done?
There a some articles on the web which explain how to use gerrit and jenkins to force a stable branch.
I am unsure if I need both, or if it is better to use something else.
Environment: We are 10 developers, and use python and django.
Question: Which tool can help me to force a stable master branch? }}} Wahrscheinlich suchst du etwas wie git-flow[1].
Viele Grüße Markus [1] https://github.com/nvie/gitflow
Am 31.07.2013 10:03, schrieb Markus Zapke-Gründemann:
Thomas Guettler schrieb:
ich habe versucht eine deutsche Beschreibung für das Subject zu finden, konnte aber keine passende Formulierung finden.
Vor ein paar Tagen habe ich eine Frage bei Stackoverflow gestellt, die ich gerne auch hier besprechen würde:
http://stackoverflow.com/questions/17524869/force-stable-trunk-master-branch...
Ich denke, ihr seit dem Englischen mächtig:
{{{ Our development departments grows and I want to force a stable master/trunk.
Up to now every developer can commit into the master/trunk. In future developers should commit into a staging area, and if all tests pass the code gets moved to the trunk automatically. If the test fails, the developer gets a mail with the failed tests.
We have several repositories: One for the core product, several plugins and a repository for every customer.
Up to now we run SVN and git, but switching all repos to git could be done, if necessary.
Which software could help us to get this done?
There a some articles on the web which explain how to use gerrit and jenkins to force a stable branch.
I am unsure if I need both, or if it is better to use something else.
Environment: We are 10 developers, and use python and django.
Question: Which tool can help me to force a stable master branch? }}} Wahrscheinlich suchst du etwas wie git-flow[1].
Hallo, git-flow kannte ich noch nicht, es macht auch einen guten Eindruck. Aber was mir wichtig ist: Nur Patches, die alle Tests erfolgreich durchlaufen haben kommen in den master Branch. Die Aufgabe alle Tests aufzurufen und anschließend den Patch zu übernehmen soll automatisiert werden. Hier scheint mir git-flow nicht zu helfen. Im Moment läuft bei uns Nachts und Mittags ein Script das den Quelltext aktualisiert, alle Tests aufruft, und dann an ggf mehrere Entwickler eine Mail schreibt, falls etwas nicht mehr funktioniert. Das ist aber nicht optimal, pro Patch sollen alle Tests ausgeführt werden, damit man gleich erkennt was (und welcher Committer) verantwortlich ist. Die Idee ist aus meiner Sicht relativ simpel, aber anscheinend gibt es noch kein Tool das uns das sofort liefert. Die populären Tools in diesem Umfeld (gerrit und Jenkins) könnten sicherlich angepasst werden, damit man "force stable master" erreicht. Aber mit beiden habe ich noch nicht gearbeitet. Ist das für euch nachvollziehbar? Lösungsansätze? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
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. 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.
Die Idee ist aus meiner Sicht relativ simpel, aber anscheinend gibt es noch kein Tool das uns das sofort liefert.
Ich denke, dass liegt daran, dass es eben nicht mehr so simpel ist, sobald man "Spezialfälle" (z.B. mehrere inkompatible Commits) betrachtet. Felix
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/
On 7/31/13 4:24 PM, "Thomas Guettler" <guettli@thomas-guettler.de> wrote:
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.
Wir erzwingen durch einen commit-hook, dass immer nur ein Entwickler gleichzeitig auf Master mergen kann. Und wir benutzen auch rebase. Somit hast du also immer erfolgreiche merges zurück. Trotzdem kann es vorkommen, dass zwei grüne Feature branches (getestet durch Jenkins) in der Kombination rot werden. Das kann kein noch so restriktives System 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.
Und was ist dein automatisches merge-verbot anderes als "ich traue dir nicht, dass du das richtige tust, Entwickler"?
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.
Das darf eben nur passieren, wenn der Master grün ist. Siehe oben, dass das auch unter deiner Vision von verzögerten Merges nicht notwendigerweise immer der Fall ist. Wir haben in den letzten Jahren immer wieder massiv in die Verbesserung der Test-suite investiert, um deren immer laenger werdende Laufzeit zu kompensieren. Parallelisierung, ram-disk-datenbanken, Aufteilung in Teilprojekte. Das sollte eher euer Angriffspunkt sein. Ansonsten benutzen wir "nur" github pull requests zwecks code-reviews, und es hat natürlich vorher der feature-branch auf Jenkins grün zu sein. Diez
Hallo Thomas, ich glaube nicht, dass es hilfreich ist, den commit automatisch zu verhindern. Wenn fortwährend instabiler Code in den Trunk kommt, würde ich versuchen, das unterliegende "soziale" Problem lösen. Wenn man etabliert, dass bei zerbrochenem Trunk alles andere stehen bleibt und alle das Problem beheben, lernen die Entwickler recht schnell, das zu vermeiden. Du brauchst auf jeden Fall ein CI System wie Jenkins, dazu könnt Ihr Euch eine Lampe oder Sirene anschaffen, die den kaputten Trunk anzeigt. Es gibt nette DIY-Projekte [1] dafür, das ist eine gute Team Building Übung ;-) Wenn bei allen das Bedürfnis da ist, den Trunk stabil zu halten, helfen Code Review Tools, neben Gerrit fallen mir spontan phabricator [2], rhodecode [3] sowie die Pull Requests auf Github [4] ein. Mit letzteren habe ich in mehreren Teams gute Erfahrungen gemacht. Da Du noch SVN benutzt, würde ich Dir sowieso empfehlen, auf ein DVCS wie Git oder Mercurial zu wechseln, das ist in der Benutzung flexibler und angenehmer als SVN, und viele Tools gibt es inzwischen auch gar nicht mehr für SVN. Git scheint mir derzeit der Quasi-Standard mit der umfangreicheren Tool-Unterstützung. Grüße, Bernhard [1] https://duckduckgo.com/?q=build+status+notification+lamp [2] http://phabricator.org [3] http://rhodecode.org/ [4] https://help.github.com/articles/using-pull-requests
Thomas Guettler <mailto:guettli@thomas-guettler.de> July 31, 2013 8:57 Hallo,
ich habe versucht eine deutsche Beschreibung für das Subject zu finden, konnte aber keine passende Formulierung finden.
Vor ein paar Tagen habe ich eine Frage bei Stackoverflow gestellt, die ich gerne auch hier besprechen würde:
http://stackoverflow.com/questions/17524869/force-stable-trunk-master-branch...
Ich denke, ihr seit dem Englischen mächtig:
{{{ Our development departments grows and I want to force a stable master/trunk.
Up to now every developer can commit into the master/trunk. In future developers should commit into a staging area, and if all tests pass the code gets moved to the trunk automatically. If the test fails, the developer gets a mail with the failed tests.
We have several repositories: One for the core product, several plugins and a repository for every customer.
Up to now we run SVN and git, but switching all repos to git could be done, if necessary.
Which software could help us to get this done?
There a some articles on the web which explain how to use gerrit and jenkins to force a stable branch.
I am unsure if I need both, or if it is better to use something else.
Environment: We are 10 developers, and use python and django.
Question: Which tool can help me to force a stable master branch? }}}
Gruß, Thomas
PS: Antworten bitte an die Liste, nicht nur an mich, danke!
-- BernhardBockelbrink mobile: +49 (0) 177 72 13 550 orderbird*AG*- Wir beflügeln Gastfreundschaft! Ritterstraße 12-14, Aufg. 4 D-10969 Berlin, Germany *Gewinner Intergastra Innovationspreis*2012/2013* * tel.: + 49 (0) 800 67 337 24 fax: + 49 (0) 321 214 681 89 www.orderbird.com Registergericht: Amtsgericht Charlottenburg, HRB 13401 Vorstandsvorsitzender: Jakob Schreyer
participants (6)
-
Bernhard Bockelbrink -
Diez Roggisch -
Felix Schwarz -
Markus Zapke-Gründemann -
Stefan Behnel -
Thomas Guettler