wiki:Release a Beta milestone

Diese Seite beschreibt eine mögliche Vorgehensweise und Hinweise zum Release einer Beta-Version.

Konventionen

Build Types:

  • Nightly Builds sind experimentelle Entwicklerversionen, die unfertige oder verbuggte Features enthalten können. Nightly Builds sollten nach Möglichkeit nicht crashen, aber es kann vorkommen.
  • Beta Builds sind stabile Zwischenstände, die eine Menge von fertigen Features enthalten. Unfertige oder verbuggte Features sollten nicht enthalten sein. Crashs dürfen nicht auftreten.
  • Stable gibt es bisher nicht ;)

Die einzelnen Build-Zweige sind unabhängig voneinander, d. h. Nightly aktualisiert nicht auf Beta (weil dies einen Wegfall von Features bedeuten würde). Leider aktualisiert auch Beta nicht auf Stable, was man auf folgende Arten behandeln kann:

  1. Auto-Updater erweitern: Beta aktualisiert auf Stable und wieder zurück auf Beta (müsste dafür Einstellung in user.config speichern) oder
  2. Bei Veröffentlichung einer Stable-Version gleichzeitig eine Beta mit demselben Inhalt veröffentlichen

Installation Types:

  • NSIS: Offizielles EXE-Setup
  • ZIP: halboffizielle Variante (mit rudimentärer Setup-Funktionalität: räumt beim Update erst alte Installationsdateien weg, bevor neue entpackt werden)

SVN-Pfade:

  • trunk ist der aktuelle Arbeitspfad des Nightly Builds
  • branches sind sonstige Arbeitspfade (etwa für eine Beta), die man jederzeit verändern und irgendwann löschen kann (und auch wiederherstellen, wenn man zu voreilig gelöscht hat)
  • tags sind Momentaufnahmen für das Archiv, die weder verändert noch gelöscht werden

Vorbereitung

Zunächst empfiehlt es sich den Fortschritt eines Beta-Releases an den Tickets im trac festzuhalten. Die Ticket-Liste legt dabei nicht nur fest, was fertig werden muss, sondern auch, was nicht fertig werden muss. Damit man sich nicht mit Kinkerlitzchen aufhält oder aufwendige Umbauten anfängt, die den Milestone-Termin gefährden, gilt daher: was nicht dem Milestone zugeordnet ist, wird nicht gemacht (zumindest nicht jetzt). Insbesondere nice-to-have Tickets können meist ohne große Absprache an den nächsten Milestone durchgereicht werden: sie kosten Arbeitszeit, sind entbehrlich und tragen nicht zum Erreichen der eigentlich wichtigen Aufgaben eines Milestones bei.

  • Im trac einen Milestone erstellen (Admin → Ticket system → Milestones), grobe Ziele definieren und Datum festlegen
  • Menge von Tickets dem Beta-Milestone zuordnen, ggf. ergänzen, restliche Tickets auf späteren Milestone verschieben (!)
  • Milestone auf ct2-dev@… ankündigen und Termin für Feature Freeze bekanntgeben (ggf. auch separaten Termin für Code Freeze)
  • trunk nach branches\BetaX branchen
  • Experimentelle oder unfertige Features im Beta-Branch deaktivieren, z. B. P2P
  • Regelmäßig Bugfixes vom trunk in den Beta-Branch mergen und umgekehrt

Es ist relativ egal, ob man Bugfixes ursprünglich im trunk oder im Beta-Branch committet, da man einzelne Revisionen in beide Richtungen mergen kann. Grundsätzlich ist es möglich parallel im trunk schon an neuen Features zu arbeiten und diese Revisionen beim Merge entsprechend auszulassen kann, aber es erhöht das Risiko für Konflikte. Folgende Ratschläge erleichtern das Mergen:

  • Beta-Branch nicht zu früh vom trunk abspalten: das Feature-Set sollte weitgehend fertig sein
  • Regelmäßig durch die trac changesets gehen (oder durch die TortoiseSVN Revision Log) und für jede Revision einzeln entscheiden, ob sie gemergt wird
  • In TortoiseSVN Merge a range of revisisions verwenden, z. B. 3345,3390-3395,3429
  • Bei geänderten Einrückungen hilft Ignore all whitespaces
  • Bugfixes separat von strukturellen Änderungen oder neuen Features einchecken (einzelne Commits auseinanderfriemeln ist ätzend!)
  • Änderungen an Binaries separat von Source-Änderungen einchecken (Binaries werfen sofort Konflikte, da kein Merge möglich)

