Concernant la mise à jour de la source de Discourse, des dépendances au niveau du système d’exploitation, de l’image de base Docker, des gems Ruby et autres, il est possible de le faire en construisant en deux étapes et en exécutant les tâches susmentionnées lors de la première étape.
Cette première étape est agnostique à l’environnement et pourrait même être exécutée dans un environnement CI (vous pourriez ainsi utiliser une image presque identique dans les environnements de staging et de production, évitant ainsi les erreurs potentielles dues à une reconstruction à des dates différentes, sans parler de la réduction des temps d’arrêt).
Les tâches de migration de la base de données et de assets:precompile devraient toujours être exécutées sur la machine cible. La migration de la base de données est dans la plupart des cas rapide. En revanche, la tâche assets:precompile pose problème car c’est l’étape qui prend le plus de temps. Je pense que c’est parce que certains assets ont besoin de connaître des informations environnementales définies dans la base de données, comme certaines règles CSS, pour s’exécuter.
Ce serait extrêmement avantageux si cette tâche pouvait être divisée en deux : d’abord compiler tous les assets qui ne dépendent pas de l’environnement, ce qui pourrait être fait dans un environnement CI, puis, lors de la deuxième étape, compiler uniquement les assets qui dépendent de données dans la base de données, etc. Cela dit, je ne sais pas à quel point ce serait techniquement difficile à mettre en œuvre.
Je discute de l’amorçage du conteneur de l’application en deux étapes dans le sujet suivant :
Les modifications que j’ai apportées concernaient uniquement la division du modèle web de Discourse en trois fichiers, mais les tâches restent les mêmes. Cependant, il serait préférable que l’équipe de Discourse prenne en charge cette approche afin que je n’aie pas besoin de les mettre à jour en raison de futures modifications du modèle web.