3

I am building phoenix application with exrm.

Good practice suggests, that I should make tests against the same binary, I'll be pushing to production.

Exrm gives me the ability to deploy phoenix on machines, that don't have Erlang or Elixir installed, which makes pulling docker images faster.

Is there a way to start mix test against binary built by exrm?

tkowal
  • 9,129
  • 1
  • 27
  • 51

1 Answers1

4

It should be noted that releases aren't a binary file. Sure they are packaged into a tarball, but that is just to ease deployment, what it contains is effectively the binary .beam files generated with MIX_ENV=prod mix compile, plus ERTS (if you are bundling it), Erlang/Elixir .beam files, and the boot scripts/config files for starting the application, etc.

So in short your code will behave identically in a release as it would when running with MIX_ENV=prod (assuming you ran MIX_ENV=prod mix release). The only practical difference is whether or not you've correctly configured your application for being packaged in a release, and testing this boils down to doing a test deployment to /tmp/<app> and booting it to make sure you didn't forget to add dependencies to applications in mix.exs.

The other element you'd need to test is if you are doing hot upgrades/downgrades with your application, in which case you need to do test deploys locally to make sure the upgrade/downgrade is applied as expected, since exrm generates default .appup files for you, which may not always do the correct thing, or everything you need them to do, in which case you need to edit them as appropriate. I do this by deploying to /tmp/<app> starting up the old version, then deploying the upgrade tarball to /tmp/<app>/releases/<new version>/<app>.tar.gz, and running /tmp/<app>/bin/<app> upgrade <version> and testing that the application was upgraded as expected, then running the downgrade command for the previous version to see if it rolls back properly. The nature of the testing varies depending on the code changes you've made, but that's the gist of it.

Hopefully that helps answer your question!

bitwalker
  • 9,061
  • 1
  • 35
  • 27
  • 2
    To add to this excellent answer, keep in mind that release doesn't contain test code and it also doesn't include `mix`, so running tests on the release can't technically work. You could of course consider integration/acceptance testing, if you deploy the release to some staging server and run some black box tests (e.g. by checking the outcome of various http requests). – sasajuric Oct 01 '15 at 08:05
  • Thank you, that was, what I actually expected, but I just wanted to be sure. One more question. It is compiled with `MIX_ENV=prod`, but will the actual release read the enviroment variables? So that if I have MIX_ENV=stag with other database credentials, it should still work correctly? Thanks bitwalker for the great software :) – tkowal Oct 01 '15 at 16:45
  • 1
    @tkowal You can still use System.get_env within your code, so you can set environment variables and read them as you'd expect, the difference is in the configuration of your application, as the configuration won't change based on `MIX_ENV` anymore (this is because you are not using Mix in a release, either to run it, or to read configuration). So the config will be whatever environment you ran `mix release` with (unless you edit sys.config on your target system). – bitwalker Oct 02 '15 at 04:12
  • 1
    @sasajuric Good thing to point out! Though you can actually add the `mix` application as a dependency, and include it in the release, but as you can probably guess, it's neither recommended or guaranteed to even work properly ;) – bitwalker Oct 02 '15 at 04:15