Testen

Sämtliches Testen sollte auf dem Beta-Branch durchgeführt werden. Die Menge an unterschiedlichen Testmethoden mag abschreckend wirken, dient aber letztlich der Entlastung des Teams von manuellen und repetitiven Fleißarbeiten.

  • In der GUI alle Buttons durchklicken, die beim Start sichtbar sind (man muss nicht alles bin ins letzte Untermenü händisch durchprobieren, aber man sollte sicher sein, dass CT2 nicht schon beim ersten Benutzerklick abstürzt)
  • Im -test-Modus starten und alle Templates automatisch für 10-20 Sek durchlaufen lassen
    • Anschließend txt-Logdatei auf Warnings und Errors prüfen
    • LocExtension-Probleme werden als Warning angezeigt
    • WSM-Ladeprobleme (inkonsistente Konnektoren oder Settings) werden als Warning angezeigt
    • Bug: Man kann den Test im Hintergrund laufen lassen, aber wenn man das CT2-Fenster in den Vordergrund holt, bekommt ein altes Tab den Fokus, was dann vom DemoController ein zweites mal gestartet/gestoppt wird
  • In Zukunft: Wizard Unit Test zum Konsistenz-Check der Wizard-Config
  • In Zukunft: Template/Plugin Unit Test zum Vergleich gegen Testvektoren
  • In Zukunft: Übersetzungstool CT2Translate zur Vollständigkeitsprüfung der .resx-Dateien (ggf. ergänzend zu LocExtension-Warnings im -test-Modus)

Release

  • changelog.txt aktualisieren
  • Auf Buildserver einloggen
  • SVN Update auf Build-Ordner durchführen
  • In MsBuild - CT2 Main.proj:
    • Versionsnummer CT2_Beta aktualisieren
    • CT2_BuildType von Nightly auf Beta ändern
    • CT2_SvnRepositoryPath von trunk auf den BetaX-Branch umstellen
  • Run86.bat ausführen und log_x86.log beobachten
  • Bei Erfolg UpdateNightlyBuilds.bat ausführen
  • Aufräumen nicht vergessen: CT2_BuildType auf Nightly und CT2_SvnRepositoryPath auf trunk zurücksetzen
  • Aktuellen Stand von branches/BetaX nach tags/YYYYMMDD_BetaX branchen bzw. taggen

Run86.bat führt alle notwendigen Schritte automatisch durch, etwa:

  • Kompiliert die BuildTasks neu
  • Führt einen SVN Checkout oder Revert&Update durch
  • Schreibt alle AssemblyInfo.cs neu
  • Kompiliert die PAP-Libs
  • Kompiliert die CoreDeveloper-Solution
  • Signiert Build mit Strong Name und Software Publisher Certificate
  • Aktualisiert CT2_Versions.xml

Die Änderungen liegen in BuildOutput und werden erst öffentlich, wenn man sie per UpdateNightlyBuilds.bat auf den Webserver kopiert hat. Der Nightly Build wird dies um 0:00 UTC automatisch durchführen.

Nachbereitung

Im Laufe einer Beta erhält man Crash Reports oder sonstige Bugmeldungen. Bei kritischen oder häufig auftretenden Bugs ist es überlegenswert eine Beta zu aktualisieren. Hierfür muss man Bugfixes aus dem trunk in den Beta-Branch mergen und die Schritte aus dem Abschnitt #Release wiederholen. Allerdings muss man beachten, dass es evtl. zwischenzeitlich Änderungen am Build-Prozess gab, daher sollte man den Build-Ordner auf dem Buildserver nicht auf HEAD updaten, sondern auf die Revision vom ursprünglichen Beta-Release.

Last modified 7 years ago Last modified on Dec 30, 2011, 2:38:22 PM