Je construis l'application de phoenix avec l'exrm. Bonne pratique suggère, que je devrais faire des tests contre le même binaire, je vais pousser à la production. Exrm me donne la possibilité de déployer Phoenix sur des machines sur lesquelles Erlang ou Elixir n'est pas installé, ce qui accélère le tirage des images.Essai de libération d'élixir construit avec exrm
Y a-t-il un moyen de démarrer mix test contre binaire construit par exrm?
Il convient de noter que les versions ne sont pas un fichier binaire. Bien sûr, ils sont empaquetés dans une archive, mais ce n'est que pour faciliter le déploiement, ce qu'il contient est effectivement les fichiers binaires .beam générés avec MIX_ENV=prod mix compile, plus ERTS (si vous l'empaquetez), fichiers Erlang/Elixir .beam, et les scripts de démarrage/Donc, en bref, votre code se comportera de manière identique dans une version comme il le serait lors de l'exécution avec MIX_ENV=prod (en supposant que vous avez exécuté MIX_ENV=prod mix release). La seule différence pratique est de savoir si vous avez correctement configuré votre application pour être intégrée dans une version, et tester cela revient à faire un déploiement de test à /tmp/<app> et de l'amorcer pour vous assurer que vous n'avez pas oublié d'ajouter des dépendances à applications dans mix.exs.
L'autre élément que vous devez tester est si vous effectuez des mises à niveau/rétrogradations à chaud avec votre application, auquel cas vous devez effectuer des tests de déploiement localement pour vous assurer que la mise à niveau/rétrogradation est appliquée comme prévu. génère des fichiers par défaut .appup pour vous, qui ne font pas toujours ce qui est correct, ou tout ce dont vous avez besoin, dans ce cas vous devez les éditer le cas échéant. Je le fais en déployant à /tmp/<app> en démarrant l'ancienne version, puis en déployant l'archive tar de mise à niveau à /tmp/<app>/releases/<new version>/<app>.tar.gz et en exécutant /tmp/<app>/bin/<app> upgrade <version> et en testant que l'application a été mise à niveau comme prévu, puis en exécutant la commande downgrade de la version précédente pour voir si elle revient correctement . La nature des tests varie en fonction des changements de code que vous avez effectués, mais c'est l'essentiel.
Espérons que cela aide à répondre à votre question!
Pour ajouter à cette excellente réponse, gardez à l'esprit que la version ne contient pas de code de test et qu'elle n'inclut pas 'mix', donc l'exécution de tests sur la version ne peut techniquement pas fonctionner. Vous pouvez bien sûr envisager des tests d'intégration/d'acceptation si vous déployez la version sur un serveur de transfert et exécutez des tests de boîte noire (par exemple en vérifiant le résultat de diverses requêtes http). – sasajuric
Merci, c'était, ce que je m'attendais vraiment, mais je voulais juste être sûr. Encore une question. Il est compilé avec 'MIX_ENV = prod', mais la version actuelle lira-t-elle les variables d'environnement? Donc, si j'ai MIX_ENV = stag avec d'autres informations d'identification de base de données, cela devrait fonctionner correctement? Merci bitwalker pour le super logiciel :) – tkowal
@tkowal Vous pouvez toujours utiliser System.get_env dans votre code, de sorte que vous pouvez définir des variables d'environnement et les lire comme vous vous y attendez, la différence est dans la configuration de votre application, comme la configuration ne changera plus en fonction de 'MIX_ENV' (parce que vous n'utilisez pas Mix dans une version, que ce soit pour l'exécuter ou pour lire la configuration). Ainsi, la configuration sera l'environnement dans lequel vous avez exécuté 'mix release' avec (sauf si vous éditez sys.config sur votre système cible). – bitwalker