Erzählen Sie mir von Ihrer Erfahrung mit Release Candidate (RC), wie haben Sie diesen Ansatz in Ihren Projekten angewendet?

Ich habe die Release Candidate-Version als letzte Testphase vor der Veröffentlichung im App Store verwendet.

Der Prozess umfasste in der Regel:

1. Erstellung des RC basierend auf dem Branch release oder main nach Stabilisierung.
2. Hochladen des Builds zu TestFlight für eine Gruppe interner Tester und/oder externer Beta-Tester.
3. Gründliche Tests auf verschiedenen Geräten und iOS-Versionen.
4. Nur kritische Fehler, die die Veröffentlichung blockierten, wurden behoben. Kleine Verbesserungen und nicht kritische Fehler wurden auf spätere Versionen verschoben.
5. Bei kritischen Fehlern: Erstellung eines Patch-Branches vom RC, Behebung, Erstellung eines neuen RC-Builds und Wiederholung der Schritte 1-4.
6. Wenn das RC die Tests erfolgreich besteht und keine kritischen Fehler enthält: Veröffentlichung desselben Builds im App Store.

Der Einsatz von RC minimierte das Risiko, eine instabile Version zu veröffentlichen, da der für Tests verwendete Build identisch mit dem war, was an die Endbenutzer ausgeliefert wurde. Dies erhöhte das Vertrauen in die Qualität der Veröffentlichung.