Sobre la actualización del código fuente de Discourse, las dependencias a nivel de sistema operativo, la imagen base de Docker, las gemas de Ruby y cosas similares, es posible hacerlo construyendo en dos pasos y ejecutando las tareas mencionadas anteriormente en el primer paso.
Este primer paso es agnóstico al entorno y podría ejecutarse incluso en un entorno de CI (de modo que podrías usar una imagen casi idéntica en los entornos de staging y producción, evitando posibles errores debidos a reconstrucciones en fechas diferentes, sin mencionar la reducción del tiempo de inactividad).
Las tareas de migración de la base de datos y assets:precompile aún tendrían que ejecutarse en la máquina de destino. La migración de la base de datos, en la mayoría de los casos, sería rápida. Por otro lado, la tarea assets:precompile es un problema porque es el paso que más tiempo toma. Creo que es porque algunos activos necesitan conocer ciertos detalles del entorno definidos en la base de datos, como algunas reglas CSS, para ejecutarse.
Sería excelente si esta tarea se dividiera en dos: primero, todos los activos que no dependen del entorno se ejecutarían y podrían procesarse en un entorno de CI; y en el segundo paso, solo se compilarían los activos que dependen de datos en la base de datos, etc. Dicho esto, no sé qué tan difícil sería implementarlo técnicamente.
Hablo sobre el arranque del contenedor de la aplicación en dos pasos en el siguiente tema:
Los cambios que realicé solo consistieron en dividir la plantilla web de Discourse en tres archivos, pero las tareas son las mismas, aunque sería genial si el equipo de Discourse lo soportara para que no tuviera que actualizarlo debido a cambios futuros en la plantilla web.