Ich weiß, dass die Standardempfehlung für die Discourse-Versionierung tests-passed lautet, aber unser Team hat bisher die Discourse-Version in der app.yml explizit angegeben, z. B. version: 2.7.0.beta1. Wir tun dies, weil wir die auf der Produktionsumgebung installierte Version explizit steuern möchten.
Allerdings haben wir in diesem Thema einen Fehler entdeckt, der uns daran hindert, dies wie bisher zu tun. Dies ist ein Problem aufgrund unserer Vorgehensweise beim Autoscaling unseres Forums. Nehmen wir an, Version 2.7.0.beta1 ist aktuell auf der Produktionsumgebung im Einsatz. Dann kommt es zu einem plötzlichen Anstieg des Datenverkehrs auf dem Forum, und wir müssen eine weitere Instanz hochfahren, um diesem gerecht zu werden. Wenn in der app.yml tests-passed steht und seit dem letzten Produktionsupdate eine weitere Discourse-Version veröffentlicht wurde, wird eine neue Instanz (2.7.0.beta2) gestartet, die mit der bestehenden kollidiert. Dadurch haben wir zwei verschiedene Versionen im Einsatz, möglicherweise mit Datenbankänderungen und anderen Kompatibilitätsproblemen, was dazu führt, dass die Produktion nicht korrekt funktioniert.
Es gibt auch andere Gründe, warum wir ein solches automatisches Update nicht wünschen, etwa Kompatibilitätsprobleme mit Plugins oder der Wunsch, alles vor dem Release auf der Produktionsumgebung vollständig auf der Staging-Umgebung zu testen.
Als Anmerkung: Wir haben versucht, diese Lösung umzusetzen, um die Discourse-Version angeben zu können, aber sie schlägt aktuell bei Version 2.7.0.beta3 fehl. Wir erhalten einen Bundler-Fehler, der dem ähnelt, der hier beschrieben wurde. Ich weiß, dass die Lösung dieser Person darin bestand, wieder zu tests-passed zurückzukehren.
Meine Frage lautet also: Wie können wir angesichts unseres Autoscaling-Setups und unseres allgemeinen Bedarfs, die auf der Produktionsumgebung eingesetzte Discourse-Version explizit anzugeben, die Discourse-Versionierung effektiv steuern? Ich würde gerne hören, was andere in einer solchen Situation getan haben.