Discourse のソースコード、OS レベルの依存関係、Docker ベースイメージ、Ruby Gems などの更新について、ビルドを 2 ステップに分け、1 ステップ目で上記のタスクを実行することで対応可能です。
この最初のステップは環境に依存しないため、CI 環境でも実行できます（これにより、ステージング環境と本番環境でほぼ同一のイメージを使用でき、異なる日時にビルドを再実行することによる潜在的なエラーを回避でき、ダウンタイムの削減にもつながります）。
DB マイグレーションと assets:precompile タスクは、依然としてターゲットマシンで実行する必要があります。DB マイグレーションはほとんどの場合高速ですが、一方、assets:precompile タスクは問題となります。なぜなら、このステップが最も時間を要するからです。その理由として、一部のアセットが DB で定義された環境情報（一部の CSS ルールなど）を認識して実行する必要があるためではないかと考えられます。
もしこのタスクを 2 つに分け、環境に依存しないアセットを先に実行して CI 環境で処理し、2 ステップ目では DB などの環境情報に依存するアセットのみをコンパイルすることができれば、非常に素晴らしいことです。ただし、技術的に実装がどの程度難しいかはわかりません。
アプリコンテナのブートストラップを 2 ステップで行うことについては、以下のトピックで議論しています。
私が行った変更は、Discourse の Web テンプレートを 3 つのファイルに分割したことだけですが、タスク自体は同じです。それでも、Discourse チームがこの仕組みをサポートしてくれれば、Web テンプレートの将来の変更に合わせて毎回更新する必要がなくなるため、非常に助かります。