[Python-de] Force stable trunk

Thomas Guettler guettli at thomas-guettler.de
Do Aug 1 08:46:21 CEST 2013


Am 31.07.2013 19:59, schrieb Felix Schwarz:
>
> Am 31.07.2013 18:39, schrieb Thomas Güttler:
>> Aus meiner Sicht ist das Testen nicht Teil des Deployments, es muss
>> vorher geschehen. Eine Begründung: Der Code wird mehrfach ausgeliefert.
>> Die gleichen Tests mit gleichem Code mehrfach auszuführen ist nicht
>> sinnvoll.
>>
>>
>>> Üblicherweise erreicht man das mit einem "production" branch.
>>
>> Genau darum geht es mir. Für mich sind in diesem Kontext
>> Trunk/Master/Produktion synonym. Entwickelt wird in feature oder devel
>> Branches.
>>
>> Der Masterbranch muss stabil sein. Das will ich auch hier besprechen.
>
> Ich möchte erläutern, warum ein production branch meiner Meinung nach oft
> trotzdem notwendig ist (und das hinter deiner Frage stehende Problem lösen kann):
>
> Annahmen:
> 1. Man möchten niemals Code deployen, der nicht auf dem Testserver alle Tests
>     durchlaufen hat (oder wenn doch, ist das die große Ausnahme für den super-
>     wichtigen Hotfix).
> 2. Eine ausreichend große Testsuite bringt längere Testzeiten (z.B. ½ Stunde)
>     mit sich.
> 3. Egal wie oft vorher getestet wurde (z.B. feature-branch), letztlich muss
>     der Code für den Produktivserver einmal komplett getestet worden sein,
>     mehrere Commits können in Kombination Probleme verursachen, so dass Tests
>     für die einzelnen Feature-Branches nicht ausreichen.
> 4. Es könnte vorkommen, dass man wirklich schnell einen Fix einspielen muss,
>     während der Test für den vorangegangenen Commit noch läuft. Hier sollte es
>     einen klaren Mechanismus geben, so dass niemand ad-hoc etwas erfinden muss
>     (das geht in so einer Situation ziemlich sicher schief).
> (Wie man sieht, ist das obige eine WebDev-Sicht.)
>
> Ein System "commit in master nur nach vorigen Jenkins-Test, deployment direkt
> von master" erzeugt letzlich auch nur zwei Branches (selbst wenn es nur
> unterschiedliche Stände in zwei DVCS-Repos sind). Da kann man dann auch gleich
> den production branch einführen.

Ich stimme dir voll zu, nur habe ich einen anderen Namen für den Branch genommen.

Etwas anders formuliert könnte man auch fragen:

  Welches Tool hilft mir feature-Branches automatisch
  nach dem OK aller Tests in den stable-Branch zu mergen?

Insbesondere bei vielen kleinen Änderungen ist das manuelle Vorgehen nervig.

Wenn es genau einen zentralen Prozess gibt, der das ausführt, dann gibt es
auch nicht das Problem der inkompatiblen Commits. Der erste gewinnt. Hotfixes
sind ein anderes Thema.

Gruß,
   Thomas

-- 
Thomas Guettler http://www.thomas-guettler.de/


Mehr Informationen über die Mailingliste python-de