Что касается обновления исходного кода Discourse, зависимостей на уровне ОС, базового образа Docker, Ruby-гемов и подобного, это можно сделать, разбив сборку на два этапа и выполнив вышеупомянутые задачи на первом этапе.
Этот первый этап не зависит от среды и может выполняться даже в CI-окружении (таким образом, можно использовать практически идентичный образ в staging и production, избегая возможных ошибок из-за пересборки в разные даты, не говоря уже о сокращении времени простоя).
Задачи миграции базы данных и assets:precompile всё ещё нужно будет выполнять на целевой машине. Миграция базы данных в большинстве случаев будет быстрой. С другой стороны, задача assets:precompile является проблемой, так как это самый продолжительный этап. Я думаю, что это связано с тем, что некоторые ассеты нуждаются в информации об окружении, определённой в базе данных (например, некоторые правила CSS), чтобы выполнить сборку.
Было бы чрезвычайно полезно, если бы эту задачу можно было разделить на две части: сначала собирались бы все ассеты, не зависящие от окружения, и их можно было бы выполнять в CI-окружении, а на втором этапе компилировались бы только те ассеты, которые зависят от данных в базе данных и т.д. Тем не менее, я не знаю, насколько сложно технически реализовать это.
Я обсуждаю запуск контейнера приложения в два этапа в следующей теме:
Внесённые мною изменения касались только разделения шаблона веб-интерфейса Discourse на три файла, но задачи остались прежними. Хотя было бы здорово, если бы команда Discourse поддержала это, чтобы мне не приходилось обновлять их из-за будущих изменений в веб-шаблоне.