Release Build vs. Nightly Build

Eine typische Lösung besteht darin, einen CI-Build (Continuous Integration) auf einem Build-Server auszuführen: Er analysiert den Quellcode, erstellt einen Build (im Debug-Modus) und führt Tests aus, misst die Testabdeckung usw.

Ein anderer Build-Typ, der normalerweise als "Nightly Build" bezeichnet wird, ist das langsame Erstellen von Codedokumenten, Erstellen eines Setup-Pakets, Bereitstellen in einer Testumgebung und Ausführen automatischer Tests (Rauch- oder Akzeptanztests) für die Testumgebung usw.

Nun die Frage:

• Ist es besser, einen dritten separaten "Release Build" als Release Build zu haben?
• Oder "Nightly Build" im Release-Modus und verwenden Sie es als Release?

Was setzen Sie in Ihrem Unternehmen ein?

(Der Release-Build sollte auch eine Art Tag zur Quellcodeverwaltung der potenziellen Produktversion hinzufügen.)

Ein Fall, bei dem der Release-Build dem nächtlichen Build entspricht, ist: Sie möchten genau das testen, was Sie veröffentlichen . Sie möchten keine Fehler in der Produktion entdecken, die bereits beim Testen von Entwicklern entdeckt wurden.

Der Unterschied zwischen Release und Nightly Builds:

• Der nächtliche Build wird automatisch jede Nacht ausgeführt, während der Release-Build zu bestimmten Zeitpunkten von Hand ausgeführt werden sollte
• release build sollte idealerweise den Quellcode taggen / verzweigen und möglicherweise die Build-Artefakte in einem zentralen Repository bereitstellen (z. B. bei Verwendung von Maven)

Diese Unterschiede sind in der Praxis ein paar zusätzliche Optionen in den meisten mir bekannten Build-Management-Systemen. Um das Risiko menschlicher Fehler zu minimieren, können diese z. B. in einer Batch- / Skriptdatei gespeichert werden, die nur die erforderlichen Parameter verwendet (und validiert).

Nun, ich würde mir wünschen, dass der Release-Build dem nächtlichen so nahe wie möglich kommt! Im Idealfall genau das gleiche, aber mit einem Tag.

Die Sache ist, wenn Ihr Release-Build und Ihr nächtliches nicht gleich sind, besteht die Möglichkeit, dass alles, was anders ist, ein Problem maskieren kann (oder das Auffinden eines Problems so viel schwieriger macht).

Ich hätte einen einzigen Build-Prozess, der bei jedem Check-in, der vom CI-Service ausgeführt wird, alles erstellt. Das wären sowohl Debug- als auch Release-Builds.

Bei zwei oder drei separaten Prozessen müssen sie nur nach dem Zufallsprinzip Änderungen vornehmen, ohne dass dies dokumentiert wird. Es wird nicht lange dauern, bis jemand für jede potenzielle Veröffentlichung 15 Schritte ausführen muss, um sie für die Veröffentlichung vorbereiten zu können.

Eine Sache, die ich unbedingt machen möchte, ist, den nächtlichen Build in den Release-Modus zu versetzen und nicht in den Debug-Modus. Bei Protokollierungsframeworks wie log4net, die System.Diagnostics.Debug ersetzen, bestehen die Hauptunterschiede zwischen Release- und Debug-Modus in der Lebensdauer von Objekten und in der Codeoptimierung.

Wenn Sie Ihrem nächtlichen Build nicht tatsächlich einen Debugger hinzufügen, würde ich dies auch vorschlagen.

Der Prozess, dem wir folgen, ist, dass der nächtliche Build jede Nacht ausgeführt wird. Wenn dies funktioniert, können wir denselben Build auf unseren anderen Servern bereitstellen (kein Neuaufbau, nehmen Sie einfach die Installationspakete und führen Sie sie aus). Wenn wir ein Problem mit dem nächtlichen Build haben, checken wir die Änderungen an einem Zweig ein und führen tagsüber einen nächtlichen Build von diesem Zweig aus. Die Tests können dann erneut ausgeführt werden.